[dmarc-ietf] Search for some consensus, was: 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'm going to take another stab at this, starting back at the top of the thread 
since things went off the rails.

This is an attempt to see if we can focus in on getting some agreement on a 
path forward on this question.  If I may generalize for a moment, it seemed to 
me that there are roughly two sets of perspectives on this (with considerable 
variation within each set, of course).  One set is from people primarily 
focused on the security benefits associated with use of restrictive DMARC 
policies such as p=reject.  The other set is from people primarily focused on 
the interoperability impacts associated with some domains using such 
restrictive policies.

For many, the security benefit is the primary purpose of DMARC.  Without it, 
it's relatively pointless.  On the other hand, interoperability is a 
significant reason the IETF exists.  Without interoperability, the IETF is 
relatively pointless.  I am starting from the assumption that people are 
prioritizing different things differently in good faith.  Disagreement is normal 
for something like this.

For those of you that are new or perhaps relatively new to the IETF, I would 
comment RFC 7282 to you for background, particularly paragraph 3 [1] as I 
think it is a great discussion of the IETF way to work through a path forward.

The TLDR version is trying to find something we can live with, not something we 
would prefer.  There's clearly no overlap between the preferences of the 
people in the two groups I described above.  If anyone doubts that, I 
encourage you to consult the list archive for the last month.  The question 
is, can we get to something that people from both groups can live with and 
adequately address any technical points that are raised.

My recollection is that a general formulation that I proposed had at least 
some traction out of both groups:

> [some appropriate description] domains MUST NOT publish restrictive DMARC
> policies due to interoperability issues

Leaving aside (for now) the question of what goes into [some appropriate 
description] and with the assumption that there will be some non-normative 
discussion to amplify whatever that is and probably give some indication about 
what domains might do to not be one of those domains, is there anyone who just 
can't live with that formulation of the situation?

If you can't, please also make a suggestion of an alternative that you can 
live with and why you think people in the group you are not a member of should 
be able to accept it.

Scott K

[1] https://www.rfc-editor.org/rfc/rfc7282#page-7