On Tue, Dec 3, 2024 at 9:33 PM Douglas Foster < [email protected]> wrote:
> If this document is approved as a standard, will IETF implement the > standard? > Will it use DMARC to protect posts to their mailing lists? > Will it use publish p=reject? > > Which members of the consensus will be implementing this spec, as written, > within their organizations? > > Or is this about writing documents, rather than about improving the email > ecosystem? > > In my view, the IETF really is about writing documents; improving the email ecosystem is incidental to the task at hand, and only for some of the documents that the IETF produces, although it is a hoped-for goal of this particular document. An RFC is intended to serve as a reference document describing a given protocol or mechanism (we'll call it X) such that all who claim to implement X are doing so with a (hopefully) common understanding of X. RFCs are not the only source of such documents for this task; the CA/B Forum and W3C are two other examples of organizations that produce similar documents, albeit perhaps with different methods for doing so. There are well over 9,000 RFCs, and I daresay that the IETF has most likely not implemented all of them, mostly because many aren't applicable to the IETF as an organization. Long-time participants of the IETF are fond of saying that the IETF is not the "protocol police", and I think both RFC 7489 and DMARCbis reflect that ethos, specifically in the fact that neither require a receiving organization to honor a Domain Owner's handling policy (the p= flag) when a message fails DMARC validation checks. In addition, neither require a receiving organization to generate reports, nor do either require a Domain Owner to solicit reports. This, to me, makes your question regarding "implementing this spec, as written" a bit problematic, because there are many permutations of participating in DMARC on both sides of the email transaction. I think DMARCbis does a fine job of explaining how a Domain Owner can announce its participation in DMARC, how a Domain Owner's mail can be judged to pass or fail DMARC validation checks, and what consequences might await mail that fails such checks at receiving organizations that participate in DMARC and honor Domain Owner policies. The document notes that indirect flows can present challenges to DMARC validation checks getting a pass verdict, and these challenges have been part of the daily lives of mailing list operators for at least ten years, ever since yahoo.com first published p=reject, and maybe before then. Those who operate IETF mailing lists have implemented the per-address modifications that are mentioned in the next to last paragraph in section 7.4 - https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-36.html#name-interoperability-considerat - and thus protect list members from being unsubscribed due to bounces caused by failed DMARC validation checks at the downstream mailboxes. Whether or not they use DMARC to prevent forged posts to mailing lists, I cannot say. What I do know is that Gmail and Yahoo are both now requiring DMARC policies be published by Domain Owners for certain classes of email, and I expect those requirements to expand, not contract, over time. Those requirements are currently based on RFC 7489, and if DMARCbis is never officially published, they'll continue to be based on RFC 7489 until something better (for them) comes along. (Even if DMARCbis is officially published, those requirements will be based on RFC 7489 for whatever amount of time it takes for code libraries to be updated to implement the DNS Tree Walk and recognize the new tags in DMARC records.) So, for me, the question isn't "Will the IETF implement DMARC?"; rather, the question is "Will the IETF publish a reference for the mechanism upon which a majority of the world's daily mail flow does and will depend?" -- Todd Herr Some Guy in VA LLC [email protected] 703-220-4153 Book Time With Me: https://calendar.app.google/tGDuDzbThBdTp3Wx8
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
