![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
- 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 notifiedif an email is rejected, unlike Bayesian filters/content filterswhich 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 mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.