Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Tobias Herkula <[e-mail]>]

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" <[e-mail] <mailto:[e-mail]> im Auftrag von [e-mail] <mailto:[e-mail]>>:


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=[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>>> 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=
>>>> [e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula <tobias.herkula=
>>>>>> [e-mail] <mailto:[e-mail]>> 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
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Seth Blank * | Chief Technology Officer
>>>>> *e:* [e-mail] <mailto:[e-mail]>
>>>>> *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
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
>>>>>
>>>> _______________________________________________
>>>> dmarc mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
>>>>
>>> --
>
>*Seth Blank * | Chief Technology Officer
>*e:* [e-mail] <mailto:[e-mail]>
>*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
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>