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. 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. 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.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. 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
