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 <superu...@gmail.com> wrote: > On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula <tobias.herkula= > 401und1...@dmarc.ietf.org> wrote: > >> My team recently concluded an extensive study on the current use and >> performance of DMARC. We analyzed a staggering 3.2 billion emails, and the >> insights drawn are quite enlightening. Of these, 2.2 billion emails >> (approximately 69%) passed the DMARC check successfully. It's quite an >> achievement, reflective of our collective hard work in fostering a safer, >> more secure email environment. >> >> >> >> However, upon further analysis, it's evident that a mere 1.6% (or >> thirty-six million) of these DMARC-passed emails relied exclusively on the >> Sender Policy Framework (SPF) for validation. This is a remarkably low >> volume compared to the overall DMARC-passed traffic, raising questions >> about SPF's relevancy and the load it imposes on the DNS systems. >> >> >> >> Given the current use case scenarios and the desire to optimize our >> resources, I propose that we explore the possibility of removing the SPF >> dependency from DMARC. This step could result in a significant reduction in >> DNS load, increased efficiency, and an accurate alignment with our >> predominant use cases. >> >> [...] >> > > Does anyone have consonant (or dissonant) data? > > -MSK, participating > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
