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

[Jim Fenton <[e-mail]>]

On 28 Mar 2023, at 17:15, 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.

Mailing lists being a primary example of usage that may run afoul of a p=reject policy, but not the only one.

>    To be explicitly clear: domains used for general-purpose email MUST
>    NOT deploy a DMARC policy of p=reject.

I’m not sure p=quarantine is a good idea either for such domains.

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

Strongly agree. The primary problem with DMARC has been the inappropriate use of p=reject policy for domains that aren’t transactional, and clear wording is required to correct that practice.

Even for transactional domains, some cautionary text might be added about recipient-side forwarding (alumni domains and the like) that might not be fully transparent and break DKIM signatures. These might also be caught up in a p=reject policy. My college alumni address, which used to be quite transparently forwarded, now breaks the original DKIM signature for reasons that aren’t clear to me.

-Jim