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

[Scott Kitterman <[e-mail]>]

On Sunday, April 9, 2023 3:50:46 AM EDT Murray S. Kucherawy wrote:
> Emphatically "wearing no hat" here, just speaking as a long-time
> participant:
> 
> On Sat, Apr 8, 2023 at 2:13 PM Mark Alley <mark.alley=
> 
> [e-mail]> 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?
> 
> IMHO, absolutely not.
> 
> Since one of the IETF's main goals in producing a technical specification
> is interoperability, and since improperly deployed "p=reject" results in
> the very essence of non-interoperability in the deployed email base, I'm
> having trouble imagining why the standard should leave operators with any
> choice here.  That is, in direct reply to the cited definition of "SHOULD
> NOT", I claim there do not exist valid reasons in particular circumstances
> when the particular behavior is acceptable, even when the full implications
> are understood and the case carefully weighed.
> 
> (Note, here, that Barry has in his proposed text limited the constraint to
> those types of deployments where the damage is likely.  I concur.  DMARC,
> as currently defined, works just fine when deployed in transactional
> situations.  Or, at least, I haven't seen that identified as a problem
> case.)
> 
> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST
> NOT" that we know people will ignore calls into question the IETFs
> relevance or legitimacy.  But I submit that the IETF issuing a standards
> track document which fails to take the strongest possible stance against
> deploying DMARC in a way that knowingly imposes substantial breakage, for
> any reason, is irresponsible and is the greater threat to our legitimacy.
> Keep in mind that improper deployment of DMARC results in damage to
> innocent third parties: It's not the sender or the MLM that's impacted,
> it's everyone else on the list.  It's breathtaking to me that we can feel
> comfortable shrugging this off under the banner of "security" or "brand
> protection".
> 
> In a separate email, Doug Foster just said:
> > I also have a hard time with the notion that any domain with a potential
> 
> exception becomes a domain that MUST NOT protect itself from impersonation.
> 
> But it's not "MUST NOT protect itself from impersonation", it's "MUST NOT
> use DMARC to protect itself from impersonation" when the use of the domain
> includes non-transactional operations likely to be disruptive.
> 
> Imagine a web server protocol that states, when receiving a proxied
> connection, if the web server looks at it and sees something it didn't
> like, it rejects the request, but also fouls up some other active,
> legitimate operation in the process.  Imagine further that the only
> defensive posture about this disruption is a "SHOULD NOT".  Whatever
> benefit such an algorithm might claim, should it be given a place among the
> other standards the IETF produces?  I would hope the answer is obvious.
> And if we're not willing to tolerate it in the web world, why are we
> willing to tolerate it for email?
> 
> The IETF has no illusion that it is the standards or protocol police.  It
> is sufficient, however, to be able to say in the face of such breakage that
> this is not how the IETF intended DMARC to be deployed.  (A similar debate
> exists already, for what it's worth, in the domain registration space.)
> That is, if you do "p=reject" when you know what you're doing is going to
> clobber other people's legitimate operations, you can't claim to be
> operating in compliance with the standard.  We need to be able to say that,
> even if the offender doesn't care to listen, and "SHOULD NOT" simply
> doesn't cut it.
> 
> Mike also likes to invoke King Canute, but I think that's a faulty
> analogy.  DMARC does not deserve elevation in our calculus to the
> equivalent of a force of nature.  It was built and deployed by humans, who
> often make mistakes or have agendas.  The same cannot be said of the ocean
> or tides.
> 
> Finally, and for the only part with my AD on but askew: Scott has proposed
> a couple of good alternatives to consider, though one of them includes
> "MUST consider".  I have placed a DISCUSS on formulations like this in
> other documents before because I don't know how one would evaluate
> compliance with such a normative assertion.  It reduces in my mind to "OK
> I've thought about it, thus I have complied", so it doesn't actually say
> much in defense of interoperability.
> 
> -MSK, participating

Fair enough on the MUST consider.  I agree.

I also agree with your more general comment here.  I think we're at the point 
where we've pretty well discussed it at least to the point of diminishing 
returns.

How do we drive this to closure?

Scott K