On 6/2/10 7:34 PM, John Levine wrote: >>> The basic problem with ADSP is that we shipped an untested prototype, ... >>> > The problems with ADSP aren't just for lists, but whatever. > Agreed.
Spamassassin's pre-configured ADSP information represents less than 1% of domains being phished, which in turn represent less than 1% of domains. Much like a flea of a flea sitting on an elephant. While more comprehensive lists are possible, publication should be open, the goal of ADSP. The lifespan of phishing domains is often measured in hours, which means retaining name recognition and trust represents a reasonable strategy. Suggesting use of sub-domains to differentiate policy is counter-productive, when it confuses a population that does not understand how URIs function, and will not understand that the right-hand side of an email-address is changing for policy reasons, and that is not a phish. ADSP, as currently defined, does not offer policy flexibility when using a single domain. In addition, it is not clear whether ADSP is recommending receiver handling, or asserting Author Domain policies. Rather using reputation as a patch over third-party exceptions, as with Vouch-by-Reference, the Author Domain is also able to declare which third-party domains are eligible for exceptions in their asserted policy of "all" + "3px", for example. These exceptions might include ancillary conditions to narrow their scope. Unlike Vouch-by-Reference that entails subsequent transactions and protocols with different entities, the singular ADSP exception transaction is determined by a single protocol. It is possible to delegate to other services the publication of which third-party services require exceptions. Exception lists might be industry related, regional, or community based. It seems clear the third-party authorization draft based upon hash labels should include how delegation could be implemented in a manner transparent to recipients. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html