On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman <[email protected]> wrote:
> I think it depends on what is meant by 'source'. > > Imagine a scenario where I'm the mail admin for a shop that has 5 outbound > servers. As a matter of security policy, private keys are generated on the > machine that will use them and never transit the network. For DKIM then, I > have 5 selectors. No problem. > > Time passes. I remember to do key rotation, but my colleagues that manage > our > DNS close the ticket that to add the records for the new keys after only > publishing 4 of the 5 new records. > > Since the DNS people closed my ticket as finished, I put my new keys in > production and start using the new selectors. > > Being a conscientious mail admin, I check my DMARC feedback reporting > regularly. To my dismay, I discover that over the next day or two my DKIM > pass rate for direct mail goes from 99% to less than 80%. > > If I have the selector, I can identify that all the unexpected failures > come > from a single system. I can take it out of production while I trouble > shoot > and focus my efforts on what went wrong on with the key rollover for that > one > system. Without the selector, I don't know if it's a single 'source' or > multiple 'sources'. > > In this context, having the selector in DMARC feedback reporting to help > define a 'source' is really useful. > > Using the selectors to segregate different 'sources' for reputation > purposes > is not (in this case). > > Receivers know the selector. If they feed domain and selector into their > Bayesian processors and get a useful distinction, they are going to use it. > No RFC will change that. If there's some statistically significant > difference > in 'sources' identified that way, then that's their call. > Agreed 100% > > I think selectors in DMARC reporting would be really useful. For ARC > though, > I'm not at all convinced. I can't think why, as a sender, I would care. > So this use case is exactly correct, and I think it very clearly demonstrates the value of the selector when it comes to reporting back on ARC in a DMARC report. Take the following case, extending Scott's example: When we have a direct sender -> receiver relationship, in aggregate, the receiver will see 5 DKIM-Signatures, four of which pass and one of which fails. This information can be reported back to the sender to fix the broken key. Now, with a sender -> intermediary -> receiver relationship (and assuming the intermediary modifies the message and breaks the signature, so ARC is needed for delivery), in aggregate, all 5 sender DKIM-Signatures will be broken. Without a selector, it is impossible to disambiguate which keys are problematic and need fixing since they all share the same header.d/header.i. And to be very specific about this above case, in the aggregate for AAR for i=1 you'd see "dkim=pass header.i=example.com" four times and "dkim=fail header.i=example.com" once, but all signatures will fail to validate at the receiver. Adding the selector makes it possible to disambiguate these statuses so that the sender, to whom these selectors are meaningful, can fix broken configurations. Does this make sense or is the example and value of selectors still unclear? Seth > Scott K > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
