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. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
