On March 19, 2023 6:57:13 PM UTC, Wei Chuang <weihaw=40google....@dmarc.ietf.org> wrote: >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.
If we're going to deprecate indirect mail flows we should be explicit about it. Standardizing protocol changes that make them look inherently suspicious while pretending that they are still supported is disingenuous and not the way to go about it. As far as I have seen, none of the proposals that break the boundary between envelope and the message body can distinguish between 'good' and 'bad' indirect mail. I do think we should, for the moment, continue to focus on the problem statement to see if we can come up with a technically distinct definition of the problem. Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
