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. > 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... --Kurt
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
