On 7/11/18 5:15 PM, Brandon Long wrote:
DKIM-Signatures are also sometimes removed from messages (mailing
lists often do this), and there are also MTAs which incorrectly make
assumptions about how DKIM-Signature failure means (the RFC says a
failed DKIM-Signature should be treated as if it's not there, but
that's not what we're seeing in practice). Earlier instances of the
AMS are expected to fail if the message content is changed and for
that to be fine.
We did spend a bunch of time, maybe before it even came to the IETF,
exploring whether we could do this without having a separate set of
header fields, and we decided no.
So essentially we're creating a bunch of header bloat (creating
duplicate header fields with different names where that could be
avoided) because there are some MTAs that did not follow the
specifications before. That makes me unhappy, but what matters here is
not the behavior of all MTAs, it's the behavior of MTAs implementing ARC
(that include instance number tag/value). If there's an MTA in the
middle that deletes DKIM-Signature, it's not implementing ARC and the
chain is broken.
Small reminiscence (feel free to ignore this): Back when we were merging
DomainKeys and IIM to create DKIM, one of the design decisions was
whether to publish the public key in DNS (ala DomainKeys) or to include
it in the signature header field and put a fingerprint in DNS (ala IIM).
The decision was made when a large mail service provider calculated how
much more storage they would have to buy in the latter case (because of
the larger header field). While that was ~14 years ago and storage is
cheaper now, we're talking about a lot more space than just a public key.
-Jim
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
