Nolisting

Nolisting is a method of defending electronic mail users against e-mail spam. The idea is that by having a non-existent primary mail server and a working secondary mail server, attempts to contact the primary mail server will always fail. If the mail is sent by a correctly configured email server, the sending server will then try to contact the secondary mail server, and should succeed. Spammers frequently use custom software that does not retry low-priority MX records.

Nolisting refers only to a configuration involving an unresponsive single primary MX with one or more functional lower priority MX servers. This configuration has been proven to be very safe. Variations involving multiple unresponsive MX records do not meet this definition (and there is little evidence supporting the effectiveness of such an approach).

Spammers are known to sometimes bypass the primary mail server and contact the lowest-priority (highest preference number) mail server first (in violation of RFC 2821). This is because backup mail servers often have less stringent spam filters and security checks and spam that would get blocked by the primary is often accepted by the secondary. This is an old technique that Nolisting does not specifically address; however, it does increase the likelihood that the spam will be handled by the working secondary mail server (especially in environments with no backup MX).

Unlike real email servers, spam sources often don't retry on failure. Thus the failure to deliver on the first attempt causes the spammer to move on to the next victim. Legitimate email servers will retry the next higher numbered MX and the email is delivered with no significant delay. The result is that a significant amount of spam bot spam just goes away. It also reduces the load levels on the server as less spam has to be processed by spam filtering software. This technique is sometimes referred to as "poor man's greylisting" because it is easy and inexpensive to implement.

Drawbacks

Downsides to this technique include increased traffic from those spam programs that send to all MX records listed, and the danger of unknowingly losing mail from an improperly configured mail transfer agent (MTA) or script. At least some nolisting uncovers applications written using JavaMail do not retry using the next highest priority MX.

This technique relies on spammers using custom software that ignores the SMTP protocol. As such, it is not a viable long-term solution. Spammers can thwart Nolisting by simply using standard email server software or by adding a little error-recovery to their custom software. Thankfully, Nolisting can be easily abandoned if it ceases to be useful.

Implementation

Here is a simple example of MX records that demonstrate the idea:

MX 10 dummy.example.com.
MX 20 real-primary-mail-server.example.com.

This defeats spam programs that only connect to the highest priority (lowest numbered) MX and do not follow the required error-handling by retrying the next priority MX.

The highest priority (lowest numbered) MX should be completely unresponsive on port 25 and should not connect and return a 4xx error. MTAs such as Qmail interpret the rules differently and if a standard Qmail server sees a 4xx response on the primary server it will not retry on the higher numbered MX records. Qmail will retry until it gives up and the good email will be lost. However if port 25 is dead Qmail will retry the higher numbered MX servers.

Some SMTP applications are very crude and only send to the lowest numbered MX record. This is rare but it does happen. One solution is to block port 25 to the world on your lowest MX with iptables but to have exceptions so that specific IP addresses can get through.

Nolisting should only be implemented on a network under the domain administrator's control. While a "nolisting service" may sound attractive and ease implementation, it hands complete control of all incoming mail to a potentially untrustworthy third party. It would be trivial to selectively accept sensitive mail from specific domains without detection.

Similar techniques

Note that the Nolisting technique uses a non-existent primary mail server, which is compatible with all correctly configured mail servers. There are alternate techniques that use a "non-responding" mail server (i.e., one that accepts connections but does not send data) or that use a server that accepts connections and reports an error for all SMTP commands. These are not the same as Nolisting, and are not compatible with the SMTP protocol (even though it may work with some mail servers).

Configurations involving multiple fake MX records may be counterproductive, serving only to increase network traffic with spam that would not have existed otherwise.

See also

• Greylisting

External links

• Nolisting: Poor Man's Greylisting
• Fight Spam With Nolisting article on Slashdot
• Other Trick for Blocking Spam where the concept of using fake MX records was discussed.