On Fri, Jul 7, 2017 at 10:54 PM, Murray S. Kucherawy <superu...@gmail.com> wrote:
> On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman <skl...@kitterman.com> > 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. > Great > 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. > The way I read it, the consensus in this thread and others is that selectors and source ip make sense to transmit for DMARC report reasons, but where/how they should be transmitted does not have consensus. An earlier thread discussed putting this information in the AAR, but the consensus in that thread was that the AAR definition in the spec should be kept as minimal as possible, and a better place for the selector was the A-R, but the source ip didn't belong in the A-R at all. If neither of these pieces of information make sense in an A-R, to me it makes sense to revisit the conversation around transmitting via AAR instead of discussing new headers altogether (which is where the source ip conversation went), which definitely does feel like feature creep. Or maybe, put a different way, the question is: what's the simplest way, with the least delta to the spec, that allows for transmission of selectors and source ip? This would enable DMARC reports for messages delivered due to ARC to have the same report payload as messages delivered directly. > > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
