Hi Richard and John, The text I included was only meant as a starting point for discussion, not as wording I expect to see adopted as is. The BCP author is of course free to modify it, remove parts of it, or rewrite it entirely in whatever way best fits the document.
What I believe matters is that operators are aware of the limits that MTAs, message stores and mailbox providers place on header sections and individual header fields. These limits vary considerably from one implementation to another, and they are not always enforced in the same way. Since DKIM2 adds header fields whose size grows with each hop and with the content of any Recipes, it seems worth giving operators a short note in the BCP so they can keep these limits in mind when deploying DKIM2 and avoid interoperability problems. However the BCP ends up expressing this, whether with specific figures or with a more general note, I would be happy with either. Best, Mauro > On 30 Sep 2026, at 19:18, John Levine <[email protected]> wrote: > > It appears that Mauro De Gennaro <[email protected] <mailto:[email protected]>> > said: >> Hi all, >> >> I went through spec-06, bcp-01 and dns-00 looking for anything about header >> size limits in bytes and found nothing. BCP 7.5 covers the >> number of Message-Instance and DKIM2-Signature fields; I'm not trying to >> reopen the discussion about a ceiling on that number, but the >> size of those fields is the other half of the same problem and fits >> naturally in that section. Spec section 16 is still TBA. The only >> place the topic shows up is section 4.3.1 of >> draft-moccia-dkim2-deployment-profile, which the WG decided not to adopt, so >> I'm not building >> on it, and I'm not proposing anything about the recipe or JSON design >> either. This is a small operator note for the BCP, with proposed >> text further down. >> >> I think this deserves a few paragraphs because receivers fail in three >> different ways when the header section gets too big. Some reject >> during the SMTP transaction, which is fine because the sender finds out. >> Some drop the connection. Others truncate silently, and for us >> that is the bad case. Every DKIM2-Signature covers all Message-Instance and >> DKIM2-Signature fields, so a single truncated field breaks >> every signature on the message, and the verifier reports "Message-Instance >> m=x contains invalid JSON" against a Reviser whose message was >> well formed when it left. >> >> I asked Claude to research what are the header limits defaults on different >> MTAs, message stores and cloud providers, details are below. >> "Total" is the whole header section, "per header" is one logical field. >> >> - Sendmail 8.18: MaxHeadersLength 32768 total, 552 5.6.0 [1] > > That's just the default which you can override in your config file. > > I don't see any reason to assume that the other numbers are meaningful, > either. > > In any event I agree with Richard that even 32K is a lot of headers and it's > not likely to be a problem > unless people are deleting large executable attacchments and trying to > describe that in the diffs which serves them right. > > R's, > John
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
