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