That would be how a sender says it, yes. The proposal we’re discussing is not to leave it up to the sender, but to tell the validator, as part of the DMARC protocol, not to evaluate SPF for the purpose of DMARC.
BARRY On Thu, Jun 8, 2023 at 4:51 PM Scott Kitterman <skl...@kitterman.com> wrote: > Isn't the way to say I don't use SPF for DMARC to not publish an SPF > record? > > Scott K > > On June 8, 2023 3:35:38 PM UTC, Seth Blank <seth= > 40valimail....@dmarc.ietf.org> wrote: > >I’ll bring data. I think there’s a practical problem here and a class of > >services that are not email-first which will break completely (ie get > >immediately rejected) were such a change to be made. > > > >This feels like a significant interoperability problem we’d be > introducing. > > > >I’m loathe to add flags when we’ve been so good at simplifying DMARC > >through the bis process and removing flags, but what about a way to say “I > >only send with DKIM, and do not evaluate SPF on my behalf”? > > > >That wouldn’t create an interop problem, and gives a path to upgrade > >without creating breaking change out of the gate? > > > >Seth > > > >On Thu, Jun 8, 2023 at 16:05 Barry Leiba <barryle...@computer.org> wrote: > > > >> Oh, and as to your last paragraph, I think it’s the wrong question. > What > >> we need to understand is that SPF is ineffective, and DKIM is what’s > >> necessary to make DMARC work effectively. When we started, DKIM was > not as > >> broadly deployed and we didn’t understand how bad SPF would be. We have > >> different information now, and we need to say that of you want to > reliably > >> authenticate you have to use DKIM… that’s it. > >> > >> Barry > >> > >> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank <s...@sethblank.com> wrote: > >> > >>> Participating, while running around so apologies for terseness: > >>> > >>> Sophisticated senders do DKIM. The long tail, we're lucky if they do > SPF. > >>> Some authentication is better than none. > >>> > >>> The problem isn't people evaluating SPF vs DKIM and choosing the easier > >>> option. It's people who have a business, who bolt on email, and then > >>> struggle to authenticate through any means. Again, we're lucky when we > get > >>> SPF from them, and I'll still take that over no auth all day every day. > >>> > >>> Don't disagree at all with the myriad problems with SPF, and that the > >>> goal should be to eliminate it. I just don't believe we're anywhere > close > >>> to that being a reality yet. > >>> > >>> The data that led to DMARC showed that SPF and DKIM were both necessary > >>> to determine legitimacy broadly. What would we need to understand now > to > >>> see if only DKIM is necessary? > >>> > >>> On Thu, Jun 8, 2023 at 3:44 PM Barry Leiba <barryle...@computer.org> > >>> wrote: > >>> > >>>> See, I don't look at it as "harmed". Rather, I think they're using > "we > >>>> use SPF" as a *reason* not to use DKIM, and I think that *causes* > harm. > >>>> > >>>> SPF is, as I see it, worse than useless, as it adds no value to domain > >>>> that use DKIM -- any time DKIM fails SPF will also fail -- and > actually > >>>> impedes the adoption of DKIM. Reliance on SPF causes DMARC failures > that > >>>> result in deliverability problems for legitimate mail. I > wholeheartedly > >>>> support removal of SPF as an authentication mechanism that DMARC > accepts. > >>>> > >>>> Barry, as participant > >>>> > >>>> On Thu, Jun 8, 2023 at 3:30 PM Seth Blank <seth= > >>>> 40valimail....@dmarc.ietf.org> wrote: > >>>> > >>>>> Participating, I have data that I believe points to a long tail of > >>>>> businesses who predominantly only authenticate on behalf of others > using > >>>>> SPF, and would be harmed by such a change. It will take me a little > while > >>>>> to confirm and share. > >>>>> > >>>>> I also know a predominant ccTLD with millions of registrations, that > >>>>> has SPF on roughly 80% of them, but DMARC on barely 5%. I don't have > data > >>>>> on DKIM for those, but I assume it's closer to the DMARC penetration > than > >>>>> the SPF one. I'll see if I can get this data to share more > publically, and > >>>>> also get the DKIM answer. > >>>>> > >>>>> Of course the goal is aligned dkim with a stated policy, but I don't > >>>>> think the data supports us being anywhere close to that > realistically. > >>>>> > >>>>> As Chair, this is a valuable conversation to have with real data on > >>>>> problems and opportunities at scale, and am excited to see Tobias > share and > >>>>> see what others have to say. > >>>>> > >>>>> Seth > >>>>> > >>>>> On Thu, Jun 8, 2023 at 3:21 PM Murray S. Kucherawy < > superu...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula <tobias.herkula= > >>>>>> 401und1...@dmarc.ietf.org> wrote: > >>>>>> > >>>>>>> My team recently concluded an extensive study on the current use > and > >>>>>>> performance of DMARC. We analyzed a staggering 3.2 billion emails, > and the > >>>>>>> insights drawn are quite enlightening. Of these, 2.2 billion emails > >>>>>>> (approximately 69%) passed the DMARC check successfully. It's > quite an > >>>>>>> achievement, reflective of our collective hard work in fostering a > safer, > >>>>>>> more secure email environment. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> However, upon further analysis, it's evident that a mere 1.6% (or > >>>>>>> thirty-six million) of these DMARC-passed emails relied > exclusively on the > >>>>>>> Sender Policy Framework (SPF) for validation. This is a remarkably > low > >>>>>>> volume compared to the overall DMARC-passed traffic, raising > questions > >>>>>>> about SPF's relevancy and the load it imposes on the DNS systems. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Given the current use case scenarios and the desire to optimize our > >>>>>>> resources, I propose that we explore the possibility of removing > the SPF > >>>>>>> dependency from DMARC. This step could result in a significant > reduction in > >>>>>>> DNS load, increased efficiency, and an accurate alignment with our > >>>>>>> predominant use cases. > >>>>>>> > >>>>>>> [...] > >>>>>>> > >>>>>> > >>>>>> Does anyone have consonant (or dissonant) data? > >>>>>> > >>>>>> -MSK, participating > >>>>>> _______________________________________________ > >>>>>> dmarc mailing list > >>>>>> dmarc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/dmarc > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> *Seth Blank * | Chief Technology Officer > >>>>> *e:* s...@valimail.com > >>>>> *p:* 415.273.8818 > >>>>> > >>>>> This email and all data transmitted with it contains confidential > >>>>> and/or proprietary information intended solely for the use of > individual(s) > >>>>> authorized to receive it. If you are not an intended and authorized > >>>>> recipient you are hereby notified of any use, disclosure, copying or > >>>>> distribution of the information included in this transmission is > prohibited > >>>>> and may be unlawful. Please immediately notify the sender by > replying to > >>>>> this email and then delete it from your system. > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> -- > > > >*Seth Blank * | Chief Technology Officer > >*e:* s...@valimail.com > >*p:* 415.273.8818 > > > >This email and all data transmitted with it contains confidential and/or > >proprietary information intended solely for the use of individual(s) > >authorized to receive it. If you are not an intended and authorized > >recipient you are hereby notified of any use, disclosure, copying or > >distribution of the information included in this transmission is > prohibited > >and may be unlawful. Please immediately notify the sender by replying to > >this email and then delete it from your system. > > _______________________________________________ > 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
