> On Jun 8, 2023, at 10:20 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 <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
