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