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

[Douglas Foster <[e-mail]>]

Thank you, Scott.   You have done a great job of encouraging progress on a
topic with strong emotions.

I believe we need warnings to all three participants:
- One to domain owners, which Barry started
- One to lists and other forwarders, for which Hector has provided a
starting point
- One to evaluators, which is where I tried to steer us.

They are not mutually exclusive.  Each party has to deal with the "fait
accompli" represented by the messages that it receives, and makes its own
choices.

For domain owners, I am comfortable with the language above, and some of
the other recent variants.  I prefer the ones that focus on guidance,
rather than "MUST NOT", but I understand the emotion that leads to MUST NOT.

For lists, I need to start by expressing my surprise that unsubscribing an
innocent bystander is the most serious consequence.   It is very risk to
send a message when you expect the recipient to classify it as malicious.
 The expected response should be blacklisting by the server organization,
which includes all of its clients, which is possibly coupled with an RBL
listing.   In short, the consequences can be disastrous and SHOULD NOT be
undertaken.   Mailing lists have this problem because of making changes,
but any forwarder has this problem if they forward a message that has DMARC
enforcement, but no signature, due to domain owner errors.

Given that lists are expected to (A) continue making content changes, and
(B) continue accepting all comers, I think we need to embrace From Rewrite
as a necessary consequence of A and B.    Unlike Hector, I don't have a
problem with From Rewrite because the act of altering the content makes it
a new message, and the modifying entity becomes responsible for the whole
thing.   So we need a caveat to list owners which lays out the real risks
and the better alternatives.

For evaluators, we need a warning that says DMARC is not perfect.
Evaluators should expect to see:
- acceptable impersonation from certain sources,
- lost credentials due to relay after mailing list additions to a message,
- lost credentials due to forwarding after spam filter additions to a
message,
- lost credentials due to forwarding of unsigned messages.
While automatic rejection on p=reject is implemented by some evaluators, it
will always be sub-optimal.    The better choice is to quarantine with
prioritized review, so that real threats can become complete blocks on the
responsible party, and non-threats can be corrected with local policy
adjustments.

Doug Foster



On Fri, Apr 28, 2023 at 9:28 PM Scott Kitterman <[e-mail]>
wrote:

> 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
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>