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

[Scott Kitterman <[e-mail]>]

We've gone nearly a week without any further discussion on this thread.

I reviewed the thread and I think this is the closest we got to anything 
(most) people agreed on.  I know not everyone liked it, but I doubt we're 
going to get closer to a consensus on this.

Can we adopt this and move forward on to the next thing?

Scott K

On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote:
> I'm happy with that suggestion.
> 
> Barry
> 
> On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman <[e-mail]> 
wrote:
> > Would you feel any better if the MUST NOT was followed by 'to preserve
> > interoperability '?  That's implicitly there and I believe technically
> > correct.  If you value other properties of the system higher than
> > interoperability, then the advice may not apply, which is fine.
> > 
> > Scott K
> > 
> > On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex" 
<Alex_Brotman=[e-mail]> wrote:
> > >I’m just not sure how we determine what is high-value.
> > >
> > >comcast.com: p=reject
> > >comcast.net: p=none
> > >xfinity.com: p=quarantine
> > >
> > >The top one is corporate, middle is consumer, bottom is consumer (but not
> > >actually used) & customer comms (sub-domains).  They’re all used in
> > >various ways for internal messaging.  Should I tell our corporate admins
> > >that they need to no longer publish p=reject?  They’re violating the RFC
> > >by doing so?  There are very few consumer-oriented messages that
> > >originate from comcast.com.  Are we doing it right?  It makes things a
> > >little harder when one of our employees wants to use a mailing list. 
> > >But that still feels like the right thing to do.
> > >
> > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and
> > >dictating to domain owners what is in their best interests, regardless
> > >of our perceived value of their domain.
> > >
> > >--
> > >Alex Brotman
> > >Sr. Engineer, Anti-Abuse & Messaging Policy
> > >Comcast
> > >
> > >From: dmarc <[e-mail]> On Behalf Of Barry Leiba
> > >Sent: Wednesday, March 29, 2023 10:15 AM
> > >To: Todd Herr <todd.herr=[e-mail]>
> > >Cc: [e-mail]
> > >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
> > >flows
> > >
> > >I'm very much against text such as this, as I think it encourages
> > >deployments that are contrary to interoperability and to the intent of
> > >p=reject.
> > >
> > >I contend that p=reject (as with the similar construct in the older ADSP)
> > >was intended for high-value domains and transactional mail, and that it
> > >was never intended for use in domains where general users send general
> > >email.
> > >
> > >I stand by the MUST NOT that I proposed.
> > >
> > >Barry
> > >
> > >
> > >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
> > ><todd.herr=[e-mail]<mailto:[e-mail]
> > >f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
> > ><[e-mail]<mailto:[e-mail]>> wrote:
> > >
> > >If you agree that interoperability is increased, then I'd suggest that
> > >you actually do agree that the proposed text is appropriate.
> > >
> > >
> > >I don't know that I agree that interoperability is increased...
> > >
> > >I'm having trouble squaring proposed language that says "Domain owners
> > >MUST NOT publish p=reject because it breaks interoperability" with the
> > >following language from section 5.8:
> > >
> > >
> > >Mail Receivers **MAY** choose to accept email that fails the DMARC
> > >
> > >mechanism check even if the published Domain Owner Assessment Policy
> > >
> > >is "reject". In particular, because of the considerations discussed
> > >
> > >in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
> > >
> > >messages solely because of a published policy of "reject", but that
> > >
> > >they apply other knowledge and analysis to avoid situations such as
> > >
> > >rejection of legitimate messages sent in ways that DMARC cannot
> > >describe, harm to the operation of mailing lists, and similar.
> > >
> > >It seems inconsistent to state with certainty that authorized mail will
> > >be rejected due to authentication breakage when there is no requirement
> > >that a reject policy be honored (and we have plenty of evidence that
> > >Mail Receivers are following the 'SHOULD NOT reject messages' guidance).
> > >
> > >Language that would be more consistent in guidance to the domain owners
> > >might look something like this:
> > >
> > >After careful analysis of the aggregate report data as described in
> > >section 5.5.5 (Collect and Analyze Reports), Domain Owners **MAY**
> > >choose to change their policy from 'none' to 'quarantine' or 'reject'.
> > >If, in the Domain Owner's judgement, unauthorized and deceptive use of
> > >its domain name in the RFC5322.From field puts at risk the trust it has
> > >built with its recipients, then it is **RECOMMENDED** that the Domain
> > >Owner make use of the p and/or sp tags to set policy to 'quarantine' or
> > >'reject' for those streams most at risk of loss of trust.
> > >
> > >If going that route, probably want to consider expanding on 5.5.5, too; I
> > >need to think about it some more.