Subject: [dmarc-ietf] Reporting DMARC policy in A-R header fields

From: Scott Kitterman <[email-masked]>
Date: Mon, 29 Jul 2019 15:37:55 -0400

I'd like to add the option to record DMARC results in an A-R header field for 
consumption by a downstream processor.  I think it would be something like 
this:

Authentication-Results: mail-router.example.net; dmarc=pass 
header.from=example.com policy.dmarc=none

That would take adding an entry in the Email Authentication Methods registry 
for:

method: dmarc
ptype: policy
value: dmarc

Does that make sense as a way to do it?  Does anyone have alternative 
suggestions?

Scott K

---

From: Дилян Палаузов <[email-masked]>
Date: Mon, 29 Jul 2019 19:50:34 +0000

Hello Scott,

You want to add the option to record the DMARC policy in the A-R header.  I add it as comment:

Authentication-Results: mail.example.org/x551xr2q019874; dmarc=pass
 (p=quarantine dis=none) header.from=example.com; spf=pass
 smtp.mailfrom=[email-masked]

with dis being the disposition.

What will a downstream processor do with the information?

Regards
  Dilyan

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 29 Jul 2019 15:59:30 -0400

> What will a downstream processor do with the information?

It would execute the policy (e.g. reject or quarantine).  I would rather 
enforce reject in the MTA and leave quarantine to the MDA since that's just a 
question of which folder the mail lands in, not really an MTA function.  If 
you don't do all the policy enforcement in the MTA, then there needs to be 
some way to record it.

Scott K

> > I'd like to add the option to record DMARC results in an A-R header field
> > for consumption by a downstream processor.  I think it would be something
> > like this:
> > 
> > That would take adding an entry in the Email Authentication Methods
> > registry for:
> > 
> > method: dmarc
> > ptype: policy
> > value: dmarc
> > 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 Jul 2019 00:54:57 -0400

> Does that make sense as a way to do it?  Does anyone have alternative

I think comments should be free-form.  If we want data that can be machine 
parsed, we should specify it.

I think the above works in ABNF terms.  It's:

Authentication-Results:" authserv-id; method=result ptype.property=value 
ptype.property=value

According to the ABNF, there can be more than one propspec 
(ptype.property=value) per methodspec in resinfo, so I think it's legal.  It 
would just need the new registry values for dmarc.

Scott K

---

From: Дилян Палаузов <[email-masked]>
Date: Tue, 30 Jul 2019 13:34:46 +0000

Hello Scott,

do you want to include in the A-R header the published policy, as obtained from DNS (my first interpretation of your
proposal), or the disposition of the message after applying DKIM/SPF/DMARC validation, pct sampling, and the ominous
reject→quarantine sampling conversions?

With disposition I mean what is called at https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result.

For the disposition on p=reject only the MTA can make the decision based on pct to reject, so it makes sense if the
result of disposition is included in the A-R header by the MTA and consumed by the MDA.  In turn, including pct and
published DMARC policy in the A-R header, so that the MDA can do the sampling, does not make sense.

If you want to call the new parameter “policy”, then it shall be articulated that it means disposition, and not
published policy.

I am in favour of the proposal.

It allows for forwarded emails/aliases to indicate in the A-R header, that sampling was already performed by the
aliasing server, and the final server that accepts the email can skip performing the sampling again.  Performing the
sampling again has the disadvantage, that the pct= parameter is misinterpreted, as the parameter is supposed to be
applied only once.

On the other side, skipping of the second sampling by whatever server is pure theory, and has no practical impact.

Greetings
  Дилян

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 Jul 2019 13:56:16 +0000

The published policy (that's why I suggest dmarc.policy).  I'm not sure if disposition belongs in A-R.  If it does, it'd be a local policy override, probably policy.dmarc as described now in RFC 8616.

Scott K

On July 30, 2019 1:34:46 PM UTC, "Дилян Палаузов" <[email-masked]> wrote:
>Hello Scott,
>
>do you want to include in the A-R header the published policy, as
>obtained from DNS (my first interpretation of your
>proposal), or the disposition of the message after applying
>DKIM/SPF/DMARC validation, pct sampling, and the ominous
>With disposition I mean what is called at
>https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result.
>
>For the disposition on p=reject only the MTA can make the decision
>based on pct to reject, so it makes sense if the
>result of disposition is included in the A-R header by the MTA and
>consumed by the MDA.  In turn, including pct and
>If you want to call the new parameter “policy”, then it shall be
>articulated that it means disposition, and not
>published policy.
>
>It allows for forwarded emails/aliases to indicate in the A-R header,
>that sampling was already performed by the
>aliasing server, and the final server that accepts the email can skip
>performing the sampling again.  Performing the
>sampling again has the disadvantage, that the pct= parameter is
>misinterpreted, as the parameter is supposed to be
>applied only once.
>
>On the other side, skipping of the second sampling by whatever server
>is pure theory, and has no practical impact.
>
>Greetings
>  Дилян
>
>registry

---

From: "Stan Kalisch" <[email-masked]>
Date: Tue, 30 Jul 2019 17:21:28 -0400

> The published policy (that's why I suggest dmarc.policy). I'm not sure if disposition belongs in A-R. If it does, it'd be a local policy override, probably policy.dmarc as described now in RFC 8616.

In that case, if the downstream were to make use of the upstream's disposition, it's extrapolating a meaning from the disposition, but not actually deriving meaning from the authentication results themselves, so I'm inclined to agree.

Thanks,
Stan

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 31 Jul 2019 09:11:49 +0200

On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote:

> The published policy (that's why I suggest dmarc.policy).

Published policy can be ambiguous.  Say you have p=quarantine; sp=none.  The
MTA chooses which to apply based on the domains (publishing and From:).  So it
makes sense to write the /applied/ published policy.

I'm not good at designing A-R stanzas, as you know.  However, since dmarc is
already the policy method, why not write dns.policy, since that is where it
comes from?

> I'm not sure if disposition belongs in A-R.  If it does, it'd be a local
> policy override, probably policy.dmarc as described now in RFC 8616.

You mean RFC 7489, don't you?  I see nothing about A-R in RFC 8616.

Would it be possible to add a result of "quarantine"?  Having dmarc=fail and
dns.policy=quarantine leaves a good deal of interpretation to the MDA.  If one
could write dmarc=quarantine, a simple string search or regular expression
would do.

Currently, I use a comment too.

Since we're at it, besides the spam folder, is it fine if the MDA sets IMAP
keyword $Junk[*] or $Phishing[†] or would we dare registering a new one?

Best
Ale

-- 
[*] https://www.iana.org/assignments/imap-jmap-keywords/junk/junk-template
[†] https://www.iana.org/assignments/imap-jmap-keywords/phishing/phishing-template

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 31 Jul 2019 10:46:00 +0000

>already the policy method, why not write dns.policy, since that is

The problem with dns as a ptype is that virtually all this is from DNS.  I haven't had a chance to study your proposal in detail or coordinate with the other designated experts, but speaking for myself my initial thought is that dns is not a good ptype name.

This is specific to DMARC, so I think it's appropriate to say so.

>You mean RFC 7489, don't you?  I see nothing about A-R in RFC 8616.

Sorry.  I meant RFC 8601.

>could write dmarc=quarantine, a simple string search or regular

That's a great example of why dns.policy= isn't the way to go.  It's too generic.  If it's dmarc.policy=quarantine, there's no ambiguity.  You can't put quarantine as the DMARC result, because that's not what it is.  The DMARC result is pass/fail/none.

>keyword $Junk[*] or $Phishing[†] or would we dare registering a new

It's outside my area of expertise, so I don't have a strong opinion, but I'd be inclined not to register a new one.  I think the average user can be confused by too many terms for things that to them are the same.

Scott K

---

From: "Stan Kalisch" <[email-masked]>
Date: Wed, 31 Jul 2019 08:30:25 -0400

> The problem with dns as a ptype is that virtually all this is from DNS. I haven't had a chance to study your proposal in detail or coordinate with the other designated experts, but speaking for mys…

Moreover, given the D in DMARC literally means "Domain-Based", I think this nomenclature would be potentially confusing and unfortunate.

> This is specific to DMARC, so I think it's appropriate to say so.

There is that too.

Stan

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 31 Jul 2019 08:06:03 -0700

> keyword $Junk[*] or $Phishing[†] or would we dare registering a new one?

I think that's part of the discussion in the JMAP/EXTRA WGs.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Jul 2019 20:36:49 -0700

On Mon, Jul 29, 2019 at 12:38 PM Scott Kitterman <[email-masked]>
wrote:

> for

This seems sane to me, or at least neither an objection nor a better idea
came to mind.  :-)

I concur with whoever disagreed with doing it in comments as a normative
thing meant for downstream processing.  IMO, comments in header fields are
meant for debugging done by things in meat-space.

-MSK, hatless