[ietf-dkim] [Fwd: New Version Notification for draft-fenton-dkim-reputation-hint-00]

[J.D. Falk]

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/