What’s stopping large providers from removing DKIM now if they wanted to?
Or have they actually made the choice to keep the signatures in? 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? 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). 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? 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. 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. laura > On 22 Nov 2022, at 18:56, mikespec...@gmail.com wrote: > > I have nothing much useful to add, except to say that I’m pro removing the > DKIM header for other privacy reasons. I also think the ietf signaling > support for this would be helpful in getting large email providers to push > forward with solutions here. > > KeyForge: Non-Attributable Email from Forward-Forgeable Signatures > usenix.org > <waves_favicon.ico> > > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge>KeyForge: > Non-Attributable Email from Forward-Forgeable Signatures > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge> > usenix.org > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge> > <waves_favicon.ico> > <https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge> > > ==Mike > >> On Nov 22, 2022, at 10:47 AM, Dave Crocker <d...@dcrocker.net> wrote: >> >> On 11/22/2022 6:12 AM, Scott Kitterman wrote: >>> On Tuesday, November 22, 2022 8:48:48 AM EST Alessandro Vesely wrote: >>>> On Tue 22/Nov/2022 01:21:00 +0100 Murray S. Kucherawy wrote: >>>>> We actually seemed to like the idea, at least back then, that the >>>>> signature >>>>> survives delivery so that it can be validated at any point later. >>>> Indeed, there are products, like Lieser's DKIM verifier plugin for >>>> Thunderbird[*], which verify DKIM on the MUA. >>> My desktop MUA of choice (kmail) includes the capability too. >> >> >> To the extent there is serious pressure to aid MUA awareness of the DKIM >> header-field for a received message, we can specify renaming the field (and >> removing the actual signature value.) >> >> This retains the desired signalling information, without being useful for >> replay. >> >> 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 -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
