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

[Scott Kitterman <[e-mail]>]

There are several variations of text that roughly mean the same thing, 
particularly when you keep in mind that IETF specifications are intended to be 
interoperability specifications, not implementation specifications.

We could do I think any of the following and they are roughly semantically 
equivalent:

[general purpose]* domains MUST NOT publish p=reject to preserve 
interoperability

to preserve interoperability, domains SHOULD NOT publish p=reject unless they 
are [not general purpose]* domains

which could be accompanied by:

[not general purpose]* domains SHOULD determine their email authentication 
deployment is accurate and complete before publishing restrictive policies 
(p=quarntine or p=reject) to avoid interoperability issues.

Publishing DMARC records with restrictive policies does cause interoperability 
problems for some normal email usage patterns.  Potential impacts MUST be 
considered before any domain publishes a restrictive policy.

* whatever the right formulation is, that's a related, but distinct (and I 
think less controversial question).

I think there's enough there for everyone to find their preferred answer.  I 
think it's clear on the interoperability risks, but the last MUST allows for 
the realist case that people are going to do it anyway.  I have no preference 
between the first two alternatives.

Scott K


On Saturday, April 8, 2023 5:12:56 PM EDT Mark Alley wrote:
> Re-looking at the definition of "SHOULD NOT", I don't see why it can't
> be considered.
> 
> "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that
> there may exist valid reasons in particular circumstances when the
> particular behavior is acceptable or even useful, but the full
> implications should be understood and the case carefully weighed before
> implementing any behavior described with this label."
> 
> Seems to fit perfectly with how domain owners currently can pick and
> choose interoperability with p=none over more strict protection, or vice
> versa with p=reject, in my opinion. Is that not considered "acceptable"
> by this definition's context?
> 
> On 4/8/2023 4:10 PM, Scott Kitterman wrote:
> > Possible.  I didn't count.
> > 
> > I didn't see any convergence towards an alternative.
> > 
> > I think adding explicitly that the MUST is related to interoperability
> > reasonably addresses the concern that there are non-interoperability
> > reasons people are going to publish p=reject despite the side effects.
> > 
> > I don't see a stronger consensus for a specific alternative.
> > 
> > I think we have exhausted the discussion on the topic, so, whatever the
> > resolution, I'd like to see the chairs drive the question to closure. 
> > It's pretty clear it's not going to naturally drift into a universal
> > consensus.
> > 
> > Scott K
> > 
> > On April 8, 2023 8:58:13 PM UTC, Dotzero<[e-mail]>  wrote:
> >> Going back through the thread I find more people questioning/disagreeing
> >> with the proposed wording than agreeing with it. I don't see a rough
> >> consensus.
> >> 
> >> Michael Hammer
> >> 
> >> On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman<[e-mail]>  
wrote:
> >>> 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.
> >>> 
> >>> _______________________________________________
> >>> dmarc mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dmarc
> > 
> > _______________________________________________
> > dmarc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc