On Mon 06/Jul/2020 06:50:45 +0200 Jim Fenton wrote:
On 7/5/20 7:42 PM, John Levine wrote:
It would not be hard for a bad guy to use the footer or add-part
transformation to lay a big spammy blob on top of some innocuous
original message. Rather than play cat and mouse and try to figure one
when a change is too big, recipients would use this the same way they
use ARC, and only check it on mail from senders who are generally well
behaved.
That was basically the argument against the l= parameter in DKIM
signatures. We did end up keeping l= because it only has effect if the
signer uses it and the verifier accepts its use, although it was widely
expected that it would not be used much. I suspect that's what happened.
The rationale for deprecating l= was that HTML and CSS allow appended content
to be displayed before or even above (overlapping) the original content.
I don't recall an actual proof of concept, though. Perhaps, we could have
thought better:
1. In most cases, text/html is relegated in its own MIME entity. Multipart
messages don't support simple append, except for the "epilogue" area.
2. In any case, the </html> etag is covered by the signature. Added text
would trigger quirks mode, and suppress CSS.
Rather than deprecate l=, perhaps we could just have noticed that it only makes
sense in text/plain messages, where it allows the addition of a footer. For
example, this message —now that IETF seems to have given up base64 encoding—
should feature an unbroken author signature.
For multipart messages, transformations may need to replace boundaries. In
that case, the "restricted patch" to undo the transformation may require more
data than it is convenient to store in a DKIM tag.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
