On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins <la...@wordtothewise.com> wrote:
> ... > One of the panel members has shared the following from what he said at the > session: > > * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay. > * There may only be a best practices solution, and not a protocol solution. > * DKIM has since the beginning kept itself completely separate from the > message transport. Several of the proposed solutions (including mine) take > leaps of varying sizes into the realm of DKIM knowing something about the > transport; the lightweight ones connect the message to the envelope > somehow, and the more heavyweight ones mean DKIM filters have to learn > about MXes and whatnot. We have to be absolutely certain that we want to > break that wall if we go this way, because once we do, there will be no > turning back. > Agreed for the most part. While we can get mileage with the existing RFC6376 based tools such as header oversigning, "x=" expiry, and the other techniques mentioned, at some point the spammers will adapt. And as Michael and the panelist have pointed out, RFC6376 inherently permits DKIM replay as a feature due to that separation between envelope and message. The main thing I would quibble with the panelist is the distinct break if we start validating parts of the envelope or interacting with transport, as whatever technique to be adopted will have to consider participation by unaware forwarders i.e. some sort of gradual adoption process likely with some sort of experiment. Also I would argue we should break that wall between the message and the envelope and transport. From where I sit, I see mail forwarding bit by bit breaking as spammers use forwarding as a general technique, and the mitigations put in place using the existing protocols are insufficient for the challenge. The evidence is anecdotal since there aren't great tools to look at this at scale. -Wei
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
