There are three items in the document that have consensus, which I believe are wrong. I am in the rough on these, and not looking to relitigate them. I am hoping to provide text that clarifies concerns in a manner that leads consumers of the document to make better informed implementations, and I provide what I've previously shared to the list as rationale for the language but not as relitigation of the core topics.
In order from most to least contentious: 1. 8.6. Interoperability Considerations "It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish p=reject." While this advice represents consensus, it does not represent operational best practice, nor where the market is moving to stop fraud and abuse. DMARC is becoming increasingly required at the major mail receivers, and messages that cannot get a DMARC pass are increasingly likely to get rejected outright. This language feels like it is creating an even worse interoperability problem-- giving guidance to people that will guarantee their mail gets rejected by major mail systems. These DMARC mandates arose after consensus was called, and have changed the playing field materially. More accurate language that alleviates the concern would be "It is therefore critical that domains that host users who wish for their messages to be modified and spoofed by downstream intermediaries, such as alumni forwarders or mailing lists, SHOULD NOT publish p=reject. Such spoofed messages may still be rejected, regardless of a domain owner's published DMARC policy." When it comes to the Charter, the document is supposed to articulate how to address indirect mail flow, and this would be the place. Therefore, I believe it is also worthwhile in this section to reference both ARC, as well as other mechanisms that such breaking intermediaries that create new messages (and therefore spoof the sender) could undertake, such as From rewriting to properly claim ownership of the message, or not making changes to the message that invalidate DKIM. 2. 5.7.4. Send Aggregate Reports There are no protocol police, and implementers are free to follow or ignore normative guidance at their whim. For a domain owner, it is an interoperability problem to not receive reports, and therefore this meets the normative requirement to be a MUST. Smaller receivers are of course free to ignore this if the burden is too high, but that should be their guidance to ignore, not the document's duty to presuppose. Domain owners need reports, or they cannot put the work in to authenticate their mail and publish a policy that has an impact they can expect. So reports MUST be sent. Given the consensus around SHOULD, I'd recommend the following change: OLD: Given the above, to ensure maximum usefulness for DMARC across the email ecosystem, Mail Receivers SHOULD generate and send aggregate reports with a frequency of at least once every 24 hours. NEW: In order for domain owners to properly collect and analyze reports (section 5.5.5) in order to authenticate their mail and publish a policy if they wish (section 5.5.6), mail receivers need to supply those reports. To ensure maximum usefulness for DMARC across the email ecosystem, understanding that some receivers may find this an undue burden, Mail Receivers SHOULD generate and send aggregate reports with a frequency of at least once every 24 hours. 3. 4.4. Identifier Alignment Explained If we ever open alignment again for a future document, I hope we do away with strict alignment. It would also simplify the document and the examples greatly. Early on, consensus was that we should keep strict alignment, as it was used by a very small handful of organizations, but primary amongst them were some banks who took strict to mean more secure. Further details were discussed at the interim here: https://mailarchive.ietf.org/arch/msg/dmarc/PPskhJKs-cvXJpjzh-UiJQ9ba4M/ This decision to keep strict alignment made sense in isolation. Since then, we've discussed two other removals -- relying on SPF at all, and not worrying about mailing list traffic at all -- both of which affect more mailflow and deployment than strict alignment. If we're willing to seriously discuss things that affect more mail, should we not also review the need for strict alignment? I also don't think we really reviewed strict alignment after incorporating the tree walk into the document. Most of the uses for strict alignment were in the "I have a large organization, and want to make sure one part of the organization cannot spoof another" camp-- which now the tree walk should have provided a more scalable solution for. As was discussed during the interim, there is not operational practice that underscores strict alignment actually providing any real advantage. Practically speaking, almost no one uses strict alignment. And for those that do, it tends to be significantly more difficult to implement, for no actual benefit that's ever been presented to this working group. Further, there are many that look at "strict" as "better" and "more secure" and then find themselves unable to implement DMARC, when relaxed alignment would have actually given them everything they need and the protections they're looking for. At a minimum, I think the second paragraph of section 4.4 should be changed: OLD: The choice of relaxed or strict alignment is left to the Domain Owner and is expressed in the domain's DMARC policy record. NEW: The choice of relaxed or strict alignment is left to the Domain Owner and is expressed in the domain's DMARC policy record. In practice, nearly all domain owners have found relaxed alignment sufficient to meet their needs. Seth, as an individual, not trying to relitigate, just trying to clarify concerns, and not dying on any of these hills. -- Seth Blank | Chief Technology Officer Email: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
