Seth Blank writes: > 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."
I do not think the text above is more accurate, I think is mostly wrong. The current text in the draft is correct (or even better would be to say MUST NOT, but I think we lost that consensus call). The only reason intermediaries might be considered to be "spoofing" anything is because of the use of SPF. It is completely possible to implement mail forwarding which keeps DKIM valid, thus DMARC is still fine, but there is no way to keep SPF valid, and as not everybody implement DKIM this will cause mails to be rejected. But we lost that battle to remove SPF in the dmarcbis too... I think we should keep the current text. > 3. 4.4. Identifier Alignment Explained > > 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 myself would like to get both SPF and strict alignment to be removed from the draft. Some adminstrators are still going to use the SPF regardless what DMARC says, and some of them are already using it before DMARC which means they do not care about DMARC they only care about SPF, and there is nothing we can do for them (execpt we could say they are not compliant with DMARC). > 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. My understanding is that with tree walk and psd=n for the "strict" domain will allow those who want to enforce strict alingment to do so, so there is no point of having two different ways in the draft to archieve same result. I.e., if you want strict alignment, for domain a.mail.example.com, simply publish DMARC record for _dmarc.a.mail.example.com which has psd=n and that will provide you strict alignment. -- kivi...@iki.fi _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
