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.
I was thinking of the work involved in putting it into the mailing list
software. ARC was straightforward, one bit where the messages come in to
recard the A-R header, another bit cloned from the DKIM code to apply the
seal.
For this I'd need to go through vast amounts of code looking for every
place that changes the message and figuring out what change might map onto
what DKIM key, and we still have a lot of changes that don't map onto
anything, so now some changes are safer than others.
It would not be hard for a bad guy to use the footer or add-part
transformation to lay a big spammy blob ...
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.
But then what? Surely we're not going to revisit the WKBI of showing
different parts of the message in different colors depending on whether
they're signed. If it's got bolted on spam, you treat the message as spam
so I don't see that this has gained you anything.
R's,
John
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
