I know that M3 is totally separate from this group, but this is more-so
a question for Todd H- does this mean that the M3AAWG authentication
best practices recommendation will also change based on this if this is
the intended usage going forwards with DMARCbis?
Quote from the existing document
<https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf>
-
* "DMARC Policy statements should be “p=reject” where possible,
* “p=quarantine” otherwise.
o “p=none”, “sp=none”, and pct<100 should only be viewed as
transitional states, with the goal of removing them as
quickly as possible. "
On 3/28/2023 8:42 AM, Todd Herr wrote:
On Tue, Mar 28, 2023 at 8:36 AM Jim Fenton <fen...@bluepopcorn.net> 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:*todd.h...@valimail.com
*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.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
