On Wed, 27 Jul 2011, Douglas Otis wrote: > DKIM should be viewed as a Work-In-Progress still missing a viable > policy layer.
So you at least agree ADSP needs reform or replacement. Here's another way to express my points. Of the policies a sender may wish to publish in ADSP or a successor, some are worthless or nearly so for the purpose of preventing phish sent in the name of that sending entity. "dkim=unknown" is of course such a policy, and so is my "dkim=except-mlist". I imagine TPA could be used to write an infinity of such policies, as well as solid ones. But such policies may still be useful in the big picture. If a sender is not a bank, perfect forgery protection is not needed, and likely not worth the sacrifices required for a solid policy. But such senders may be able to provide information stronger than unknown, yet weaker than discardable. It's good for the phish targets if those domains do. At present, admins seem in no hurry to develop and deploy receiverside ADSP support, since it is rare for a domain to deploy discardable, and thus even rarer for ADSP (as-it-stands) to ever make a reject recommendation. If most domains published -at least- a weak policy, receiverside ADSP deployment would become worthwhile. If except-mlist became standard, a BOFH might implement ADSP for his own account, and he would see a decent reduction in overall false-negative rate, because after applying his mailing-list whitelist, he can treat except-mlist as discardable. He can't do that for his users (as he does not know for sure what they are subscribed to), but once he's taken that first step, it's easy for him to treat except-mlist as unknown for them while *still respecting discardable*. And the phish targets will then be happy to see discardable honoured. Consider SPF. SPF does nothing to prevent phish, as it only protects the MAIL FROM: address which is not presented to the user by default. Yet receiverside SPF deployment has progressed further than ADSP, because SPF does kill some spam. ---- Michael Deutschmann <mich...@talamasca.ocis.net> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html