That's a circle argument, as long as there is a Receiver that's needs SPF, the sender will not disable it.
/ Tobias Am 08.06.23, 16:51 schrieb "dmarc im Auftrag von Scott Kitterman" <dmarc-boun...@ietf.org <mailto:dmarc-boun...@ietf.org> im Auftrag von skl...@kitterman.com <mailto:skl...@kitterman.com>>: 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 <mailto: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 ><mailto: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 >> <mailto: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 >>> <mailto: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 <mailto: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 >>>>> <mailto:superu...@gmail.com>> >>>>> wrote: >>>>> >>>>>> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula <tobias.herkula= >>>>>> 401und1...@dmarc.ietf.org <mailto: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 <mailto:dmarc@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/dmarc >>>>>> <https://www.ietf.org/mailman/listinfo/dmarc> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Seth Blank * | Chief Technology Officer >>>>> *e:* s...@valimail.com <mailto: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 <mailto:dmarc@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/dmarc >>>>> <https://www.ietf.org/mailman/listinfo/dmarc> >>>>> >>>> _______________________________________________ >>>> dmarc mailing list >>>> dmarc@ietf.org <mailto:dmarc@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/dmarc >>>> <https://www.ietf.org/mailman/listinfo/dmarc> >>>> >>> -- > >*Seth Blank * | Chief Technology Officer >*e:* s...@valimail.com <mailto: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 <mailto:dmarc@ietf.org> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc> _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
