Subject: [dmarc-ietf] reporting arc local_policy to dmarc rua

From: Brandon Long <[email-masked]>
Date: Thu, 4 May 2017 15:58:48 -0700

6.4.5 in the current spec specifies the following as how to report the
local_policy override from arc:

   <policy_evaluated>
     <disposition>delivered</disposition>
     <dkim>fail</dkim>
     <spf>fail</spf>
     <reason>
      <type>local_policy</type>
      <comment>arc=pass ams=d1.example d=d1.example,d2.example</comment>
     </reason>
   </policy_evaluated>

The comment is obviously completely unspecified, though maybe some
inferences can be done... though I'm not sure what it's saying myself.

Are we attempting to dictate the comment?  Or is that just an example and
it could be anything?

If anything, then folks who ingest these may need to look at a bunch, or
folks may just say arc=pass.

Is the more extensive information useful?

I came up with random format for use in the comment field for the authres
header, ie something like:

arc=pass (i=2 spf=pass spfdomain=example.com dkim=pass dkdomain=example.com)
(only partially rolled out, most servers are just saying (i=2)) but I'm not
sure that's useful directly either.

Brandon

---

From: Peter Goldstein <[email-masked]>
Date: Thu, 4 May 2017 16:19:29 -0700

So as a consumer of these reports I'd definitely like to see a structured
value with as much information as possible.

The ideal would be to get as much information as we'd get if the final
receiver had seen the original email directly at i=0.  So that would mean:

   - SPF Result and SPF domain
   - For each DKIM signature on the i=0 email, the result and the domain.
   This should show all signatures from the original message, regardless of
   status
   - DKIM Selectors - Unfortunately we probably can't get the DKIM
   signature selectors (because they aren't generally recorded in the
   Authentication-Results, and so won't be available to downstream hops), but
   if we can get them, that would be very helpful.

The above will aid in classification and tracking down problems with
authentication.

In addition, we probably want to record the # of hops (i.e. i=2)

The proposal above is a good start, but I don't think it handles the
multi-DKIM signature case well.  Do you have thoughts on how you'd record
and propagate information on multiple signatures in the report?

Best,

Peter

On Thu, May 4, 2017 at 3:58 PM, Brandon Long <[email-masked]> wrote:

> arc=pass (i=2 spf=pass spfdomain=example.com dkim=pass dkdomain=
> example.com) (only partially rolled out, most servers are just saying
> (i=2)) but I'm not sure that's useful directly either.
>
> Brandon
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 4 May 2017 17:02:00 -0700

> Are we attempting to dictate the comment?  Or is that just an example and

In the draft, the comment was simply an example. That's why there is no
further explanation of "required content". If we want to specify how
local-policy is reported, I think we risk derailing the spec, though I
understand the desire for a tightly specified syntax and content. The
consumption of it will be for people who process reports. We had asked
various folks from current processors and got no particular input earlier.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Fri, 5 May 2017 14:30:15 -0700

Brandon, thanks for this email.

Your question has solidified two matters for clarification that I have
about the end to end functionality of ARC with respect to the AAR header
and what that means for information reported back via DMARC.

For context, these questions come from the point of view of a domain owner
who wants to publish a DMARC policy of p=none to collect authentication
information with the goal of getting to a p=quarantine or p=reject policy,
and as a generator of reports who wishes to provide the most valuable
information to that domain owner to help with this process.

With no intermediaries, the useful pieces of information to identify
services that fail authentication are:
- The source IP
- SPF result and SPF domain
- For each DKIM signature on the message, its result, domain, and selector
- The policy disposition of the message

At the end of an ARC chain, we’re generally left with an i=1 AAR with only
SPF, DKIM, and DMARC pass/fail, and potentially a local_policy report which
says arc=pass|fail. As a domain owner at p=none who wants to get to
p=reject, this is not sufficient information to uncover authentication
failures that are obscured by mailing lists or forwarding that modified the
message.

A DMARC report which provides the above pieces of original authentication
information as part of the ARC reporting, not just the SPF and DKIM
pass/fail results, would be valuable in helping get to DMARC enforcement.

Forgetting the specifics of what I outlined above, to me there are two
important questions here for discussion:
1) What is the appropriate information to return via a DMARC report for
messages with an ARC chain to help a domain owner identify unauthenticated
sources of email?
2) How can this information be encoded to survive transit and be reported
by a final receiver?

What do you all think?

Seth

-- 

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 5 May 2017 18:13:31 -0700

> failures that are obscured by mailing lists or forwarding that modified the

I don't quite understand this assertion. At the end of an ARC chain, we
have the list of all the members of the chain and (for a domain asserting
p=none) the results of DMARC evaluations at each step.

> messages with an ARC chain to help a domain owner identify unauthenticated

Why would you be looking to ARC to discover "unauthenticated sources of
email"? That's not really ARC's role. If all of the intermediaries are
enforcing DMARC and reporting results, it seems like ARC would be somewhat
superfluous.

> 2) How can this information be encoded to survive transit and be reported

I'll defer thoughts on this until we hammer out #1 :-) I would really like
to get some thoughts from rua aggregators...

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Fri, 5 May 2017 22:28:03 -0700

On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) <[email-masked]> wrote:

>> At the end of an ARC chain, we’re generally left with an i=1 AAR with
>> only SPF, DKIM, and DMARC pass/fail, and potentially a local_policy report
>> which says arc=pass|fail. As a domain owner at p=none who wants to get to

> enforcing DMARC and reporting results, it seems like ARC would be somewhat

I'm specifically talking about what most domain owners go through when
first implementing DMARC prior to enforcement, as outlined in
https://tools.ietf.org/html/rfc7489#appendix-B.2

With no intermediaries, a DMARC report will give you back the source IP of
the originating sender, which is useful for validating or correcting
authentication mechanisms under the domain owner's control.

If I understand the current spec correctly, with ARC, the DMARC report will
have the IP of the last intermediary, but not necessarily of the original
sender, which obfuscates the information needed to fix broken
authentication. In other words, if a message sent through an ARC chain
failed DMARC initially, it still won't be delivered and the information
needed to fix this failure will not be in the final DMARC report.

To take a trivial example with no intermediaries (example.com at p=none):
- An unsigned email is sent from an example.com server of 192.0.2.50.
Ultimately, example.com receives a DMARC aggregate report with a record for
192.0.2.50 that shows spf and dkim fails. Now that IP can be added to the
example.com SPF record for future messages to pass DMARC.

And the same example but through an ARC signing intermediary (example.com
at p=none):
- An unsigned email is sent from an example.com server of 192.0.2.50
through a single hop at example.net with IP 198.51.100.100. Ultimately,
example.com receives a DMARC aggregate report with a record for
198.51.100.100 that shows spf and dkim fails and a local policy
comment of "arc=pass (i=1
spf=fail spfdomain=example.com dkim=fail dkdomain=example.com)". When
example.com receives this report, there is insufficient information in the
data to go fix the example.com SPF record.

My questions are:
1) should ARC help a domain owner at p=none get visibility into the
authentication status of originating senders?
2) if so, what information is worth preserving in addition to
spf/dkim/dmarc status for the express purpose of adding to the final
receiver's DMARC report?

> to get some thoughts from rua aggregators...

Agreed :-)

Seth

-- 

Bringing Trust to Email

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 06 May 2017 16:31:46 +0000

>authentication status of originating senders?
...
I think no.

Ultimately receivers will need to decide if they trust ARC to override a DMARC failure.  I don't think this is a technical question of if the ARC signer is correctly determining the authentication status of mail, I think it is a reputation question.

ARC is used to upgrade the status of a message.  Deciding to do that is all about the ARC signer, not the original authentication mechanism.

It might not hurt to describe how to structure the comment to provide such information for those that care (if providing authentication trace details in the comment, then SHALL do it this way), but no more than that.  That could even be done as a separate draft to minimize the requirements creep in this one.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Mon, 8 May 2017 18:38:24 -0700

I agree 100% with you in the case of a receiver dealing with an ARC signed
message from a domain with a policy of quarantine or reject.

What I think you're saying is that in the case of a p=none, it's not
necessary for ARC to provide information on originating services, but if a
receiver has the information, the spec could provide guidance so long it
doesn't introduce new requirements or creep.

This makes a lot of sense if written tightly (otherwise I agree we're
talking about a separate doc that should be considered separately). I'm
happy to suggest something concise unless anyone else has a strong opinion.

Seth

On Sat, May 6, 2017 at 9:31 AM, Scott Kitterman <[email-masked]>
wrote:

> Ultimately receivers will need to decide if they trust ARC to override a
> DMARC failure.  I don't think this is a technical question of if the ARC
> signer is correctly determining the authentication status of mail, I think
> it is a reputation question.
>
> ARC is used to upgrade the status of a message.  Deciding to do that is
> all about the ARC signer, not the original authentication mechanism.
>
> It might not hurt to describe how to structure the comment to provide such
> information for those that care (if providing authentication trace details
> in the comment, then SHALL do it this way), but no more than that.  That
> could even be done as a separate draft to minimize the requirements creep
> in this one.
>
> Scott K
>

-- 

Bringing Trust to Email

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 22:07:46 -0700

On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <[email-masked]> wrote:

>    - For each DKIM signature on the i=0 email, the result and the
>    domain.  This should show all signatures from the original message,
>    regardless of status
>
>
Aren't those in the DMARC report already?

>    -
They could be added to A-R, in theory, but they're not really
user-consumable which is why they were originally omitted.

> In addition, we probably want to record the # of hops (i.e. i=2)

That could be added as a message-level property.

> and propagate information on multiple signatures in the report?

Doesn't the XML schema for DMARC reports permit multiple signatures to be
reported?

-MSK