I definitely support this idea, as having the selectors available is extremely useful to us as part of service authentication. And putting them into the AR headers seems to be the appropriate solution.
I guess the next question is how we would actually go about sending this information. Something like header.s? =Gene On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long <[email protected]> wrote: > On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy <[email protected] > > wrote: > >> >> >> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <[email protected]> >> wrote: >> >>> So as a consumer of these reports I'd definitely like to see a >>> structured value with as much information as possible. >>> >> > [snip] > >> >>> - DKIM Selectors - Unfortunately we probably can't get the DKIM >>> signature selectors (because they aren't generally recorded in the >>> Authentication-Results, and so won't be available to downstream hops), >>> but >>> if we can get them, that would be very helpful. >>> >>> >> They could be added to A-R, in theory, but they're not really >> user-consumable which is why they were originally omitted. >> > > Thinking some more on this while thinking about the format of the DMARC > report, I think we should consider it. > > The AuthRes header was meant to help pass information to the end user (or > their mail client) from their own mail system. > > The AAR header is meant to pass information from each hop to all of the > following hops, and meant mostly (at this point) to inform the DMARC > handling of the message. > > And part of the point of DMARC is informing admins/domain owners on how > their mail is being evaluated to help them get to stricter levels. > > It's pretty obvious that for the domains of larger organizations, one can > end up with many sources of email. We've taken a pretty strong stance > internally at Google that we don't give out DKIM keys, the mail has to > relay through us to be signed, but given the blank stares we seem to get > from ESPs when we say that, I don't think that's the standard at all. > > So, different selectors are a really good indicator, possibly more so than > IPs, of where mail comes from. But neither IPs nor selectors are included > in the AuthRes or AAR headers. > > Now, the selector is still there if the DKIM signature wasn't removed. > Though, it's often removed when messages are deliberately rewritten > (mailing lists), because there still exists receivers which reject mail > based on broken signatures. > > IPs are preserved in Received headers, but extracting them and knowing > ADMD boundaries and such becomes kind of complicated, compared to the much > simpler usage of including them as a propspec for SPF. > > My point is, AAR is computer consumable authenticated forwarded > information. This information may not inform the DMARC result directly, > but being able to pass it to the aggregate report seems pretty useful. > > Brandon > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
