On 21 Nov 2022, at 16:07, Jon Callas wrote: >> On Nov 21, 2022, at 14:01, Dave Crocker <[email protected]> wrote: >> >> On 11/21/2022 1:56 PM, Murray S. Kucherawy wrote: >>> I don't want to get into implementation discussions before we even have a >>> charter, but I'm curious about how this could be made effective. >> >> I'd count it as a simple tool that might have incremental benefit. >> >> Simply give guidance that an MDA SHOULD remove the DKIM signature, unless >> there is a local arrangement with the recipient not to. (Obviously the >> local detail could swap the default the other way.) >> >> I would expect anything more elaborate to be in the range of diminishing >> returns and, therefore, not worth the complexity, effort, etc. > > As another original author, it was hard for me to understand what this was > talking about when the discussion first came up. I even considered replying > to this thread asking something like, "isn't replay just sending the message > again?" before I understood. > > I really like the guidance that an MDA SHOULD remove a DKIM signature. I have > memories that we discussed just that even at the time, for a number of > reasons. > > This is a fine solution to this problem. The replay issue just goes away if > the header lines are removed.
I disagree with Jon (and Dave) on this. Spammers are notably agile — if some mechanism they have been using stops working, they quickly adapt and develop a workaround. In this case, they only need to arrange to have the signed message relayed to an MTA they control, and their problem is solved. In many cases they probably collect the signed messages from their own MTAs already. There is only a very indirect benefit for the very large number of DKIM-aware MTAs to change their behavior and remove DKIM signatures at delivery. This will take a VERY long time to happen, and the problem persists in the meanwhile (and the above adaptation on the part of spammers takes place as well). > It also addresses my long-standing complaint that DKIM is not supposed to be > a tracking and authenticity mechanism. Moreover, this is a much better > solution to my complaint than anything anyone has come up with, including my > eccentric foot-stamping about keys. This came up in the context of the use of DKIM signatures on leaked email messages to authenticate the leaked content. That is not the problem we’re trying to solve here. -Jim _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
