Subject: Re: [dmarc-ietf] A-R results for DMARC

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 22:16:09 -0500

I don't think there is a ticket for this, but it would be nice if
there were standard ways to put a few more items into the DMARC part
of an A-R header, in particular the p= and pct= values and the
location of the policy record if it's not the same as header.from.

None of the existing ptypes really apply here (in particular "policy" is
for local policy, not a policy you found somewhere else.)  Perhaps call
it polrec for policy record and add polrec.p polrec.pct and polrec.domain.

I have never understood all of the indirection involved in defining
stuff for A-R but I'm hoping Murray can help out.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Mon, 7 Dec 2020 19:19:59 -0800

Please open a ticket, agreed that standardization here is a good thing.

I have some further thoughts as an individual once the ticket is opened.

On Mon, Dec 7, 2020 at 19:16 John Levine <[email-masked]> wrote:

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

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Dec 2020 20:18:54 -0800

> stuff for A-R but I'm hoping Murray can help out.

What I think you're referring to is a distinction between the way we seem
to want to use A-R now versus how it was originally intended.

The original intent back in RFC 5451 was to relay only those details that
an MUA might care about, such as the DKIM result (so you can display
something representing a "pass" or "fail" on a message) and maybe the
domain name found in a passing signature (an early shot at caring about
alignment when rendering a message).  The community seems to have shifted
toward that being too strict and instead wanting to use it as a transport
mechanism for any evaluation detail about the message that might be
interesting to the MUA or any other downstream agent once it reaches its
final ADMD.  RFC 8601, for instance, registered "header.a" and "header.s",
DKIM properties that are almost certainly of no interest to MUAs.

So that ship has sailed, meaning yes, we could register these too if
they're going to be useful to downstream agents.  Though for that matter,
you could just start using them even without registering them to see if it
would be helpful, because 8601 allows for local conventions (the
tried-and-true "ignore what you don't know" thing that DKIM introduced).

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 7 Dec 2020 23:31:17 -0500

On Mon, 7 Dec 2020, Murray S. Kucherawy wrote:
> alignment when rendering a message). ...

I suppose but 5451 also says it might be useful to message filters.

> tried-and-true "ignore what you don't know" thing that DKIM introduced).

Sure, I can write the code to stick them in but it would be nice to have 
some expectation that I'm not going to collide with something else, or 
other people use different tags for the same thine.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brandon Long <[email-masked]>
Date: Tue, 8 Dec 2020 16:51:57 -0800

> I suppose but 5451 also says it might be useful to message filters.

Right, there are clearly MUAs that do some amount of spam filtering, so
disposition
of p=quarantine would seem to be useful for that.

> other people use different tags for the same thine.

Right, we clearly send that information around our system as separate
metadata
about the message... for us it would be more useful as an agreed upon place
where MUAs can consume it.

And it seems like in some places, disparate tools are chained together, and
headers
are where that metadata lives as the message flows between systems.  I'm
sure those places will come up with their own or add to some large
X-My-System blob,
but a standard place does allow different tools from different folks to be
used together.

Brandon

---

From: "John R Levine" <[email-masked]>
Date: 8 Dec 2020 20:45:12 -0500

> but a standard place does allow different tools from different folks to be

Well, it was certainly easy to code:

  Authentication-Results: iecc.com; spf=pass spf.mailfrom=[email-masked] spf.helo=mail-vk1-xa2c.google.com smtp.remote-ip="2607:f8b0:4864:20::a2c"; dkim=pass header.d=google.com header.s=20161025 header.a=rsa-sha256 header.b="QsMz7qJd"; dmarc=pass header.from=google.com polrec.p=reject polrec.pct=100

Regards,

---

From: Douglas Foster <[email-masked]>
Date: Tue, 8 Dec 2020 22:37:40 -0500

If included in an ARC set, John's extensions would solve my concerns about
lost data during forwarding.   HELO links the result to a received entry.
 Full SMTP address recovers data lost to SMTP rewrite.  DKIM domain
partially recovers from From rewrite if it is the From foaming being
reported,  but the full address is actually needed for some situations.

On Tue, Dec 8, 2020, 8:45 PM John R Levine <[email-masked]> wrote:

>   Authentication-Results: iecc.com; spf=pass spf.mailfrom=[email-masked]
> spf.helo=mail-vk1-xa2c.google.com
> smtp.remote-ip="2607:f8b0:4864:20::a2c"; dkim=pass header.d=google.com
> header.s=20161025 header.a=rsa-sha256 header.b="QsMz7qJd"; dmarc=pass
> header.from=google.com polrec.p=reject polrec.pct=100
>
> Regards,

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Dec 2020 14:27:01 -0800

On 12/8/20 4:51 PM, Brandon Long wrote:
>
>
> On Mon, Dec 7, 2020 at 8:31 PM John R Levine <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Right, there are clearly MUAs that do some amount of spam filtering, 
> so disposition

Is there any evidence for that though? I would assume that the folks on 
this list use a diverse set of MUA's and would be in a position to tell 
us if some of them do. I'm guessing by your statement that gmail doesn't 
do anything different.

Mike

---

From: Brandon Long <[email-masked]>
Date: Wed, 9 Dec 2020 15:37:19 -0800

On Wed, Dec 9, 2020 at 2:27 PM Michael Thomas <[email-masked]> wrote:

> this list use a diverse set of MUA's and would be in a position to tell us
> if some of them do. I'm guessing by your statement that gmail doesn't do
> anything different.
>
Gmail does put messages with disposition quarantine into the spam label,
but we don't rely on the A-R header to pass that information from the smtp
transaction to the mailbox.

At least the Mac Apple Mail client did have a client-side spam filter,
looks like it probably still does:
https://support.apple.com/guide/mail/reduce-junk-mail-mlhlp1065/mac

Does it handle spf/dkim/dmarc in any way?  I don't know.

Brandon

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 10 Dec 2020 09:34:15 +0100

On Thu 10/Dec/2020 00:37:19 +0100 Brandon Long wrote:
>>>> The original intent back in RFC 5451 was to relay only those details
>>>> that an MUA might care about, such as the DKIM result (so you can
>>>> display something representing a "pass" or "fail" on a message) and
>>>> maybe the domain name found in a passing signature (an early shot at
>>>> caring about alignment when rendering a message). ... >>>
>> disposition of p=quarantine would seem to be useful for that. >>
>> us if some of them do. >
> Gmail does put messages with disposition quarantine into the spam label, but
> we don't rely on the A-R header to pass that information from the smtp 

As an SMTP filter, zdkimfilter can reject, but it cannot quarantine.  That is 
MDA's territory.  It passes quarantine information in an A-R comment[*].  If 
there was a standard way to convey that info, it could be used by MUAs as well 
as by any other software not specifically designed around zdkimfilter's 
idiosyncrasies.

Best
Ale
-- 

[*] https://www.tana.it/sw/zdkimfilter/zdkimfilter.html#dmarcand