• 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 run.
    
    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 open relay.
    
    
  • 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 filtered.
  • 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 get listed.