[dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Scott Kitterman <[e-mail]>]

On Tuesday, April 25, 2023 2:27:18 PM EDT Scott Kitterman wrote:
> 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.

Over the last 4 days there have been 34 responses to this message from seven 
different people.  I think it's been useful. The comments directly related to 
my original question seem to have died down, so I thought it might be a good 
time to try to summarize.

As a reminder, the question I posed was about objections (can't live with it) 
to using a construct like this to address the core DMARC interoperability 
issue (with the definition of "some appropriate description" deferred for later 
as well as some non-normative amplification):

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

There were two responses in the thread to the effect that "I can't live with 
it" (and some additional apparent support for one fo them).

The first alternative suggested was:

> Domains owners who have users who individually request 3rd parties to emit
> mail as an address within the domain MUST NOT publish a restrictive DMARC
> policy if they wish to support their users' usage of any potential 3rd
> party. Examples of 3rd parties include mailing lists and email service
> providers. These 3rd parties are not always aware of, or willing to work
> around, DMARC. Domain owners implementing DMARC as a means for governance
> by restricting the unauthorized usage of the domain MUST be aware that not
> all of the 3rd parties will make changes to work around DMARC, resulting in
> interoperability issues for their users' usage of the 3rd parties. Domain
> owners SHOULD provide an alternative address for these users within a
> cousin domain or subdomain that is not directly associated with the
> organization's brand-associated domain that is used for marketing and
> transactional email that needs the security benefits of DMARC. These users
> MUST use an address within a domain that does not have a restrictive DMARC
> policy.

My assessment is that this is a close cousin to my original suggestion.  If I 
were to attempt to distill it down to something parallel to my original 
suggestion, I think it would be along the lines of:

> Domains owners [use case] MUST NOT publish a restrictive DMARC policy
> if they wish to support [use case]. [Lots of explanation].

Distilled down like this, it doesn't seem that different to me and we could 
probably work some something like this and produce something conceptually 
similar.  I understand why this is preferable to some, although I don't 
personally prefer it because I think it's less clear.

The other alternative reverses the logic to shift the emphasis:

> Forcing authentication into Internet mail by publishing restrictive DMARC
> policies breaks some well established patterns of usage.  Publishing such
> policies is thus RECOMMENDED only for domains [in this other appropriate
> description].

I think this approach addresses a different question.  It offers only advice 
about who should publish restrictive policies.  It fails to warn against 
interoperability problems.  I RECOMMEND x for [some] is not the same thing as 
[not some] MUST NOT x.

Additionally, I think the objection isn't technical:

> Me, for one.  Because more than 98% of domains are going to fall into the
> description, however we word it, that statement makes the whole I-D
> nonsensical.  Cannot we just tell the problem without MUSTard?

I don't think burying the lede to encourage adoption is the way we should go.  
I didn't see any other support for this approach.

Ultimately, I'm not a WG chair or an AD, so I'm not in a position to make any 
kind of consensus call.  It does seem to me though that there's a solid 
consensus for some form of statement including "MUST NOT publish a restrictive 
DMARC policy".  I think there's still room for discussion about what goes on 
either end of that phrase.

Thanks to everyone who contributed.  I'll leave this here for the chairs' use 
in deciding a path forward from here.

Scott K