On 14 Nov 2008, at 09:19, <michael.dillon@xxxxxx>
<michael.dillon@xxxxxx> wrote:
- DNSBLs are a temporary fad, they'll never last.
(we've been serving DNSBLs for 10 years)
Longevity is no guarantee of future survival.
A good argument against publishing a standard for any technology at all.
- DNSBLs are bad for email.
(we alone flag some 80 billion spam emails *per day*, spam which
would otherwise clog servers and render email completely useless)
Interesting point. If you did not run those DNSBLs then the flood of
spam would have rendered email completely useless which would have
reduced the sell-rate from one in 12.5 million, to zero. At which
point there is no financial incentive for spam. Or, more likely, spam
would have been maintained at a much lower level to maximize their
profit.
The "we don't need filters, the spammers will regulate themselves"
theory also holds for eliminating the police: crooks will regulate
themselves when too much crookness renders crooking not so profitable.
This theory can be tested and you guys at BT could be the pioneers:
turn off BT's spam filters and we'll watch. Obviously let your
customers know first or your phones will light up (something like
this will do: "Dear BT customer, we're turning your spam filters off
as an experiment to see if, over time, spammers will spam you a bit
less when they realize your mailbox has imploded under the weight of
spam").
- DNSBLs have huge False Positives.
(at 80 billion spams stopped per day, if we had even a miniscule
FP level there would be a worldwide outcry and everyone would stop
using us. Do the maths. Our FP level is many times lower than any
other spam filter method by a very, very long way)
Hmmm. No data provided, so no maths is possible.
I thought perhaps you might be with BT's mail engineering team. BT
uses our DNSBLs, you therefore have precise data on both how much
spam you stop with them and FPs for your customers. (If you're not
with BT's mail engineering team I apologize)
- DNSBLs break email deliverability.
(DNSBL technology in fact ensures that the email sender is
notified
if an email is rejected, unlike Bayesian filters/content filters
which place spam in the user's trash without notifying the
senders)
This still breaks deliverability.
Deliverability breaks when someone accepts a package, says "250 OK,
got it" to the courier, and then silently trashes it without
informing the Sender that the Recipient did not in fact get it.
How many times have you sent an email and your recipient says days
later "I didn't get it" and you say "well you must have since it
didn't bounce back" and both of you waste time. Almost guaranteed in
such cases your recipient was using post-SMTP-phase spam filters,
content filters or "I guess this looks like spam" filters and the
receiving server *did* accept your mail, *did* give your server a
"250 OK, got it" which concluded the transaction and then quietly put
your message in the Junk.
DNSBL technology maintains the fundemental rule of email
deliverability: If an email can not be delivered *inform the Sender*.
Steve Linford
The Spamhaus Project
http://www.spamhaus.org
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf