- DNSBLs are temporary fad, they'll never last.
(we've been serving DNSBLs for 10 years)
Longevity is no guarantee of future survival.
- 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
- 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. Note that a huge FP
does not imply a huge quantity of false positives, if you allow for an
- 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.
- DNSBLs "sit in the middle of an end-to-end email transaction"
(see: http://www.spamhaus.org/dnsbl_function.html for
There is a diagram under Rights of a Sender vs Rights of a Receiver
which shows that the DNSBL modifies the behavior of the Receiving
mail server. This is what I mean by "sitting in the middle of an
end-to-end (sender to recipient) email transaction.
- Someone from BT said "DNSBLs should not be standardised"
(BT has a contract with Spamhaus to use our DNSBLs on its network,
we're not sure why BT would prefer the DNSBLs it uses to not be
standardised but we'll ask them at contract renewal time ;)
This is the IETF. Nobody here speaks for any company or any
other organisation. Many people have stated that THIS DRAFT should
not be accepted as a STANDARDS TRACK RFC because it does not meet
the IETF requirements for an IETF STANDARD. That is very different
from saying that DNSBLs should not be standardised.
- DNSBLs are all bad because someone had a bad experience with SORBS.
(well, we're not SORBS. Nor are Trend Micro, Ironport, or the other
responsible DNSBL operators)
DNSBLs are risky because of the many cases put forward here. This
implies that there are security considerations that should be discussed
in the RFC, but which the authors neglected to mention.
DNSBLs using 127.0.0.2 cause absolutely no 'damage' whatsoever)
You must not have read the draft. People are concerned with stuff
like this from section 2.3:
To minimize the number of DNS lookups, multiple sublists can also be
encoded as bit masks or multiple A records. With bit masks, the A
record entry for each IP is the logical OR of the bit masks for all
of the lists on which the IP appears. For example, the bit masks for
the two sublists might be 127.0.0.2 and 127.0.0.4, in which case an
entry for an IP on both lists would be 127.0.0.6:
In any case, your diatribe will not change the fact that this draft
will not be standardised. In order to become a standard, a draft has
to have consensus, and you can't build consensus by misstating the
arguments against standardisation, and then saying that it is all
Ietf mailing list