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

[Scott Kitterman <[e-mail]>]

On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> I raised this issue in the DMARC session in Vienna, and have let it
> sit for a while so as not to derail other discussion.  As we're pretty
> close to finished with the DMARCbis document, I'd like to raise it
> again, this time with specific proposed text for us to discuss.
> 
> And so:
> 
> OLD
> 
>    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.
> 
> 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
> 
> I'm well aware that the MUST will *not* be followed by everyone, and
> that some domain owners will feel that they need to use p=reject,
> regardless.  I think that's fine: the standard should specify what's
> right for interoperability, and I believe that improper use of
> p=reject is extremely harmful to interoperability... so "MUST" is
> correct here.  And no one will be arrested or fined for choosing not
> to follow it.  We should still say it, nonetheless.
> 
> OK, have at it.

I think this is pretty good.  I would only add a "because ..." clause at the 
end.  Often in IETF documents we say SHOULD/SHOULD NOT unless $REASON if there 
are clear exceptions.  We don't generally justify MUST/MUST NOT because we 
expect people to adhere to them.  In this case though we know that the MUST is 
going to be met with suspicion is some quarters, so I think we should explain 
why.  It doesn't have to be much.  You may have even written it already in 
your note after the suggested change.  I thnk it applies to p=quarantine as 
well, as Jim Fenton suggested.

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."

Scott K