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

[Todd Herr <[e-mail]>]

On Tue, Mar 28, 2023 at 8:36 AM Jim Fenton <[e-mail]> wrote:

> 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.
>
>
I also like the new text, and further propose updating section 7.6 (in the
Changes from RFC 7489 section) from this:

OLD

7.6  Domain Owner Actions


This section has been expanded upon from RFC 7489.


To this:


NEW


7.6  Expansion of Domain Owner Actions Section


This section has been expanded upon from RFC 7489.


RFC 7489 had just two paragraphs in its Domain Owner Actions section, and
while

the content of those paragraphs was correct, it was minimalist in its
approach to

providing guidance to domain owners on just how to implement DMARC.


This document provides much more detail and explanatory text to a domain
owner,

focusing not just on what to do to implement DMARC, but also on the reasons
for

each step and the repercussions of each decision.



In particular, this document makes explicit that domains for general-purpose

email **MUST NOT** deploy a DMARC policy of p=reject.


END


Obviously, the last paragraph of section 7.6 will reflect the consensus of
whatever 5.5.6 ends up being.


-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [e-mail]
*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.