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 protected]> wrote: > > > 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 > -- [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
