In my mind, there are two important things I would like to see achieved: 1) Distinguish indirect from direct flows (encode in some way which server / mailingList the original DKIM message was intended to come from). This is needed for domains that aren't easily identifiable as direct flows (SPF isn't aligned by DKIM in the direct case). 2) Give more info to identify benign indirect flows (E.g. "forwarded on behalf of"). This is helpful for recognizing a recipient's desired indirect flows.
Note that this isn't to say indirect mail would be deprecated. The goal is to better distinguish the flows so we can have a minimally disruptive response when Replay mitigations are needed. For example, consider the approach of counting MessageIds. This has some side effects on benign mail. The better we can identify the benign cases the easier it is to avoid negatively affecting those even while a DKIM Replay attack is active. On Sun, Mar 19, 2023 at 12:22 PM Scott Kitterman <skl...@kitterman.com> wrote: > > > 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 >
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
