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
