-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Mauro De
Gennaro <[email protected]> writes
>I went through spec-06, bcp-01 and dns-00 looking for anything about header
>size
>limits in bytes and found nothing.
try RFC5321 and if you cannot find it there then no formal limit exists
and it is not, in my view, appropriate for DKIM2 to set one
>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.
this does not seem to be a DKIM2 specific issue at all
> 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.
that seems like a win for DKIM2 ... if the header fields are mangled
then signatures will probably fail (depending on exactly which header
fields were dropped -- because some are not signed) and so the message
should not be accepted ... I doubt a Verifier would get to the point of
checking the JSON
>I asked Claude to research what are the header limits defaults on different
>MTAs, message stores and cloud providers, details are below.
if you didn't check for yourself, then "informed guesses are below"
might be closer :-)
[...]
>so 63 hops of dual signatures
>already passes Sendmail's default before any other header is counted
why would any email travel 63 hops without something being broken ?
this topic came up earlier and numbers between 20 and 32 (IIRC) were
thought to be outrageously high .. recalling that MTAs count Received
header fields to detect loops and that Received header fields will
probably outnumber DKIM2-Signature header fields once the count gets
above about 3 ((and Message-Instance fields are unlikely to ever be more
than a handful))
>7.5. Discussion re: Maximum Number and Size of Message-Instance and
>DKIM2-Signature Header Fields
[..]
>Many MTAs, mailbox servers and hosted providers limit the size of the
>header section of a message, the size of individual header fields, or
>the number of header lines.
I think "All" rather than "many"
>Before adding its header fields, a Reviser SHOULD check that
>the Message-Instance header field it adds, measured as transmitted
>(field name and folding included), does not exceed 30000 octets, and
>that the header section as a whole, once its Message-Instance and
>DKIM2-Signature header fields are added, does not exceed 100000
>octets.
If you are adding 30K of recipes then I rather think you are doing
something dumb and any sensible reputation system is going to dislike
your email
>If a content-bearing Body Recipe would break either bound,
>the Reviser SHOULD use a null Body Recipe (Section 5.2 of [DKIM2])
>instead: a null Recipe is a visible, predictable outcome, whereas a
>truncated one is not.
Truncated header fields have a very predictable outcome -- failure to
deliver. In contrast, null body recipes have an unpredictable outcome
because there will not be a contractual relationship to fall back on and
we are not yet sure what the consensus will be in dealing with these (I
suspect general rejection, but with allowlisting)
>Header Recipes cannot be null (Section 5.1 of
>[DKIM2]); a Reviser whose header field changes would need a Header
>Recipe that breaks either bound SHOULD NOT make those changes.
I think that is MAY NOT because it may well interwork ...
>Operators who enforce header size limits on inbound mail SHOULD
>reject messages that exceed them during the SMTP transaction (for
>example with 552 5.3.4) instead of accepting and truncating.
that's not needed because you SHOULD NOT accept if the signature fails;
what you probably want to say is that if the message may be truncated
then you must take that into account when deciding whether or not to
accept an email
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBar0RgWHfC/FfW545EQKC8wCfbMrwhgpDEG3QMYDgk4SLIykhiZ4AoK/o
ZVRcZeWv/s6mCrRXqG2T8H7v
=QIEw
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
