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 On Thu, May 4, 2017 at 3:58 PM, Brandon Long <[email protected]> wrote: > 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 > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols [email protected] +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
