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

[Douglas Foster]

My Data:

Data set: 360,000 messages.
Scope notes:
1) Data is based on messages that passed successfully through sender
filtering.   I don't' care whether a sender authenticates when I know that
I don't want his messages at all.
2) A DMARC-inspired authenticate test is applied to all messages, so this
data is not limited to policy-publishing domains

Successful Verification Rates based on verification method
-
DKIM & SPF : 54.6%
DKIM-only: 14.5%
SubTotal : 69.1% have DKIM-verified FROM addresses.  This is consistent
with Tobias's data

SPF-aligned: 14.5%   This is much higher than what Tobias reported, but his
data probably includes a mix of spam and non-spam
SubTotal : 83.6%  (Messages with a verified FROM address using SPF and DKIM
together)

SPF-local:  8.5% (SPF Pass but not aligned, yet FROM is trusted using local
policy)
Total  92.1% of all messages have a FROM address that  I consider
acceptably verified.

I had an experience where dual-authentication was useful.  A software
update caused my MTA to "forget" its DKIM configuration.The fix
required generating a new key pair, publishing the public key, and hoping
that DNS propagated quickly to those who needed it.I was glad for
SPF-aligned authentication during the interim between when the problem was
introduced and the fix was propagated.

We have two topics intermixed:  (a) should we deprecate SPF for DMARC
purposes, and (b) should we deprecate SPF completely.   We should
definitely not deprecate SPF completely.In my experience, filtering
software collects all of its data before making any decisions, rather than
interleaving the data collection process with the filtering process for the
purpose of minimizing data collection effort.   DMARC reporting and ARC
Sets seem to depend on filters behaving in this way.  So, even if DMARC
drops SPF, I don't think there will be a measurable benefit to DNS
workload, because SPF is useful for other purposes.

I do think readers would benefit from a frank discussion about the SPF
risks associated with shared tenancy and excessive inclusion.   They should
understand that removing SPF policies, and depending on DMARC alone, can be
a successful way to manage those risks.

Doug Foster


On Thu, Jun 8, 2023 at 10:21 AM Murray S. Kucherawy 
wrote:

> On Thu, Jun 8, 2023 at 6:00 AM 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

The data I have seen (and it sounds like Mike is saying the same thing) shows 
DKIM verification results are less than 100%, consistently, for direct 
connections.  It was always lower than the SPF pass rate for hosts listed in a 
domain's SPF record.  I understand that in theory, it shouldn't matter, but in 
practice it is.

Software engineering isn't a perfect science.  In general, a more complex 
protocol will suffer more defects.  If you want to design things that only work 
when software is perfect, I'm not interested.

In terms of utility for direct connections, I think having both helps and I 
don't find claims the SPF can never pass when DKIM fails to be credible.  If 
someone has data that shows that's true now, I'd be interested to see it (my 
experience is a few years ago, so things may have changed).

Ultimately, I think SPF and DKIM both suffer from what I'll genetically call 
data hygiene problems.  SPF is mostly adding third party providers who are 
insufficiently careful (might not even care, I don't know) generating SPF pass 
results for "bad" mail.  DKIM is mostly about replay attacks.  Neither of these 
are protocol problems and I don't think support dumping one or the other out of 
DMARC.

One could make the opposite argument too, and I think it would be equally valid:

The only value DKIM brings for DMARC is for indirect mail flows.  For any 
direct connections, SPF is sufficient.  All the proposed DKIM changes to solve 
the DKIM replay problem are likely to break indirect mail flows anyway, so 
there's no longer a point to keep DKIM.  It's much more complicated and it 
looks like the benefit of it is going away, let's just simplify the protocol 
and get rid of it.

Now, I think that's a bad argument, but I don't think it's any worse than the 
argument being presented to get rid of SPF.

Scott K

On June 8, 2023 10:26:59 PM UTC, Barry Leiba  wrote:
>> There are DKIM verification failures for reasons unrelated to DNS failures.  
>> As an example, I
>> recently fixed a DKIM validation bug in the library I maintain which was 
>> causing a small fraction
>> of valid signatures to fail verification since at least 2011.  SPF + DKIM 
>> reduces DMARC failures.
>
>Oh, well, I don't buy this one at all: My software might have bugs, so
>I have to use multiple mechanisms?  No, you have to fix the software.
>"Software might have bugs" is not a reason to put extra complexity
>into a protocol.
>
>Would you suggest including two DKIM signatures using different crypto
>suites in order to work around possible software bugs?  Would you
>suggest putting that into the protocol definition?
>
>> It's true that SPF is not particularly helpful for indirect mail flows, but 
>> I read your message as claiming
>> using SPF with DKIM causes DMARC verification to be worse for indirect mail 
>> flows than when using
>> DKIM alone.  Is that right?
>
>What I said was that there is no case where DKIM will fail and SPF
>will succeed.  I stand by that statement.  Can you describe a scenario
>that breaks DKIM but has SPF still work?
>
>That's assuming the software is working right and one hasn't
>configured it wrong, both of which should be fixed.  And if you can't
>retrieve a needed DNS record, you need to wait and retry, not try to
>put unnecessary redundancy into the protocol.  Unless, of course, you
>can show that DKIM is significantly more likely to fail for that
>reason than SPF is.
>
>The other thing I said about SPF is that there are cases now where the
>SPF records required by the use of major service providers are so
>bloated and contain so many IP addresses that they allow spammers who
>use those same services to spoof any other customer of the service.
>That makes SPF validation weak.  As there's no benefit to it over
>DKIM, I don't understand why we'd want to keep it.
>
>We needed SPF when DKIM was less widely deployed.  We thought it was
>more useful when we hadn't seen how often it breaks compared with
>DKIM.  And one advantage that SPF had -- that it allowed you to reject
>a message during the SMTP negotiation, before the DATA command was
>accepted -- can't be used if you need to check DKIM as well.
>
>Barry
>
>___
>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

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

[Barry Leiba]

> There are DKIM verification failures for reasons unrelated to DNS failures.  
> As an example, I
> recently fixed a DKIM validation bug in the library I maintain which was 
> causing a small fraction
> of valid signatures to fail verification since at least 2011.  SPF + DKIM 
> reduces DMARC failures.

Oh, well, I don't buy this one at all: My software might have bugs, so
I have to use multiple mechanisms?  No, you have to fix the software.
"Software might have bugs" is not a reason to put extra complexity
into a protocol.

Would you suggest including two DKIM signatures using different crypto
suites in order to work around possible software bugs?  Would you
suggest putting that into the protocol definition?

> It's true that SPF is not particularly helpful for indirect mail flows, but I 
> read your message as claiming
> using SPF with DKIM causes DMARC verification to be worse for indirect mail 
> flows than when using
> DKIM alone.  Is that right?

What I said was that there is no case where DKIM will fail and SPF
will succeed.  I stand by that statement.  Can you describe a scenario
that breaks DKIM but has SPF still work?

That's assuming the software is working right and one hasn't
configured it wrong, both of which should be fixed.  And if you can't
retrieve a needed DNS record, you need to wait and retry, not try to
put unnecessary redundancy into the protocol.  Unless, of course, you
can show that DKIM is significantly more likely to fail for that
reason than SPF is.

The other thing I said about SPF is that there are cases now where the
SPF records required by the use of major service providers are so
bloated and contain so many IP addresses that they allow spammers who
use those same services to spoof any other customer of the service.
That makes SPF validation weak.  As there's no benefit to it over
DKIM, I don't understand why we'd want to keep it.

We needed SPF when DKIM was less widely deployed.  We thought it was
more useful when we hadn't seen how often it breaks compared with
DKIM.  And one advantage that SPF had -- that it allowed you to reject
a message during the SMTP negotiation, before the DATA command was
accepted -- can't be used if you need to check DKIM as well.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On June 8, 2023 8:35:24 PM UTC, Barry Leiba  wrote:
>> A sender using both SPF and DMARC will see a slight
>> boost in validation rates due to increased resiliency when there are
>> transient DNS failures and other problems.
>
>Do you mean "both SPF and DKIM", perhaps?
>
>I don't see how that makes sense: if there's a transient DNS failure,
>then neither the SPF nor the DKIM (nor the DMARC) records can be
>retrieved.
>
>I also don't see how using an unreliable mechanism is a benefit.  It
>demonstrably hurts validation rates related to relayed/forwarded mail,
>and can cause *false* validations in cases of overly-broad SPF
>configurations (as when a large provider that also hosts many spammers
>is used).

I'm pretty sure he meant SPF and DKIM.  His statement is consistent with my 
observations.

There are DKIM verification failures for reasons unrelated to DNS failures.  As 
an example, I recently fixed a DKIM validation bug in the library I maintain 
which was causing a small fraction of valid signatures to fail verification 
since at least 2011.  SPF + DKIM reduces DMARC failures.  

It's true that SPF is not particularly helpful for indirect mail flows, but I 
read your message as claiming using SPF with DKIM causes DMARC verification to 
be worse for indirect mail flows than when using DKIM alone.  Is that right?  
If so, please expand on that because I don't understand it.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Thu, Jun 8, 2023 at 4:35 PM Barry Leiba  wrote:

> > A sender using both SPF and DMARC will see a slight
> > boost in validation rates due to increased resiliency when there are
> > transient DNS failures and other problems.
>
> Do you mean "both SPF and DKIM", perhaps?
>

My bad. I responded while in the middle of something else. Proof that one
should always proof read before hitting send.

>
> I don't see how that makes sense: if there's a transient DNS failure,
> then neither the SPF nor the DKIM (nor the DMARC) records can be
> retrieved.
>

One example is where there are a pool of DNS servers. One server in a pool
might have an issue while others are fine. All the lookups do not
necessarily hit the same server. You also don't factor in cached results
for SPF as well as potentially different TTLs for those results.

>
> I also don't see how using an unreliable mechanism is a benefit.  It
> demonstrably hurts validation rates related to relayed/forwarded mail,
> and can cause *false* validations in cases of overly-broad SPF
> configurations (as when a large provider that also hosts many spammers
> is used).
>

It's all in the mail flow and configurations. YMMV. I was dealing almost
overwhelmingly with transactional emails in a well configured environment
(from the day that DMARC was originally published we were at p=reject)).
Yes, we had to fix some things beforehand. I strongly believe that the 2
biggest problems with setting up email authentication as a sender is that
people don't put much thought into it and in many cases they deploy when
their hair is on fire.

Michael Hammer

>
> Barry
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Barry Leiba]

> A sender using both SPF and DMARC will see a slight
> boost in validation rates due to increased resiliency when there are
> transient DNS failures and other problems.

Do you mean "both SPF and DKIM", perhaps?

I don't see how that makes sense: if there's a transient DNS failure,
then neither the SPF nor the DKIM (nor the DMARC) records can be
retrieved.

I also don't see how using an unreliable mechanism is a benefit.  It
demonstrably hurts validation rates related to relayed/forwarded mail,
and can cause *false* validations in cases of overly-broad SPF
configurations (as when a large provider that also hosts many spammers
is used).

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Thu, Jun 8, 2023 at 10:44 AM Barry Leiba  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.
>

That might be true but does not address whether or not SPF is/can be useful
in the context of DMARC validation.


>
> 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.
>

I'm going to disagree with you on this, having experience with billions of
emails sent with both SPF and DKIM used in the context of DMARC validation.
A sender using both SPF and DMARC will see a slight boost in validation
rates due to increased resiliency when there are transient DNS failures and
other problems. A small percentage of a very large number is still a large
number. Let's not throw the baby out with the bath water.

>
> Barry, as participant
>

Michael Hammer


>
> On Thu, Jun 8, 2023 at 3:30 PM Seth Blank  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 
>> wrote:
>>
>>> On Thu, Jun 8, 2023 at 6:00 AM 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Hector Santos]

> On Jun 8, 2023, at 10:20 AM, Murray S. Kucherawy  wrote:
> 
> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 
> 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? 
> 



Thank you for inviting feedback on Mr. Herkula's interesting DMARC2 proposal, 
focusing on detaching SPF from DMARC's evaluation process. I would like to 
share my thoughts on this matter.

While the principle behind the proposed DMARC2 is valuable, I remain sceptical 
about the effectiveness of separating SPF from DMARC to alleviate DNS load. For 
various reasons, notably the layer issue – SPF being an SMTP protocol rather 
than a payload protocol – SPF is unlikely to be fully discarded.

It's worth recalling that SPF's contribution has served the email community 
well, despite certain node transition issues such as relays and forwards. The 
optional integration of SPF within DMARC1 from the onset might have simplified 
the process, mitigating the challenges associated with the merged results and 
reducing the occurrence of false positives, which in many cases has begun to 
give domains a second thought on using p=reject|quarantine policies. 

A potential DMARC2 proposal should, in my opinion, maintain backward 
compatibility, making SPF an optional requirement.  The real gap with DMARC1 
has been the lack of diversity in policies, and effectively, the DMARC2 
proposal could add a new "policy" that doesn't require SPF evaluation.

For context, we've amassed nearly two decades worth of data on SPF, DKIM, ADSP, 
and DMARC, providing considerable insight into the longevity and effectiveness 
of these measures.

It's crucial to establish that SPF was deliberately designed to, and in many 
cases will, use a HARDFAIL result to preempt payload transfer or its acceptance 
(at DATA). This is precisely why the SUBMITTER add-on ESMTP protocol was 
introduced as part of SenderID – the payload version of SPF – to relay the 
Purported Responsible Address (PRA) at the SMTP MAIL FROM command.

By reviving the SUBMITTER protocol for DMARC purposes, servers/receivers can 
check the DMARC policy at SMTP, offering valuable foresight into the email 
domain's expectations prior to payload delivery. This approach allows for a 
more optimized process, ensuring that SPF is evaluated at MAIL FROM or RCPT TO, 
once the recipient address's acceptability is established per RFC 5321, Section 
3.3 Mail Transactions' recommendations.

It's important to note that SPF-compliant servers – as evidenced recently by 
gmail.com – can reject SPF failures at SMTP independent of DMARC. For domains 
using SPF hard failures (-ALL), DMARC is not mandatory and in many cases, a 
hard SPF policy vs hard  DMARC policies are mutual exclusive.  Odds are good, 
if SPF was disabled, DMARC2 could yield the same way. I suggest that the 
proposed DMARC2 revisit the coupling of SOFTFAIL SPF results with DMARC2 policy 
analysis.  

While DMARC has introduced complexities and some uncertainty, my recent 
analysis reveals that domains without DMARC, but implementing hard SPF 
policies, experienced minimal issues, except for gmail.com domain members. The 
problem appears to be more prominent with ESPs, particularly those with a 
lenient DMARC p=nonen since ESPs with strong policies are restricted from 
subscriptions and submissions.

In conclusion, the evolution to a DMARC2 should focus on addressing these 
concerns, potentially including a "rewrite=1" option to mailing lists with 
appropriate permissions. This could potentially make it more palatable to 
modify the author's address, while respecting the hard-won email security 
principles.

Thanks

---
Hector Santos
Santronics Software,Inc.












___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Hector Santos]

My #1 concern is how the bigger ESP is contributing to the delivery problems, 
causing chaos for business users and customer relationship problems with mail 
hosting provider  I am seeing uncertainty and inconsistency among different 
receivers with ESP gmail.com seems to be the most aggressive and I am seeing 
the bigger ESPs using different methods, including proprietary methods.

As a sideline note, I will venture email overhead has skyrocketed to a new 
level of hard to follow headers for tech support. I don’t think we can continue 
down this path in the name of trying to get DMARC as apart of everyone’s domain 
when in fact, it is unfortunately becoming more apparent, a domain may be is 
better off with no DMARC record, not even p=none may help. Using SPF is good 
enough it seems.

—
HLS

> On Jun 8, 2023, at 11:02 AM, Barry Leiba  wrote:
> 
> I disagree with the premise (the last sentence of your first paragraph).  
> Broken or ineffective authentication is worse than none, because it causes 
> deliverability problems.  I’d rather have no authentication and rely on other 
> means of filtering.
> 
> Barry
> 
> On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  > 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 > > 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 
>>> 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 >>> > wrote:
> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 
>  > 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 opti

Re: [dmarc-ietf] version bump to DMARC2

[John Levine]

It appears that Tobias Herkula   said:
>However, such a fundamental shift in the protocol's architecture warrants a 
>clear signifier. I suggest we upgrade
>our DMARC version string from the current state to 'DMARC2.' This upgrade 
>would not only denote the change of SPF
>removal, but also the switch from the Public Suffix List (PSL) to the 
>Tree-Walk algorithm.

I was talking with someone from a Very Large Mail Provider who told me that
if we keep the same version number, they won't change what they do now, so
no tree walk even if we keep SPF.

They understand that as things stand now, the results of the PSL and
the tree walk are in practice the same. Their concern is that if some
people do it the old way and some the new, and you can't tell which
the domain expects, bad guys will create records with deliberately
inconsistent results.

I'm not sure how likely that is, but arguing with a gorilla rarely
turns out well.  I will see if I can talk to people at other VLMPs
and see how widespread this concern is.

R's,
John

PS: If we do bump the version number, it needs to go into the
aggregate reports, too.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Benny Pedersen]

Scott Kitterman skrev den 2023-06-08 17:50:
Isn't the way to say I don't use SPF for DMARC to not publish an SPF 
record?


maybe "v=spf1 +all"

or just something like over x numbers of ips, will trigger in dmarc not 
using spf ?


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Tobias Herkula]

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" 
mailto:dmarc-boun...@ietf.org> im Auftrag von 
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 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 > 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 > > 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 >> >
>>> 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 >>> 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  >
> wrote:
>
>> On Thu, Jun 8, 2023 at 6:00 AM 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, 

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

[Barry Leiba]

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  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  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  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  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 
> >>> 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   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  >> 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 a

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

[Seth Blank]

It’s not that simple for larger organizations, because of how distributed
control of subdomains can be. You’d want to set an organizational policy to
disallow SPF on the org domain.

The problem with SPF is shared services. This has become so bad recently as
to render many of the valuable bits of SPF more problematic.

I’m in general agreement with you that SPF and DKIM work in concert, and
you can’t just look at them in isolation. Even small percentages in email
represent billions of messages, as we all know from mailing list damage
from DMARC being “less than a percent.”

On Thu, Jun 8, 2023 at 16:51 Scott Kitterman  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  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  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  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 
> >>> 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   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  >> 401und1...@d

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

[Scott Kitterman]

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  
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  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  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 
>>> 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 >>> 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 
> wrote:
>
>> On Thu, Jun 8, 2023 at 6:00 AM 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.

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

[Scott Kitterman]

On June 8, 2023 2:20:44 PM UTC, "Murray S. Kucherawy"  
wrote:
>On Thu, Jun 8, 2023 at 6:00 AM 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?
>
I don't have data, but I do have a different view on how to frame the data.

We've expended a lot of cycles in this working group on trying to figure out 
how to make DMARC more reliable because it is not sufficiently so for all 
domains to publish a restrictive DMARC policy (in fact, progress in the working 
group is currently blocked on the question of how to describe this).

I don't think DMARC has a surplus of reliability such that we should think 
about giving some of it away voluntarily.  I submit that this 1.6% is not 
"mere", it's huge.

What do I mean by that?  That 1.6% will include both domains which use SPF 
alone and which use both SPF and DKIM.  DKIM is not perfect.  When I did have 
access to relevant data, I recall seeing typical DKIM verification rates for 
direct mail typically between 99.2% and 99.8%.  It was never 100%.  For SPF, 
when the SPF record was correct, it was almost always 100%.  Based on this 
historical experience, I suspect that a significant fraction of that 1.6% are 
cases like this where SPF saves the DMARC result when DKIM has failed.  

For the overall protocol, DKIM and SPF are complementary.  While an estimated 
0.5% drop in DMARC failures may not seem like much, I think it's a lot and we 
don't have a surfeit of reliability that we should give some away.

I suspect that the real driver here is senders allowing too much "bad" mail to 
get an SPF pass (I have also seen, but do not have access to, data that 
indicates this is the case).  DKIM has similar problems (see the recent DKIM 
working group discussions on replay attacks).  I think working on that problem 
(SPF/DKIM pass rates for "bad" mail) is where the focus should be.

Not a DMARC working group issue.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Tobias Herkula]

If we move to DMARC2 version string this would be solved easily, we could add 
the requirement to the tree-walk algo, we fallback to DMARC1 records if the 
tree-walk does not find a DMARC2 one. So, the long-tail can continue running in 
their current environment and upgrade on their own pace to the next DKIM only 
DMARC.

/ Tobias

Von: Seth Blank 
Datum: Donnerstag, 8. Juni 2023 um 16:35
An: Barry Leiba 
Cc: Seth Blank , Tobias Herkula , 
"dmarc@ietf.org" 
Betreff: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

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 
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 
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 
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 
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 
mailto:superu...@gmail.com>> wrote:
On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 
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 questio

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

[Seth Blank]

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  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  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 
>> 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 >> 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 
 wrote:

> On Thu, Jun 8, 2023 at 6:00 AM 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 
>> 

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

[Barry Leiba]

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  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 
> 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 > 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 
>>> wrote:
>>>
 On Thu, Jun 8, 2023 at 6:00 AM 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, cop

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

[Barry Leiba]

I disagree with the premise (the last sentence of your first paragraph).
Broken or ineffective authentication is worse than none, because it causes
deliverability problems.  I’d rather have no authentication and rely on
other means of filtering.

Barry

On Thu, Jun 8, 2023 at 3:54 PM Seth Blank  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 
> 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 > 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 
>>> wrote:
>>>
 On Thu, Jun 8, 2023 at 6:00 AM 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
>>

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

[Seth Blank]

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  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  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 
>> wrote:
>>
>>> On Thu, Jun 8, 2023 at 6:00 AM 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman

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

[Barry Leiba]

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  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 
> wrote:
>
>> On Thu, Jun 8, 2023 at 6:00 AM 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

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

[Seth Blank]

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 
wrote:

> On Thu, Jun 8, 2023 at 6:00 AM 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

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

[Murray S. Kucherawy]

On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula  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

[dmarc-ietf] DMARC2 & SPF Dependency Removal

[Tobias Herkula]

Hi All,

This message comes out of some discussions I had at the current MAAWG meeting 
in Dublin.

I hope this message finds you well. The intent of this is to propose and 
discuss an evolutionary step in the DMARC protocol, which I believe will result 
in increased efficiency, reduced DNS load, and a more accurate reflection of 
the current email landscape.

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.

However, such a fundamental shift in the protocol's architecture warrants a 
clear signifier. I suggest we upgrade our DMARC version string from the current 
state to 'DMARC2.' This upgrade would not only denote the change of SPF 
removal, but also the switch from the Public Suffix List (PSL) to the Tree-Walk 
algorithm.

By moving towards DMARC2, we not only update our standard to better reflect our 
present requirements, but we also make a clear commitment to the ongoing 
evolution and improvement of the protocol.

Best regards,

Tobias Herkula
Mail Security & Transfer
1&1 (GMX, Web.de, Mail.com, IONOS)
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc