How do we decide which IP's to add to the list?
- Automated testing:
- We are not scanning the entire internet for open
relays like some other groups have done.
- We perform an
automated open relay and open proxy test against any system that connects to any of the SMTP
servers on networks that contribute relay data to the list. This is analogous to IRC
servers that scan all connecting clients for open proxies in order
to reduce abuse of these open services on the IRC networks.
- We share open proxy data with several other DNSBLs, and do our own
verification of open proxies other DNSBLs have found and sent to us.
- We keep track of IPs
that have been tested in order to avoid automated retesting of the same IP
more than once per a set period of time.
- Our testing engine first checks for open proxies on a number of ports.
If none are found, it tries to open an SMTP connection and attempts to relay
mail using a variety of
TO/FROM addresses in an effort to find not only wide open relays, but also
those that only relay for certain FROM address formats or those that can be
fooled into relaying by playing formatting games with the TO/FROM addresses.
The TO/FROM combinations we try may change from time to time or be different
depending on the software the remote server appears to be running. The best way
to see a full list of our current TO/FROM combinations is to request testing
and watch the test as it happens. See "Requested testing" below.
- Our relay test messages
utilize an encrypted message which makes them nearly impossible to forge.
Our reception of the intact open relay test message and decryption of the
message body indicates the system it was sent through is an open relay
and results in that IP being added to the list. Servers that accept the
message but do not relay it, are not falsely detected as open relays. Our
system must receive and successfully decrypt the test message in order to
detect an open relay.
- Open SMTP relay IPs in our list expire (and get retested) after 90 days.
Other types of IP listings do not expire and are not automatically retested.
Once listed, an IP will remain listed until it expires (only applies to open
SMTP relays), is removed via the removal form,
or by hand.
- The net result is once an open system delivers mail into a
participating network, it will be detected, and listed, thus preventing
future spam. This may happen even if the relay or proxy has never been used to relay
spam. As far as our testing is concerned, an open relay is an open relay,
and we list open relays (and proxies).
- Requested testing:
- If you would like your server tested, use telnet to connect to
port 2500 on rt.njabl.org from the server you want tested. Your server will
be tested and you will see the results of the test as it is
Note: If you are not sure how your system was used as an open
relay, you can telnet as instructed above and the SMTP conversation will
display in real time as your system is (re)tested, demonstrating the
combination of to/from addresses which result in your system acting as an
- If you would like your entire network or a range of IP space you own to
be tested, contact help mail.njabl.org.
- Manual header parsing & testing:
- A select few experienced network administrators
have access to add IP ranges for dial-up ranges or direct spam sources.
These are normally found by manually parsing message headers from spam
delivered to any of our spamtrap email addresses. Dial-up
ranges are normally verified via their in-addr.arpa DNS or whois info. Multi-stage open relays may also be listed when their
admins are not responsive to complaints.
- A disturbing trend that we have noticed is open relays that accept SMTP connections on one IP, but
transmit outgoing relayed mail using a different IP address. In some cases
we have noticed this happening after a server has been listed. i.e.
Automated testing discovers an open relay and lists it. A few weeks
later, that relay is still open, but sends its outgoing email from a
different source IP address without any SMTP header entries explaining how
the message might have gotten from the input IP to output IP. These open
relays are not considered multi-stage, are listed immediately upon
discovery, and cannot be removed from the list via our removal form.
After the input IP has been fixed, the output IP will need to be removed
manually in response to email sent to removals at mail.njabl.org. Mail to
removals must include a 4 byte dotted quad IP in the subject or it will be
- When spam is received from a relay that does not accept SMTP
connections, this is often a case of different input/output IP's on an open
relay as mentioned above. In these cases, if the IP has a PTR record, we
will test the MX records for the domain indicated in the PTR record. We may
also test a range of adjacent IP's, looking for the open relay input IP.
- ISP Submission:
- If you run a network and would like to submit your dial-up IP pool
ranges or other IP ranges used by end-users that should not be talking to SMTP
servers other than your own, we're happy to add them to the dial-up port range
portion of our list. Email your IP range information to help at mail.njabl.org
Currently, the re-check interval is 4 weeks if the IP is reachable.
This means you should not notice our relay test probes more often than
once every 4 weeks. Note however that each time your system is tested,
you will likely see several log entries as our relay test program tries
relaying using a variety of to/from addresses. IP's that are unreachable
or refuse the SMTP connection when tested are retested more frequently.
Verification of open proxies sent to us by other DNSBLs is attempted
regardless of whether those IP's have been tested recently.
A multi-stage open relay is a system that relays mail for other systems
that are open relays. i.e. System A is a mail server that accepts mail from
anywhere and sends all non-local mail through system B. System B is not an
open relay itself, but is setup to accept and relay mail for A. Spam dumped
on A gets sent to B, and B then delivers it to wherever it's going. Even
though the configuration problem is on A, the admins of B are forced to deal
with the problem since theirs is the system that will deliver the spam and