On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote: > On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman <skl...@kitterman.com> > > wrote: > > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > > > NEW > > > > > > 5.5.6. Decide If and When to Update DMARC Policy > > > > > > Once the Domain Owner is satisfied that it is properly authenticating > > > all of its mail, then it is time to decide if it is appropriate to > > > change the p= value in its DMARC record to p=quarantine or p=reject. > > > Depending on its cadence for sending mail, it may take many months of > > > consuming DMARC aggregate reports before a Domain Owner reaches the > > > point where it is sure that it is properly authenticating all of its > > > mail, and the decision on which p= value to use will depend on its > > > needs. > > > > > > It is important to understand that many domains may never use > > > policies of “quarantine” or “reject”, and that these policies are > > > intended not as goals, but as policies available for use when they > > > are appropriate. In particular, “reject” is not intended for > > > deployment in domains with users who send routine email, and its > > > deployment in such domains can disrupt indirect mail flows and cause > > > damage to operation of mailing lists and other forwarding services. > > > This is discussed in [RFC7960] and in Section 5.8, below. The > > > “reject” policy is best reserved for domains that send only > > > transactional email that is not intended to be posted to mailing > > > lists. > > > > > > To be explicitly clear: domains used for general-purpose email MUST > > > NOT deploy a DMARC policy of p=reject. > > > > > > END > > > > [snip] > > > > How about, "... MUST NOT deploy a DMARC policy other than p=none because > > improper used of p=reject or (to a slightly lesser exent) p=quarantine is > > extremely harmful to email interoperability." > > Or, "...MUST NOT deploy a DMARC policy other than p=none because > improper use of p=reject or (to a slightly lesser extent) p=quarantine is > extremely harmful to email interoperability. Such improper use includes, > but is not limited to, cases where the mitigation strategies discussed in > RFCs 7960 and 8617 and elsewhere are not deployed for the mail flows > in question and cases where the domain owner deems the collateral damage > as acceptable loss in service of protecting its domain from unauthorized > usage." > > I suspect that my text above won't go over well, but the use of the term > "improper use" smacks, to me, of the IETF being the protocol police, and > I've been led to believe that's not what we do here. > > There are many things I believe, and two of them are these: > > 1. Any domain is a target to be spoofed > 2. The custodian of a thing has the autonomy to do with that thing what > they please, so long as it's within the limits of the law. "My network, > my rules" as it were (or "Your network, your rules") > > DMARC is a tool in the fight against exact-domain spoofing, but some > methods of its deployment can cause interoperability issues. I believe that > as long as the risks are well understood and fully documented (to include > references to mitigation strategies) then a domain owner will have all the > information they need to make their choice as to what policy to deploy. To > mandate that certain classes of domains not do something (and just how do > we define "general-purpose" email anyway?) seems a bridge too far for me.
I agree with your items 1 and 2. I'm not a particular fan of improper use either. Maybe instead of improper use. Maybe just "use with such domains". Your characterization reads more like SHOULD NOT unless .... I don't think that unless [list of things that are only true in very limited circumstances and can't really be verified reliably] is very useful. How about this instead (I am attempting to split the difference between assuming p=reject is okay is normal or exceptional): "...MUST NOT deploy a DMARC policy other than p=none because use of p=reject or (to a slightly lesser extent) p=quarantine for such domains is extremely harmful to email interoperability. Mitigation strategies are discussed in [RFC 7960] and [RFC 8617]." I don't think we need to reiterate what p=reject does here, that's extensively addressed elsewhere in the document. I don't think we have enough data to opine either way about the effectiveness of such strategies, so it's enough to point at them here. We don't currently list RFC 8617 as a reference. I think introducing an informative reference here is useful. It's experimental, so we definitely don't want to put any normative language around it. I suspect that's probably not what you would find ideal (it's not what I would find ideal either, but I can live with it). Can you live with it? What do others think? Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
