Jim Fenton wrote:
FYI, I have submitted a short I-D which proposes a way to communicate a
stable identifier in the DKIM-Signature header field which might be
useful in the context of reputation.
Comments appreciated.
If you've got a reputation system geared towards predicting bad traffic
(what I call the "bad/not bad" model), you have to seek identifiers which
the bad actor cannot easily change. It'd be trivially simply for a bad
actor to offer a different reputation hint in each message, confusing
reputation systems & clogging up databases -- so a smarter system will fall
back to d=, or the last-hop IP, or other data.
If you've got a reputation system targeting towards predicting good traffic
(the "good/not good" model, usually used as an input to a certification or
accreditation process), then the entity will almost always want the good
reputation of one mail stream to have a positive impact on other mail
streams. So while they may use i= to opaquely indicate different streams,
they're unlikely to include a reputation hint which reduces the likelihood
of that transitive positive reputation.
In other words: bad guys would have an incentive to use this reputation
hint. Good guys wouldn't; or if they do, it'll be for reasons which are
entirely opaque to the verifier. Just like i= today.
Suggestion: leave i= opaque, and let's see what operators (on both ends of
the transaction) do with it.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html