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.
Return Path Inc
NOTE WELL: This list operates according to