On 4/30/08, Arvel Hathcock <arvel(_dot_)hathcock(_at_)altn(_dot_)com> wrote:
Well, now we have another question -- who's going to be using ADSP, mail
system operators or end users? It's always been my impression that the
main audience is MTA operators, who will use it in filtering decisions.
MTA operators will be using/deploying ADSP. End-users are the intended
beneficiary (as is the case with _all_ filtering systems). The
motivation driving MTA operators to deploy ADSP is end-user protection.
If it's for end users, my experience says that they are equally likely to
be fooled by info(_at_)accounts-bigbank(_dot_)com, which would suggest
we've been
wasting our time.
I agree with the first part of what you've said but the second part does
not follow logically. One can not claim that because we fail to protect
a user completely we therefore aren't able to provide any protection at
all and have thus wasted our time. ADSP isn't attempting to solve the
accounts-bigbank.com problem. But it does solve the foo.bigbank.com
problem. This is wonderful news and a welcome step forward.
I would love to hear a little more from you on scenarios in which the
limited treewalking functionality would benefit you or your receiver
customers. The more specific the better. What potential deliver/not
deliver decisions are made and based on what criteria.
I think I'm looking to understand what you get out of that, versus
what you might get out of "no treewalking functionality, but I reject
non-resolvable FQDNs." It seems like it might be pretty similar. I'm
wondering if that's true.
Al Iverson
--
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com -- Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html