SPF trust was promised on the theory that shared infrastructure would prevent clients from impersonating each other. This document blows up that assumption.
It points out that clients have lost control of their SPF integrity. Neither those clients nor their message recipients have enough data to know what parts of an SPF policy are unneeded. Then it points out that there are attack vectors beyond the imagination of ordinary mortals. This document is a death knell for unsigned email, and we need to lead the effort by providing a way for senders to clearly document that all of their messages are signed. Thee are many domains that sign all messages, but there is no way for evaluators to reliably identify them This is not the time for Darwinism ("foolish people get what they deserve"). The infrastructure companies create the problem, clients choose the vendor, but unrelated recipients suffer the consequences. The wrong people take the hit. We need to provide a way to mitigate the harm caused by unjustified trust in SPF. Doug On Thu, Feb 29, 2024, 1:29 PM Scott Kitterman <skl...@kitterman.com> wrote: > > > On February 29, 2024 6:15:37 PM UTC, Benny Pedersen <m...@junc.eu> wrote: > >Douglas Foster skrev den 2024-02-29 18:48: > >> I am surprised at the lack of feedback about Barry's research link. > >> It is a devastating attack on our ability to trust SPF when shared > >> infrastructure is involved. As a result of that document, I have > >> switched camps and believe that we MUST provide a DKIM-only option for > >> DMARC. > >> > >> The proposed workaround, of using a "?" modifier to force SPF Neutral > >> instead of Pass, seems to lack both awareness and implementation, > >> since it was not even mentioned in the research document as a > >> mitigation. > > > >spf specs have desided to allow +all and unlimited numbers of ips, there > is no way to stop it unless rfc changes it > > > >even "v=spf1 ip4:0.0.0.0/0 -all" is fully valid > > > >for maillist is never being dmarc aligned anyway, but direct could be > aligned, if not a forwarding host does something, with or without srs > > > >maybe rfc wise it could help to have a max ips to get spf pass ? > > > There's no point. As has been discussed for probably 20 years, as soon as > you special case any of these kinds of records, people will move to > slightly more obscure ways to get the same results. > > From a protocol perspective there's no surprise here. The security > considerations of RFC 4408 explicitly warned about shared infrastructure > risks. The challenge is that no one cared. There's no doubt a business > opportunity here, but I expect no one will pursue it since it doesn't > require AI. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc