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 <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html