On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman <[email protected]> wrote:
> In this context, having the selector in DMARC feedback reporting to help > define a 'source' is really useful. > The DMARC report also includes other things that might be able to help you identify the bad source, like the IP address. But I do hear what you're saying. Just to be clear, I don't really have any issue with adding selectors to DMARC reports. My trepidation specifically involves using A-R to transport the selector to wherever. The purpose of A-R going back to RFC5451 was primarily to make available (i.e., highlight) to users those portions of a message that were primary input to an authentication decision: "We validated signed content X against a published key for domain Y and it passed" (for DKIM), or "we validated IP address X against the policy for domain Y and it passed" (for SPF). Given most selectors out there, in my experience, identify time ranges for which the keys are meant to be valid, or are otherwise not names meaningful to an end user, providing the selector name seems antithetical to this purpose; what, for example, would a user do with the knowledge that ietf.org's "ietf1" key or kitterman.com's "201409" key or Scott's hypothetical "machine-number-5" key signed this message? If Gmail showed that, highlighted, on a message, would it help or confuse a typical user? I think the latter, and if that's the case, I would argue that A-R is not the place to put it. This smells like feature creep to me. If consensus is that it's good feature creep, then that's what we do, but I'd like to know that we're sure we want to water down A-R's definition in this way. I don't have a problem with having some way to get the selector into the DMARC report, but I'm not convinced A-R is the right or only way to do it. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
