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

[Douglas Foster <[e-mail]>]

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 <[e-mail]>
wrote:

> On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula <tobias.herkula=
> [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]
> https://www.ietf.org/mailman/listinfo/dmarc
>