Why use a DNSBL?
Why use a DNSBL?
Doing a DNSBL lookup on an email message during the SMTP connection is cheap in hardware cycles and system time. If the MTA already knows the incoming message is spam it can deny a spam message before having to take additional action; The DNS server may even have the results cached from previous attempts!
System costs:
- Passing it to a mail-scanner (medium cost);
- Using a Bayesian filter (medium)
- Running it through a virus scanner (medium to expensive)
- Doing SpamAssassin network tests that check blocklists, DCC, pyzor, razor, etc. (medium to expensive)
Mail rejected by a DNSBL during delivery is not silently discarded. A realtime DNSBL rejection creates a delivery status notification (DSN) to the sender identifying the cause of the rejection, allowing troubleshooting on the sender’s end.
Realtime rejection avoids the backscatter problem of some spam filters which accept delivery, close the connection, and then try to return the mail after it is determined to be spam.
- Most spam and all viruses have forged sender addresses, and so the bounce would be sent to an innocent third party (if it is deliverable at all). This can be extremely disruptive to the third party!
Using the SBL, XBL & PBL lists together, or the combined Spamhaus Zen zone (recommended), rejects a large amount of spam and virus mail with very low “false positive” rejections of legitimate mail.
Back