Use of this dnsbl is currently free. It may eventually become a commercial service. We haven't figured out yet where the money will come from to support operating the list, but at some point we will either charge a small fee for access to the list or perhaps charge those listed for expedited removal.

For now, if you want to use our list, all we require is that you subscribe to list@njabl.org so that you can be kept up to date on any important changes. This moderated list is intended to be a low (nearly zero) traffic mailing list to keep the people using our dnsbl up to date on any important changes or developments. You can subscribe to list@njabl.org by sending an email to list-subscribe@njabl.org.

If you would like to discuss anti-spam issues with other interested users of dnsbl.njabl.org, there's antispam@njabl.org. This list was setup to handle traffic tangentially related to njabl.org, but not appropriate for list@njabl.org. You can subscribe by sending an email to antispam-subscribe@njabl.org.

Note: Before using any DNSBL, you really ought to be sure you know how to override a listing (locally whitelist an IP) as you may eventually need to receive email from a listed IP. For sendmail users, this can be done in the access db or via this dnswl feature based on sendmail's dnsbl feature. Note: a typo was noticed and fixed (4-29-2004) in this m4 that may have caused m4 to fail with strange errors when building your sendmail.cf.

The NJABL.ORG dnsbl zones are currently available in query mode as a dnsbl format DNS zone and can be copied via rsync. Currently, all entries resolve to one of the following:

  • 127.0.0.2 - open relays
  • 127.0.0.3 - dial-up/dynamic IP ranges. This type is deprecated. We no longer list dial-up/dynamic IP ranges. For that data, we recommend the Spamhaus PBL.
  • 127.0.0.4 - Spam Sources
    This will include both commercial spammers as well as some dial-up direct-to-mx spammers and open proxies as it's not always possible to differentiate between these sources. For commercial spammers, once we have spam on file from some of their IPs, we may add their entire IP range if it can be reliably determined.
  • 127.0.0.5 - Multi-stage open relays
    Before adding multi-stage open relays to our list, we make an attempt to notify the NIC contacts for their IP space and give them at least one week to fix their systems. This type is deprecated. We no longer list multi-stage open relays.
  • 127.0.0.6 - Passively detected "bad hosts"
    These hosts have done things a proper SMTP server should not do. They're very likely to be spam proxies. We can't say much more about this. No supporting evidence is made available for listing these IPs.
  • 127.0.0.8 - Systems with insecure formmail.cgi or similar CGI scripts which turn them into open relays
    This includes the output IP when a server with an insecure formmail CGI smarthosts outgoing email through another server or servers.
  • 127.0.0.9 - Open proxy servers
Non-dial-up range entries will often have a descriptive TXT record which should indicate why the entry was added.


Currently, the following zones exist:
  • dnsbl.njabl.org: the original NJABL zone (combination of the above 127.0.0.x types except for 127.0.0.6)
  • dynablock.njabl.org: Do not use. This subzone has been shut down! For a similar better DNSBL, use the Spamhaus PBL.
  • combined.njabl.org: This zone used to be a combination of dnsbl.njabl.org and dynablock.njabl.org in a single zone (to reduce the number of queries for sites wanting to use both zones). Since dynablock.njabl.org has been shut down, combined is currently just a copy of dnsbl.njabl.org.
  • bhnc.njabl.org: Bad host, no cookie. These hosts have done things proper SMTP servers don't do. They're either horribly broken / misconfigured servers or, far more likely, spam proxies. We can't say much more about this. No supporting evidence is made available for listing these IPs.
  • qw versions of all of the above for use by NJABL contributors
  • Additional zones may exist for testing purposes, but if you find out about them and they're not listed here, don't be shocked if they change or disappear without notice.
If you're using sendmail, edit your sendmail.mc file, and add a line such as:
FEATURE(dnsbl,`dnsbl.njabl.org',`Message from $&{client_addr} rejected - see http://njabl.org/lookup?$&{client_addr}')
and/or
FEATURE(dnsbl,`dynablock.njabl.org',`Message from $&{client_addr} rejected - see http://njabl.org/lookup?$&{client_addr}')
or just
FEATURE(dnsbl,`combined.njabl.org',`Message from $&{client_addr} rejected - see http://njabl.org/lookup?$&{client_addr}')
Then rebuild your sendmail.cf and restart sendmail. Note: This syntax is not available in sendmail versions prior to 8.10.x. For older versions, check to see if you have the old rbl syntax, or upgrade. Very recent versions of sendmail support a new feature called enhdnsbl that allows you to specify which 127.0.0.x result codes you want to take action on and ignore the rest.

If you're using qmail, the following links should be useful:
rblsmptd documentation
You'll need to get one of the rss patches for either ucspi or rblsmtpd from mail-abuse.org since most of our dial-up entries do not have TXT records.

Our dnsbl can also be used to tag potential spam messages (letting individual users decide what action to take) using Spamassassin. After you have Spamassassin properly installed, add the following to your local.cf, probably /etc/mail/spamassassin/local.cf: (note: according to the Spamassassin developers, these rules will only work with Spamassassin up to version 2.5x and will not work properly with Spamassassin >= 2.6x). Also note, NJABL is included in later versions of Spamassassin in its default config. You really shouldn't be running a version of Spamassassin old enough that it lacks NJABL rules...so there's no need to muck about with custom NJABL rules unless you want to change the default scoring or use NJABL zones not in the the default config.
header IN_NJABL_ORG    rbleval:check_rbl('njabl','dnsbl.njabl.org.')
describe IN_NJABL_ORG  Received via a relay in dnsbl.njabl.org
tflags IN_NJABL_ORG    net 

header NJABL_OPEN_RELAY         rbleval:check_rbl_results_for('njabl', '127.0.0.2')
describe NJABL_OPEN_RELAY       DNSBL: sender is Confirmed Open Relay
tflags NJABL_OPEN_RELAY         net

header NJABL_DUL                rbleval:check_rbl_results_for('njabl', '127.0.0.3')
describe NJABL_DUL              DNSBL: sender ip address in in a dialup block
tflags NJABL_DUL                net

header NJABL_SPAM_SRC           rbleval:check_rbl_results_for('njabl', '127.0.0.4')
describe NJABL_SPAM_SRC         DNSBL: sender is Confirmed Spam Source
tflags NJABL_SPAM_SRC           net

header NJABL_MULTI_STAGE        rbleval:check_rbl_results_for('njabl', '127.0.0.5')
describe NJABL_MULTI_STAGE      DNSBL: sent through multi-stage open relay
tflags NJABL_MULTI_STAGE        net 

header NJABL_CGI        rbleval:check_rbl_results_for('njabl', '127.0.0.8')
describe NJABL_CGI      DNSBL: sender is an open formmail
tflags NJABL_CGI        net

header NJABL_PROXY      rbleval:check_rbl_results_for('njabl', '127.0.0.9')
describe NJABL_PROXY    DNSBL: sender is an open proxy
tflags NJABL_PROXY      net

score IN_NJABL_ORG              0.38
score NJABL_DUL                 0.62
score NJABL_MULTI_STAGE         0.75
score NJABL_PROXY               3.00
score NJABL_OPEN_RELAY          3.00
score NJABL_CGI                 1.50
score NJABL_SPAM_SRC            3.00

For information on how to use dnsbl format lists with other mail server software, see your documentation, ask your vendor, or search the net.

Important notes for "SMTP after POP" or SMTP-Auth setups:
Some SMTP after POP setups, especially poprelayd + sendmail, may need some additional configuration to avoid rejecting SMTP relay access to authenticated IPs which are within listed dial-up/dynamic IP ranges. With poprelayd + sendmail, you'll need to duplicate the rules poprelayd says to add to SLocal_check_rcpt in SBasic_check_relay before the dnsbl rules. This will effectivley whitelist authenticated IPs.

Similarly, sendmail setups using AUTH may have issues with roaming users being blocked even though they have authenticated. The most likely solution for this is FEATURE(`delay_checks'). This feature has other side effects though that may influence what you want in sendmail's access.db. Check the sendmail cf README for more information on this.



Last modified: Sunday, 30-Sep-2007 07:59:41 EDT