A data point from the perspective of an operating re-originating relay - a service that rewrites the recipient address, terminates the inbound signing chain, and issues a fresh originating DKIM signature outbound rather than extending the chain.
On a corpus of 6186 inbound messages: header section size at the 50th percentile is 5630 octets, 90th 11420, 99th 16821. 35% of messages arrive above 8KB. 64% carry 2 DKIM-Signature fields on arrival; 46% carry at least one ARC-Seal hop. In a DKIM2 deployment that overhead does not pass through - the relay re-originates from a clean slate. Re-orgininator behavior has come up in the archive under various descriptions - “re-originator,” “alias service,” Vittorio’s “non-participating node” framing, the BCP’s own “personal alias service” mention in Section 5.4 - but the terminology section names only Originator, Forwarder, Reviser, and Receiver. Whether that gap matters for a BCP note on chain growth is a question. However, the concept appears to be in active use, it just does not yet have a name/definition. William Weiner From: Vittorio <[email protected]> To: "Ietf Dkim"<[email protected]> Date: Wed, 07 Oct 2026 06:13:58 -0600 Subject: [Ietf-dkim] Re: BCP: operator note on header size limits and Message-Instance growth > Hello. > > A data point for this thread, measured rather than estimated. > > I measured the header section of every message in two mailboxes on one > server, as delivered, counting from the start of the header block to the > first empty line with CRLF terminators. The sample is 52104 messages > received between 17 January 2024 and 7 October 2026. Two mailboxes on > one server are not a representative sample of the Internet and I report > it as what it is. The figures are the size as delivered, so they include > the header fields added locally by the receiving system, no Recipes are > present anywhere in the sample. > > Header section size, octets, whole sample: > > 50% of messages <= 2775 > 90% <= 5513 > 99% <= 11477 > largest 36480 > > above 16384 octets: 227 messages > above 24576 octets: 9 messages > above 32768 octets: 1 message > > Split by the presence of a List-Id header field: > > without List-Id, n=39013: 50% <= 2555, 90% <= 4990, 99% <= 9170, largest > 36480 > with List-Id, n=13091: 50% <= 2935, 90% <= 9518, 99% <= 17420, largest > 30619 > > The medians are close. At the 90th and 99th percentiles the mailing list > traffic is about twice the size of the rest, which is where the long > delivery paths are. The single largest header section in the sample is > not a mailing list message. > > One piece of arithmetic on the per hop figure quoted earlier in this > thread, 0.6 to 0.8 KB for a dual signature hop. Ten such hops added to > the 131 mailing list messages above the 99th percentile would put all of > them above 23000 octets and most of them above 24576. In the sample as > it stands, nine messages out of 52104 exceed 24576. That figure covers > signature material for a hop that forwards without modifying: a hop that > modifies also adds a Message-Instance and where that carries removed > content the growth is not bounded by any of the figures above. The > arithmetic is therefore a floor. > > A failure rate of this order is low enough that it would not be > recognised as a pattern, which matters when the failure mode is > truncation without indication: the verification failure is attributed to > the last signing hop, while the cause may be local to the receiver. > > Regards > Vittorio Moccia > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
