On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) <kb...@drkurt.com> wrote:
> On Fri, May 5, 2017 at 2:30 PM, Seth Blank <s...@valimail.com> 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 >> p=reject, this is not sufficient information to uncover authentication >> failures that are obscured by mailing lists or forwarding that modified the >> message. >> > > 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. > > 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? >> > > 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. > 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? > > >> 2) How can this information be encoded to survive transit and be reported >> by a final receiver? >> > > I'll defer thoughts on this until we hammer out #1 :-) I would really like > to get some thoughts from rua aggregators... > Agreed :-) > > --Kurt > Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
