I will say that the use case that is broken by removing the signature is the "re-send" case, where the MUA or some other post-delivery agent (perhaps a sieve script) re-introduces the message with a different RCPT TO but the same MAIL FROM and "From:". I don't know how often this happens nowadays, but I do know that I use it often in filters of my own, where mail sent to one of my addresses gets re-sent to another of my addresses -- sometimes in the same domain and sometimes in a different domain.
It works perfectly now, because the signature header is still there and everything still verifies, so the new delivery thinks everything is fine. But if the first MDA removes the signature, the re-send will be unsigned and will get a DMARC failure. We have to decide whether it's worth breaking that use case in order to address the replay situation. My opinion is that it's not -- because, as I say, I rely on that use case extensively. My system would have to change *significantly* in order to work around that. Barry On Sat, Nov 26, 2022 at 11:36 AM Dave Crocker <d...@dcrocker.net> wrote: > > On 11/25/2022 2:26 AM, Laura Atkins wrote: > > What’s stopping large providers from removing DKIM now if they wanted to? > > Nothing at all. That they can choose to, if they wish, is one of the > appealing aspects to this. It permits unilateral adoption. > > > > Or have they actually made the choice to keep the signatures in? > > No idea. And yes, it would be good to ask them. I wonder what venue > there might be to float such a question...? > > (time-passing jingle plays...) Venue found. So now let's see how they > respond... > > > > If they have made that choice, do we know why? If they haven’t made > > the choice, how complicated will it be to change the inbound MTA to > > strip headers? > > To quibble, I'd hope it is some form of MDA, so the step is part of > delivery and not relaying. > > > > Will this have knockon effects for their internal systems? Is there a > > risk that stripping the DKIM header will cause authentication failures > > if the messages are forwarded internally or externally? (I’m reminded > > of the time Microsoft changed some internal systems around and ended > > up having everything fail SPF because they were picking the wrong IP > > out of their mess of headers to do SPF authentication with). > > The essence of the questions you ask is to press for serious due > diligence among a range of sizeable email receiving platforms. That is > certainly an useful step before having the working group assert the > recommendation to remove the signature. > > > > And, I think most importantly: will this recommendation by the IETF > > have any impact whatsoever on the groups currently using DKIM replay > > as a way to get past (some) filters? > > There are never any guarantees about adoption. Once upon a time, the > IETF made some effort to get an indication of industry interest in > adoption. > > These days, not so much. Personally, I think that checking for adoption > interest is another kind of due diligence that ought to be required. > > > > I don’t see how it will, most of them are using their own email > > addresses / servers to collect the replayed messages and then sending > > the messages out through their own systems. > > I don't understand. > > > > Even if Google and Microsoft and Yahoo and the other top 20 mailbox > > providers start stripping DKIM headers, the attackers will be able to > > find some service somewhere that doesn’t. Worst comes to worst, they > > stand up a MX on an EC2 instance and run their own code to collect the > > mail. > > There seems to be some appeal in discounting the resulting requirement > to move to special receivers, but I don't understand that appeal. > Making things more expensive for attackers is pretty much the essence of > security protections. > > That the added expense isn't all that high seems ok to me, since the > expense of imposing that expense isn't that high either. > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker@mastodon.social > > _______________________________________________ > 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
