Subject: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows

From: Alessandro Vesely <[email-masked]>
Date: Fri, 17 Sep 2021 14:09:51 +0200

TL;DR: p=validate: reject on fail, but only on first hop.  New ticket: https://trac.ietf.org/trac/dmarc/ticket/122

It appears that John Levine via Arc wrote:
(Yes, it appears, because I cannot be sure --see below)
> 
> One time I asked one of the authors of ARC why they don't just
> whitelist mail from known mailing lists. They said the problem is that
> lists do lousy spam filtering, and legit lists leak bursts of spam all
> the time. For example, spammer steals someone's address book and
> starts sending spam to a mailing list with a From: that happens to be
> a subscriber. Most lists only check the From: address and let the spam
> through. ARC lets the final recipient peek back and see whether a
> message was DMARC aligned when it arrived at the list. Real mail from
> the sender would be, the spam wouldn't.

Without taking anything away from ARC, since IETF's MLM does check DKIM signatures, why does it let fake senders through?  The answer is, because John's domain has p=none.  Many domains have p=none.  Some do so exactly because of mailing lists.  Meanwhile, several mailing lists are adopting the practice of rewriting From:.

Now, if my server checked ARC signatures, and if it was configured to trust IETF's MLM, and if [email-masked] produced ARC headers, and if my mail client recognized ARC authentication, then I'd be sure it was really John who wrote the text quoted above.  Quite some if's, eh?

Alternatively, although my mail client displays DKIM authentications, I have to look for non-automatically trusted Authentication-Results: in the header in order to check the text was John's.

However, if I knew IETF's MLM rejected fake senders, I wouldn't have to recourse to search the header.  Knowing that the IETF rejected DMARC failure would be enough.

Indeed, most of the times DKIM signatures are valid.  On first hops, there's the additional opportunity of SPF.  Still, there are a number of failures.  I see stuff such as:

     Old-Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key)
      reason="fail (message has been altered)"
      header.d=iecc.com
      header.b=1w7rvJSu; dkim=fail (2048-bit key)
      reason="fail (message has been altered)" header.d=taugh.com
      header.b=Kc7/HE9z

     Old-Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1152-bit key)
      reason="fail (message has been altered)"
      header.d=tana.it

These seem to be signing errors.  If we had p=validate they'd have bounced back and we'd have had to resend them, possibly investigating why they failed.  Too much annoyance?  Dunno.  Since 2016 I only found 11 messages from me to IETF lists which failed to validate at the first hop.  So those bounces would be bearable, and they would help debugging the signing filter.  So, I'd set p=validate if it were available.  Would you?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 Sep 2021 12:25:11 +0000

>These seem to be signing errors.  If we had p=validate they'd have bounced back and we'd have had to resend them, possibly investigating why they failed.  Too much annoyance?  Dunno.  Since 2016 I o…

How do you define "First Hop" without enabling spoofers to trivially bypass DMARC checks by forging more than one hop of headers?

Scott K

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Fri, 17 Sep 2021 15:15:40 +0200

Scott Kitterman <[email-masked]> writes:

> How do you define "First Hop" without enabling spoofers to trivially
> bypass DMARC checks by forging more than one hop of headers?

It wouldn't matter. Sensible mailing lists would reject non-first-hop
mails for domains with p=validate. Spoofers can still spoof directly,
but they cannot use mailing lists to spread their spoofed mails.

This is a marked upgrade from p=none which most domains are forced to
use at the moment.

Then as infrastructure improves, recipients will start to reject
incoming non-first-hop mail with p=validate if it does not have a valid
ARC header.

/Benny

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 Sep 2021 13:42:12 +0000

>incoming non-first-hop mail with p=validate if it does not have a valid

If the point is that intermediaries that expect to be the first hop should reject failures for p=None, they can already do that by rejecting on SPF fail.  No need to add complexity to DMARC to get there.

If there's consensus that adding something like this to DMARC as an intermediate step for intermediaries only would be useful, then I think there are multiple issues.  One, which is resolvable, is that validate isn't the right name.  I think getting the naming and semantics right would be critical.  I don't think this can get past backwards compatibility problems though.  The p tag is a mandatory part of the record and any new value will be seen as invalid by all existing DMARC implementations, so you'd have to bump the version.  I don't think we want to do that.

Also, doing anything based on an ARC header field from anything other than a trusted source is a recipe for failure.  I've already seen cases where spoofed email got accepted due to ARC from an untrusted source.  Don't forget the limitations of ARC.

Scott K

---

From: Benny Lyne Amorsen <[email-masked]>
Date: Fri, 17 Sep 2021 18:16:12 +0200

Scott Kitterman <[email-masked]> writes:

> Also, doing anything based on an ARC header field from anything other
> than a trusted source is a recipe for failure.  I've already seen
> cases where spoofed email got accepted due to ARC from an untrusted
> source.  Don't forget the limitations of ARC.

I am not particularly worried about spoofing of domains under my
control. They are at p=none and cannot change to quarantine or reject
due to the mailing list issue.

In the past, the stance of DMARC has been clear, saying that use cases
like mine cannot be handled by DMARC policies and therefore p=none is
the only option. p=validate offers me a chance to get on board, at least
some of the way.

At present, I DKIM sign outgoing mail, but since p=none, the recipients
are unlikely to find the DKIM signatures particularly
helpful.

/Benny

---

From: Douglas Foster <[email-masked]>
Date: Sat, 18 Sep 2021 06:36:30 -0400

Benny said:
"At present, I DKIM sign outgoing mail, but since p=none, the recipients
are unlikely to find the DKIM signatures particularly helpful."

On the contrary, it helps evaluators.   A well-authenticated message might
be eligible for whitelisting, and will never be blocked based on sender
authentication criteria.   An evaluator's options are not limited by the
sender's policy position.

Doug Foster

Details:

An incoming mail stream can be broken into these phases:

- In phase 1, the message source is evaluated.   "Source" is any
combination of identifiers that can be used to establish a reputation.
In this phase, known-bad sources are blocked.    A subset of known-good
sources are tracked for whitelisting (bypass most or all of the content
scanning), but this is only safe if the relevant identifiers are not
spoofed (i.e. authenticated).  Authentication for whitelisting has nothing
to do with the sender's p=policy, only with the ability to authenticate.
Using DKIM as well as SPF gives you greater opportunity to be in this
category, if the evaluator considers your messages to need whitelisting.

(Note that for the evaluator, sender authentication is not limited to SPF
and DMARC.   A trusted source IP, or a trusted and forward-confirmed host
name, can be sufficient for authentication.)

- In phase 2, messages that were not whitelisted are subjected to content
filtering.   Messages with objectionable content are blocked.
 Objectionable content often indicates an objectionable source, so the
content blocks are used to update the message source block rules.  False
positives are used to adjust content filtering rules or add to the source
whitelisting rules.

- In phase 3, sender authentication failures are considered, and may be
determinative.   Note that there at this point there are no known
objections to the message other than the sender authentication problem.
The evaluator wants to block malicious impersonation whether or not the
sender has a DMARC policy.   Similarly, the sender does not want to block
desired messages, and there are many reasons why a critically-important
message can fail sender authentication.   A sender authentication failure
becomes an opportunity to review.   A review could lead to several outcomes

- The message is unacceptable and the offending source needs to be
blocked.   A sender block rule is created in phase 1.

- The message is acceptable but does not require whitelisting.   A sender
authentication exception is created for this identifier set. for use in
phase 3.   Content filter rules may also be added in phase 2.

- Since the message passed content filtering, an acceptable message with
sender authentication failure is unlikely to identify the need for a new
whitelisting rule, but anything is possible.

When the volume of unathenticated messages becomes overwhelming, evaluators
are more likely to apply automatic (stupid) rules.   So it is in everyone's
interest to minimize the volume of unauthenticated messages.

On Fri, Sep 17, 2021 at 12:23 PM Benny Lyne Amorsen <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 20 Sep 2021 20:15:58 +0200

>>but they cannot use mailing lists to spread their spoofed mails.

Indeed, it might be better to specify that the policy is intended for MLMs and 
similar mediators.  They usually happen to be the first external hop, which 
helps authentication but is not the key.

>>This is a marked upgrade from p=none which most domains are forced to

Yes.  Although authentication results take part in most local filtering 
recipes, this policy provides for clear, protocol level behavior.

>>incoming non-first-hop mail with p=validate if it does not have a valid

ARC has different problems.

> If the point is that intermediaries that expect to be the first hop should reject failures for p=None, they can already do that by rejecting on SPF fail.

spf=pass does not imply first hop.  Actually MLM mail often passes SPF check.

> No need to add complexity to DMARC to get there.

The added complexity is really minimal.  I agree that this proposal may 
conflict with the need to simplify DMARC.

> If there's consensus that adding something like this to DMARC as an intermediate step for intermediaries only would be useful, then I think there are multiple issues.  One, which is resolvable, is that validate isn't the right name.

I had thought p=mlm-validate, then I simplified it.  Do you have better names?

> I think getting the naming and semantics right would be critical.

Indeed.

> I don't think this can get past backwards compatibility problems though.  The p tag is a mandatory part of the record and any new value will be seen as invalid by all existing DMARC implementations, so you'd have to bump the version.

I don't think we need a different version to say something so trivial as:

    Unrecognized values must be ignored.

That point is missing in the DKIM spec.  RFC 7489 just says:

    DMARC records follow the extensible "tag-value" syntax for DNS-based
    key records defined in DKIM [DKIM].

But RFC 7376 only says:

    Unrecognized *tags* MUST be ignored.

It doesn't say that unrecognized values, in general, must be ignored.  It says 
so for individual tag values, such as unrecognized canonicalization algorithms, 
Unrecognized query mechanisms, Unrecognized algorithms, Unrecognized key types, 
and Unrecognized flags.

For the receiver behavior, to consider the record invalid would be equivalent 
to p=none, which is correct.  However, feedback reports tags shouldn't be 
invalidated.

>  I don't think we want to do that.

Agreed.

> Also, doing anything based on an ARC header field from anything other than a trusted source is a recipe for failure.  I've already seen cases where spoofed email got accepted due to ARC from an unt…

100% agreed.  While this proposal doesn't solve the MLM problem, it can 
partially help a recipient to learn whether a message was DMARC aligned when it 
arrived at the list, which is one of ARC's aims.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Sep 2021 14:32:07 -0400

On Monday, September 20, 2021 2:15:58 PM EDT Alessandro Vesely wrote:
> Indeed, it might be better to specify that the policy is intended for MLMs
> and similar mediators.  They usually happen to be the first external hop,
> which helps authentication but is not the key.
> 
> > If the point is that intermediaries that expect to be the first hop should
> > reject failures for p=None, they can already do that by rejecting on SPF
> > fail.
> > If there's consensus that adding something like this to DMARC as an
> > intermediate step for intermediaries only would be useful, then I think
> > there are multiple issues.  One, which is resolvable, is that validate
> > isn't the right name.
> > I don't think this can get past backwards compatibility problems though. 
> > The p tag is a mandatory part of the record and any new value will be
> > seen as invalid by all existing DMARC implementations, so you'd have to
> > bump the version.
> It doesn't say that unrecognized values, in general, must be ignored.  It
> says so for individual tag values, such as unrecognized canonicalization
> algorithms, Unrecognized query mechanisms, Unrecognized algorithms,
> Unrecognized key types, and Unrecognized flags.
> 
> For the receiver behavior, to consider the record invalid would be
> equivalent to p=none, which is correct.  However, feedback reports tags
> shouldn't be invalidated.

That's not specified in RFC 7489, so it's an assumption that this is how the 
world works.  At best it's undefined and I don't think we can engineer 
interoperability based on assumptions about how current implementations 
address undefined behavior.

Also, in my experience anyway, mailing lists aren't a significant source of 
problematic spam and so I don't think doing things to solve what is mostly 
already a non-problem is really needed.

Let's not do this.

Scott K

> > Also, doing anything based on an ARC header field from anything other than
> > a trusted source is a recipe for failure.  I've already seen cases where
> > spoofed email got accepted due to ARC from an untrusted source.  Don't
> > forget the limitations of ARC.
> partially help a recipient to learn whether a message was DMARC aligned when
> it arrived at the list, which is one of ARC's aims.
> 
> 
> Best
> Ale

---

From: Dotzero <[email-masked]>
Date: Mon, 20 Sep 2021 15:49:15 -0400

> already a non-problem is really needed.

+1

It does more than assume how current implementations address undefined
behavior. It also makes assumptions about curren behavior that is somewhat
known and defined but not necessarily consistent across participating
entities.

It assumes for example that outbound mail only does a single hop except for
going through MLMs. It assumes that there aren't multiple hops on the
inbound side (Think for example cloud based or hybrid security solutions
where the ultimate receiver may have limited control or no control over
behavior before ultimate delivery.

So as Scott succinctly puts it, " Let's not do this."

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 20 Sep 2021 22:46:40 -0400

>TL;DR: p=validate: reject on fail, but only on first hop.  New ticket: https://trac.ietf.org/trac/dmarc/ticket/122

I'm with Scott and Mike.  Let's not.

In most cases MLMs can do strict DMARC enforcement on *incoming* mail
with good results since it is rare to have a hop between the sender
and the MLM that breaks DMARC.

On the other end, we know what the problems are, so let's not.

R's,
John