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. > [...] > The original intent of selectors and domain names, going back to DomainKeys, was that selectors would be used to identify a key, and the domain name would be used to identify the source, or responsible party, regarding a message. Selectors can be rotated in and out of service for a given domain name without changing the domain name. Reputation, therefore, would be developed about the domain name (the "d=") specifically. Selectors were orthongonal. Based on discussions with Seth and Gene earlier, it sounds like the industry has sadly not taken up the habit of key and selector rotation, and instead the pairing of "s=" and "d=" now identifies a single source. Ignoring the obvious security problem this introduces, we're now talking about implicitly formalizing this tuple as identifying a source. This contradicts that original intent. In particular, if one were to develop reputation in this way, then a key being rotated out takes the reputation with it; signers would have to establish some procedure for doing so with substantial overlap so that the new key can be "warmed". Worse, in an emergency where a key is compromised, that tuple's reputation irretrievably suffers. How is this better than encouraging the industry to adopt the separation of functions that was originally intended? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
