Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman <[e-mail]>]

On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:
> On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman <[e-mail]>
> 
> 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