>> 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 > quickly.
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. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
