On May 6, 2017 1:28:03 AM EDT, Seth Blank <[email protected]> wrote: >On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) <[email protected]> >wrote: > >> On Fri, May 5, 2017 at 2:30 PM, Seth Blank <[email protected]> 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? ... 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
