On Sat, Nov 26, 2022 at 8: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. > Recapping what I believe I saw in the above thread- the idea is to strip the DKIM header in the message view seen from the inbox. This is an interesting idea, but as pointed out elsewhere, it's pretty easy for the spammers to bypass, as they simply need an MX they control. Alternatively any mailbox provider with access to the message w/o stripping the DKIM header. > > 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... > > As one of the instigators of the DKIM replay WG proposal at Dispatch, apologies for the delay. For the last several years, we've noticed an uptick in spam attacks around this time of year, and this year is no different. Last year the spammers were exploiting DKIM replay. This year, they are exploiting the SPF's vulnerability to multi-tenancy to obscure spam traffic though a vulnerable forwarder. Things had to calm down a bit, before getting back to this thread. In any case I also bring up the SPF issue to point out there are other authentication challenges, and to be mindful of supporting mitigating them as well. (My intuition keeps coming back to the idea that can make progress here if we could distinguish these different traffic flows) -Wei > > > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
