[ietf-dkim] Reading the entrails, was Moving to consensus
John R. Levine
johnl at iecc.com
Mon Mar 23 05:49:59 PDT 2009
>> I see no benefit whatsoever in using DKIM for blacklists. But we need
>> to be careful to avoid automatically carrying the habits of blacklist
>> filtering into whitelist filtering.
> This on its face seems like a very fair statement, and I agree with you that
> we clearly have been living in a blacklist world. But I am not convinced
> that there is a white list world out there at this time. There are too many
> virii and too many vulnerabilities to flip a good guy to a bad guy extremely
You're quite right that we're unlikely to have static whitelists any time
soon. But I was thinking more of simple questions like "is this message
whitelisted" versus "is this message blacklisted?"
Since bad guys are trying to disguise their identities to dodge
blacklists, blacklisting is necessarily fuzzy and heuristic, along the
lines of Spamassassin, and even yes/no blacklists like DNSBLs have
heuristics about how big an IP range to list if you see a cluster of
reports from a group of IPs.
But good guys want you to recognize them, so if we offer clear
instructions to make a message meet whitelisting rules, senders will
follow them. The more options they have, the less clear it is what to do,
and the more work everyone's going to have to do to sort out the results.
The reason that l= was a bad idea is that it changes the answer to the
question of whether a message is signed from "yes" to "sort of". The less
sort-of, the better.
More information about the ietf-dkim