John Levine wrote: >> My concern is this: what do identity assessors use today? An IP >> address. They might want that tidbid of information as well. How, >> then, not to exclude it? [ . . . ] > We tell senders that's the handle to put in signatures so receivers > recognize them, and we tell receivers that's the handle to check to > best know who's trying to talk to you. Assessors will certainly do > all sorts of other stuff as well, but this is the best advice on how > to interoperate with DKIM. > > With specific reference to DKIM, what I most want to discourage is > awful IP/domain hybrid hacks like only validating a signature if the > Sender-ID or SPF passes. So our interop advice is when you're thinking > about DKIM, don't think about IP addresses.
Speaking as an assessor (does anyone else here do that?), and as someone who has put a lot of thought into assessing the reputation of authenticated domains...I couldn't agree more. That way madness lies. Yet even so, assessors are going to use whatever data we think is relevant, no matter what the RFCs say. The bad guys don't care about standards, so when we're assessing badness we MUST look for non-compliant behavior -- and most assessors exempt behavior which may be non-compliant, but still extremely common. When assessing goodness we still look for non-compliant behavior, for basically the same reasons -- and often warn those good guys that they've screwed up somewhere. Concern about assessors thinking we can't use data just because the DKIM spec doesn't explicitly say we can, or vice versa, is a non-issue. -- 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
