J.D. Falk wrote:
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.
True. This is noted in the Security Considerations section of the
draft.
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.
Disagree. One such use case is noted in the draft, where an domain has
a premium service and a free service, and tags signatures accordingly
so that users of the premium service avail themselves of the better
reputation that service might have.
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.
But i= isn't opaque, not as a whole anyway. It has the syntax of an
email address, and the domain part of that address MUST be the same as
or a subdomain of the d= value.
Introducing r= provides a tag that really is opaque, as a whole, and
doesn't conflict with other DKIM extensions that might want to use i=
in a non-opaque way.
-Jim
|
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html