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

[Douglas Foster <[e-mail]>]

There is no interoperability problem.
An evaluator  has an unlimited right to block any incoming message for any
reason.
Specifically, an evaluator has the right to block any message which he
determines to be insufficiently authenticated.

If a sender wants a message to be accepted, he carries the burden of
earning the evaluator's trust.   He has no right to have his message
delivered.

An intermediary does not have a right to alter a message in transit and
still have it treated as if it had not been modified.    Arguing that a
change is "innocuous" is not a viable argument.   Doing so would require a
before-and-after comparison (which is not available), and a
technical specification of "innocuous" (which does not exist.)

Interoperability only requires that the evaluator be given the opportunity
to evaluate the message, and to do so in a way that does not cause injury
to the submitting server.   It does not matter whether he blocks the sender
IP at his firewall, rejects the connection request at hello, rejects all
recipients on RCPT TO, rejects the message after DATA, or discards the
message after DATA.  As long as both parties implement RFC5321, we have
interoperability.

If an evaluator blocks a message that a user considers acceptable, that is
a management issue between the user and the administrator.  It happens all
the time, and it is resolved through normal support processes.

Doug Foster






On Wed, Mar 29, 2023 at 5:00 PM 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]>>
> 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.
> >
> >--
> >Todd Herr | Technical Director, Standards and Ecosystem
> >e: [e-mail]<mailto:[e-mail]>
> >m: 703.220.4153
> >
> >This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> >_______________________________________________
> >dmarc mailing list
> >[e-mail]<mailto:[e-mail]>
> >https://www.ietf.org/mailman/listinfo/dmarc<
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!BnSVJ7Ot7xEorNxvwnQPPLKjCUoG0MiUMFnPczO18L4RV-xRev7lnYcl6buwUHNn4JbzvGlzqAMl2J5l4bHsMbKOXw$
> >
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>