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

[Todd Herr <[e-mail]>]

Upon further reflection, I find myself liking Barry's proposed text less,
and instead propose the following:

On Tue, Mar 28, 2023 at 9:42 AM Todd Herr <[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.
>>
>

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

5.5.6 Decide Whether 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.

The policies "reject" and "quarantine" are more effective than "none" for
accomplishing the chief goal of DMARC, namely to stop the exact-domain
spoofing of the domain in the RFC5322.From header. However, experience
has shown that a policy of "reject" can result in the disruption of
indirect mail
flows and cause damage to the operation of mailing lists and other
forwarding
services; [@!RFC7960] and [@!RFC8617] and Section 5.8, below, all discuss
this topic and/or possible strategies for addressing it.

Because of these challenges, some domains, particularly those with open
signup
capabilities, may prefer to remain at a policy of p=none. This topic is
discussed
further in section 11.4 below.

11.4 Open Signup Domains and DMARC Policies


Certain domains with open signup capabilities, where anyone can register an

account and send mail, may not want to implement p=reject. An example of
such

domains would be consumer mailbox providers that used to be known as
"freemail

providers". Domains with no DMARC policy or a policy of p=none are
vulnerable

to spoofing, but their users can send mail using these registered email
addresses

from unrelated third party systems (such as "forward to a friend" services)
or participate

in mailing lists without impediment. The security challenges that this
presents to the

domain owner are left up to those systems that allow open registration of
users.



-- 

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