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]

Reply via email to