[ietf-dkim] [Fwd: New Version Notification for draft-fenton-dkim-reputation-hint-00]
jdfalk-lists at cybernothing.org
Mon Feb 16 12:57:40 PST 2009
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.
Return Path Inc
More information about the ietf-dkim