There may need to be a bit more clarification around the use of sp= in these cases. "We are telling you that p=reject is harmful, but sp=q/r is acceptable in many cases, where these conditions are satisfied".
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <[email protected]> On Behalf Of Scott Kitterman > Sent: Tuesday, March 28, 2023 4:01 PM > To: [email protected] > Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows > > On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote: > > On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman <[email protected]> > > > > 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 > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!DQk5uxtCLX2CY35SAENNOFCA8Q1HtPphfxqGdOAYwly4Hk1ZvVvI > h4pShpcVde6DoPy_ZlUm7N8WWQe3bUhg$ _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
