On May 25, 2009, at 7:14 PM, Steve Atkins wrote: > > On May 25, 2009, at 5:48 PM, Franck Martin wrote: > >> see >> >> http://feedbackloop.yahoo.net/ >> http://www.gettingemaildelivered.com/yahoo-feedback-loop-released-to-the-public > > Yup, that's connected to the Returnpath feedback loop, rather than > reputation tracking. They're allowing you to sign up for a feedback > loop for a particular d= value and for either one specific selector > or all selectors. > > When tracking specific issues it may well be useful to get FBL > reports for just one specific user of a DKIM identity, and being > able to key on selector seems a good enough way to do that, if a bit > of a hack. It's not something I'd expect anyone to use normally, > though.
The s= value represents a valid choice for separating feedback reports. The domain may use keys for different purposes, where the s= value could be used to establish different priorities. While d= represents the first element that should be checked for reputation, either the i=, or the author address when the i= is not available, could be used as an intra-domain identifier. Provided the domain only has a few bad actors (normally less than one percent for well managed domains) a secondary check point would allow a means to exclude intra-domain bad actors that might otherwise replay their DKIM messages well beyond the normal rate-limits that a provider may have established. The only other alternative strategy would be register the the path of the DKIM signatures, but then this would not be as robust. As IP address reputation becomes more complete, the remaining avenue for spammers is to utilize provider's main servers. There are enough user systems compromised, that normal rating limiting will not be affective. With respect to DKIM, rate limiting is not effective against replay abuse. Checking the d= value's reputation should provide a high cache hit rate. If this represents a bad-actor, which is likely the case, then no other query is required. When the d= value's reputation indicates there is no intra-domain problems, then again no other query is required. However, when intra-domain problems exist, use of the i= value or that of the author address converted to a hash could represent the next query made. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
