On Friday, July 07, 2017 01:33:58 PM Seth Blank wrote: > 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?
If my mail flow was 100% indirect it would, but that's atypical. If direct mails were at 98% and indirect was at 80% it wouldn't matter what ARC says, I'd consider it somebody else's problem. Even if I had no direct mail and the indirect was 80%, I don't think I'd view what somebody told me about what somebody told them about mail I sent as a reliable basis for action. I'd leave it out of ARC for now and focus on getting it into the DMARC aggregate reports. Once it's there and there's some operator experience with the data, then we'll be in a better position to assess if there is utility for ARC. At the moment, we're purely arguing theory. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
