John, I think you are mixing up various models of Black/White listing.
The one we are familar with and the one widely used een when many are not 100% happy with it is the 3rd party Lookup IP Black List - DNSRBL. Here, many have put their trust in a 3rd party negative reputation assessment. Currently this is based on IP - an inherent anchor (input) that is always there. DNSRBL is, like it or not, a BCP many use - a pseudo standard. For white list, thus far there is no wide adoption for a 3rd party assessment and even if there was, trusting a 3rd party good reputation assessment is hard to accept. Even if someone was going to trust a 3rd party assessment, the problem here, is what "anchor" or data do you pass to the 3rd party to evaluate it. WIth DKIM, its a different model. Now we have extra potential information to pass to an 3rd party assessor. However, to me, the "disconnect" to me, is at the fundamental protocol consistency level. You want to make this purely a WHITE LIST concept. However, DKIM whitelisting idea would be fundamentally inconsistent if the opposite is not considred. In other words, if this extra information is now used for Good Reputation Assessment, then to ignore the condition when the extra information is not there, it would create a loophole and high potential to further confuse users. Just consider, if having no extra information in the mail is not important, when it is expected to be there by the domain, then without a doubt, the bad guys will have a special solution to DKIM - don't bother to sign or fake it because non-compliant DKIM mail will is ignored. It all goes back to Whats Expected by verifiers when they sees a DKIM signature or lack there of. You simply can not look for only the golden needle (good signatures) in a hay stack of abusive mail, finding two messages with the same domain, one is signed the other is not and then treat the signed with some higher classificaton while doing nothing about the unsigned. To me, it is illogical from an engineering standpoint to ignore failure. It runs the risk of creating a confusing consideration for users. This mail is ok because it was signed, valid and stamped. What do I do when mail is received from the same author but its not signed or worst, signed and broken? I'm afraid the user will learn to ignore the whole ieda and thats defeats the purpose of DKIM in my opinion. While it may help DMA people who want to white list their distributions with DKIM to help push the mail to users, they need to also understand that fraud from the same domains can't be ignore under the same DKIM considerations. The DMA might not care about that. But the DOMAIN owner will. On 3/23/09, John R. Levine <[email protected]> wrote: >>> 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 > -- hls _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
