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

[Dotzero <[e-mail]>]

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
>