On Sun, Jul 5, 2020 at 7:42 PM John Levine <[email protected]> wrote: > I wrote the Sympa ARC code which is entwined with the DKIM code so > that would probably be me. Honestly, this looks like a lot more work > than ARC to get a result likely to be worse in practice than ARC. >
Interesting; I had the opposite experience, and I had a lot of our DKIM code to recycle when I built our ARC implementation. This idea doesn't seem nearly as complicated to implement. Moreover, ARC is a much more heavyweight addition to the stack than a new DKIM tag would be. > 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 isn't a new attack though, given spammers sign their email already. This way you have (in theory) two good signatures: one from the author for the "safe" form of the message, and one for the spam that got bolted on, and you could in theory strip the spam before you deliver because you know exactly what it is. I believe that the main thing that recipients will do with either of > these is to ask was the original message actually from the putative > sender, and ARC is a lot easier to implement. > As I said upthread, I agree that it fulfills the same need that ARC does. There was a previous thread about ways to avoid MLMs needing to munge headers in a DMARC world, and that reminded me of this, so I thought it might be worth dusting it off. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
