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

[Douglas Foster <[e-mail]>]

This topic is so nuanced that I think we need a more detailed discussion
than has been proposed.   Below is my counter proposal for the topic.
Doug Foster


As DMARC rollout approaches completion, aggregate reports may continue to
indicate non-affiliated servers that produce DMARC FAIL.  The DMARC
implementation team will desire to understand whether these items represent
malicious impersonators that need to be blocked, or non-malicious sources
that should not be blocked.  Mailing lists are one commonly-cited example
of non-malicious messages that produce DKIM FAIL due to in-transit changes.
  Moving to p=quarantine or p=reject is expected to cause non-malicious
messages to be blocked as malicious, which may also affect the server
organization's reputation and consequently the server's reputation and
ability to deliver any messages anywhere.

Since mail is often bi-directional, the domain owner should be collecting
DMARC test results on incoming messages at the same time that it is
collecting DMARC aggregate reports on outgoing messages.  When both sources
point to the same server organization and SMTP domain, parallels can be
drawn.   If incoming messages from a server are blocked as malicious, then
traffic reported on the aggregate report is also presumed to be malicious.
If incoming messages are identified as coming from an acceptable but
content-altering mailing list, then aggregate report entries for the same
server organization and SMTP domain are also presumed to represent
acceptable traffic.  Not all ambiguity will be resolvable.   Additionally,
since aggregate reports are an incomplete view of data in a particular time
period, some source will not be detected at all.

Where desirable but unauthenticated mail is known to exist, out-of-band
conversations with the report sending organization and the message sending
organization may permit exceptions to be configured in advance, so that the
exempted traffic will be accepted even if DMARC enforcement begins.

Domain owners will request DMARC enforcement when the actual or feared
occurrence of malicious traffic exceeds their concerns about blockage to
desirable traffic.  When this occurs, the burden shifts more heavily to the
evaluator and his organization.  If the domain owner policy correctly
identifies a malicious traffic source, then the evaluator should block the
initial message and any subsequent message from the attacker, whether
authenticated or not.  But it the domain owner policy incorrectly flags a
message as suspicious, the error should be corrected with an adjustment to
local policy.   The difference between the two possible interpretations
becomes very important and requires great care.  To help avoid incorrect
dispositions, domain owners may be best served by stopping at p=quarantine,
and evaluators may be best served by handling p=reject as if it was
p=quarantine.

On Sun, Apr 9, 2023 at 10:36 AM Scott Kitterman <[e-mail]>
wrote:

> 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
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>