Nolisting
Poor Man's Greylisting
- What is it?
Nolisting reduces the amount of fire-and-forget spam an MTA must process by specifying a primary MX that is always unavailable.
- Is it the same as greylisting?
No, but it exploits the same noncompliant behaviour of spamware and viruses, including those that spread via internal SMTP engines. Greylisting is an approach promoted and rigorously tested by Evan Harris. It is sensible, RFC-compliant, time-proven, and valuable as one part of a multilayer defense against spam. For more information about greylisting, visit Greylisting: The Next Step in the Spam Control War.
- How does Nolisting work?
It has been observed that when a domain has both a primary (high priority, low number) and a secondary (low priority, high number) MX record configured in DNS, overall SMTP connections will decrease when the primary MX is unavailable. This decrease is unexpected because RFC 2821 (Simple Mail Transfer Protocol) specifies that a client MUST try and retry each MX address in order, and SHOULD try at least two addresses. It turns out that nearly all violations of this specification serve the purpose of sending spam or viruses. Nolisting takes advantage of this behaviour by configuring a domain's primary MX record to use an IP address that does not have an active service listening on SMTP port 25. RFC-compliant clients will retry delivery to the secondary MX, which is configured to serve the role normally performed by the primary MX (final delivery, transport rerouting, etc.).
- I need proof.
To evaluate the effectiveness of Nolisting, it is necessary to monitor connections to both MX hosts while the primary is unavailable. The most thorough approach would be to collect all packets, categorize them according to the behaviour of the connecting client, then inspect the content of each message to determine if it is spam. Nolisting will be proved effective if most of the connections from clients that don't retry the secondary MX serve only to deliver spam, viruses, or other unwanted email. It should be noted, however, that a legitimate client may retry from a different IP address, resulting in two separate IP addresses connecting to the primary and secondary MX hosts.
To simplify analysis, I use a script to categorize the connecting hosts and check them against a list of DNSBLs that reliably indicate spam for the monitored location. Here is a sample report summary based on a packet capture:
# Total SMTP packets: 10000 # Total source hosts: 579 100% (DNSBL: 480 82%) # Both MX: 128 22% (DNSBL: 46 35%) # Single MX: 452 78% (DNSBL: 434 96%) # Primary only: 331 57% (DNSBL: 325 98%) # Secondary only: 121 20% (DNSBL: 109 90%)
This is compelling evidence that most clients that do not retry the secondary MX are sources of spam or viruses (a compliant domain may retry from a different IP address, however). It also indicates that fire-and-forget spam aimed at primary MX hosts is still widespread and may be much more popular among spammers than targeting lower priority backup MX hosts.
Note that these results were compiled on a site that was carefully configured to avoid unpredictable effects introduced by using IP addresses with a history of handling mail. Such analysis can produce markedly different results on another site, for various reasons.
It is useful to run this analysis at regular intervals following the initial packet capture to reveal another beneficial side effect of Nolisting: Because the technique penalizes bad behaviour, it will stop a selection of attacks that are not yet present in content filters or DNS blackhole lists. Of course, as hosts are added to blacklists, others will be delisted. Therefore, it is important to save snapshots of the analysis shortly after the packet capture in order to accurately demonstrate the effectiveness of the technique.
- How do I install it?
Nolisting is not an application that requires installation. At its simplest, it involves a minor change to the MX records in a domain's DNS zone file. Enhanced performance and even failover can be provided by integrating a firewall, but this is not a requirement.
- What are the requirements?
Nolisting is simple to set up, but requires privileges that are only available to administrators. It is not configurable by end users. To configure Nolisting, an administrator must have the following:
- the ability create MX records for the destination domain
- a spare public IP address, within the administrator's control, that has no listening service running on SMTP port 25
- cooperation of all staff with administrative control over related network resources
- optionally, a packet filter on the IP address specified as the primary MX (recommended)
- Does it use extra resources?
Load should actually decrease on the destination mail server, because the number of SMTP connections to the mail transfer agent (MTA) decreases. Users of CPU-intensive spam filters and virus scanners will appreciate the additional processing power that is made available. The MTA will also make fewer DNS queries, thus lightening the load on the resolver and possibly limiting the ability to use DNS as an attack vector.
- Is it nice?
Nolisting forces legitimate mailers to retry delivery to the secondary MX for every message that is sent. The effect is negligible, and delays are virtually nonexistent, with most clients retrying within the same second when using a firewalled approach or active host with no SMTP listener. In this respect, Nolisting imposes less of a penalty on clients than conventional greylisting, and offers an attractive alternative if greylisting introduces unacceptable delays or maintenance overhead.
If using an IP address with no device attached, a connecting host will wait according to its own timeout values before retrying the secondary MX. This delay is normally acceptable (and even undetectable) by end users, but it can adversely affect content filter chains that attempt to keep original connections open until delivery status is confirmed (with milters, before-queue content filters, or sender address verification, for example). For this reason, it is recommended to use a packet filter rule that immediately returns a TCP RESET, simulating a connected machine that is not listening on port 25.
- I have a machine on an IP address that doesn't listen on port 25. Can I designate it as the primary MX?
Yes, but with caution. If port 25 becomes active with a listening MTA at any time, you are likely to lose mail. It is preferable to configure the primary and secondary MX IP addresses on the same machine, blocking the primary MX with a packet filter rule. This technique provides builtin failover if the firewall is turned off and allows Nolisting to be disabled simply by removing the packet filter rule, as long as the MTA is listening on both interfaces.
Some sites use the MX hosts of external spam filtering services. In such environments, it may be useful to designate a Nolisting primary MX host to reduce the amount of mail being processed by these services. This should be safe, but monitoring will be difficult. Such services often provide quarantines to allow the retrieval of false positives, and should not be held liable for any messages that were unable to pass a Nolisting primary MX (although senders will be notified by their own MTAs in case of a nondelivery).
- Can I share the same primary MX among multiple domains?
This is safe under one of the following circumstances:
- The primary MX record points to an IP address with no attached device
- The primary MX record points to an IP address with no MTA listening on port 25 on the external interface, and it will never send email to the domains for which it is the primary MX
- The primary MX record points to an IP address that is blocked on the external interface on the same machine as an MTA that accepts mail for every domain that lists it as the primary MX
You must never list as the primary MX an IP address on a machine with an active MTA that does not accept messages for the domain, or a "mail loops back to me" error might occur when the MTA tries to send a message to that domain. This will happen when the MTA has access to the interface that is firewalled against outside connections, but not internal ones. It will think it is the MX, but find that it is not configured to receive and deliver mail for the domain.
- I don't have a spare IP address. Can I use an undefined host, loopback address or bogon?
No. While testing shows that an undefined host (where the DNS server returns NXDOMAIN for a query) is fast and easy on resources, it is not RFC-compliant (all MX records must point to a host with an A record), so one cannot harbour any expectations concerning the behaviour of MTAs that encounter it. Most MTAs attempt redelivery to a secondary MX, but significant exceptions have appeared. At least one major ISP's MTA gets very confused when it sees NXDOMAIN in an MX query, and returns a nondelivery notification to the sender before it successfully retries the secondary MX. Unfortunately, the sender now believes that the message wasn't delivered and tries to resend it, with varying success. This will only serve to make your site appear to be poorly managed. In short, use the RFC-compliant approach, and everyone will be happy (except the spammers).
It should also be noted that some administrators view the use of NXDOMAIN, loopback (localhost or 127.0.0.1/8) or bogon (specially allocated) addresses in MX records to be an indicator of spam, and establish local policy to block on this criteria. While I don't feel that it is wise to block on NXDOMAIN (DNS misconfigurations are common), it is a matter of choice, and use of these addresses on public networks can't be defended by a responsible administrator. Do the right thing; it's easier in the long run.
- Can this be detected?
No, you simply have a broken primary MX.
- Can I get blacklisted for this?
No, you simply have a broken primary MX. Of course, someone could compile a list of unresponsive MX hosts, but there's no conclusive way to determine that a site employs Nolisting.
- Is it safe?
Nolisting involves multiple protocols and network resources. Implementation requires precision, coordination, strict discipline, and is vulnerable to human error. If this is beyond the ability of you or your staff, don't do it.
Having said that, once it is properly configured, there is no additional maintenance, and longterm use has yet to yield a single false positive on the low volume sites used during testing. However, I make no guarantees, and you should accept none.
- Is it secure?
A beneficial side effect of Nolisting is that it reduces the exposure of software to undesirable messages. Email flows through a gauntlet of MTAs, LDAs, MUAs, and complex filters designed to detect spam and viruses. More lines of code means more bugs. The early detection provided by Nolisting is an inexpensive way to reduce exposure to risks introduced by software.
- Can I whitelist hosts?
Because Nolisting involves multiple protocols, whitelisting may pose a challenge. When using a firewall to control access to the primary MX host, the packet filter can easily be adjusted to whitelist specified hosts or networks. But I hate maintaining whitelists, and my intense desire to avoid such chores is why I seek out solutions like this. Nolisting is named after the ideal that it involves no lists.
While it may appear to be useful to set up a bind acl list with a view to selectively offer DNS responses, it is difficult to reliably and consistently identify the resolvers used by the whitelisted hosts. Even if the resolver is known, the network it serves may contain zombies. Nolisting provides protection against exploited hosts on networks presumed to be friendly, and the penalty to legitimate hosts is so small, whitelisting may not offer enough value to justify the additional maintenance.
- Should I define multiple unavailable high priority (low number) MX hosts?
Absolutely not! To be clear: Nolisting specifies only a single nonfunctioning primary MX. Any other variation is not Nolisting.
Although spamware is constantly evolving, most of it falls within at least one of the following categories:
- it is RFC-compliant and retries MX hosts in order until delivery is successful
- it targets only the primary MX, without retrying other MX hosts
- it targets only secondary (low priority) MX hosts, where checks may be weaker, without retrying other MX hosts
- it targets all MX hosts, either randomly or systematically
With these possibilities in mind, along with the seemingly unlimited resources of spammers, it stands to reason that each MX record enlarges the target. At some point, the law of diminishing returns may adversely affect bandwidth, maintainability, and IP address portability.
Even more important, the RFC requires that connecting hosts retry delivery to MX hosts in order of priority, but does not recommend to what depth (other than trying at least two addresses). Testing has shown that different MTAs give up at different points, and the number of retries may be controlled by local policy (adding even more variation), so it is best to limit MX records to the least number necessary. For example, recent versions of Postfix try a default limit of 5 MX hosts, configurable via smtp_mx_address_limit.
For the same reason, it is important not to multihome the unavailable primary MX host (where the host name has multiple A records resolving to different IP addresses). For safety and simplicity, designate a single primary MX record that resolves to a single IP address.
- Won't I get less spam simply by defining a single MX record?
You'd think so, but this doesn't seem to be the case. A single MX host is the primary, secondary, and all MX hosts rolled into one, so it is the target of all categories of spamware. Adding a second MX to a domain that has had only a primary MX defined will cause a slight increase in the amount of direct-to-all-MX spam. RFC-compliant spam will not increase. Direct-to-secondary-MX spam will not increase. Fire-and-forget spam aimed at the primary MX will not increase. At the time of this writing, Nolisting causes the overall percentage of spam rejected by the MTA to decrease, suggesting that a significant amount still uses a fire-and-forget approach aimed at the primary MX. Therefore, Nolisting appears to be more effective than defining a single MX record. Because the number of ham messages remains the same, a lower percentage of spam rejected by the MTA is a reliable measure of effectiveness.
- Can I still specify a functioning backup MX at the lowest priority?
Yes, but additional configuration may be necessary in order for it to deliver to your functioning MX.
Also note that if it does not employ the same policies against unwanted mail, there will be a decreased benefit. This applies to backup MX hosts in any environment, and is a topic that requires a separate discussion. Many administrators prefer not to use a backup MX, and Nolisting will help to funnel all connections into one environment for comprehensive filtering.
- Will adding a nonfunctioning backup MX fight even more spam?
-
I believe that each MX host defined for a domain generates more spam, and there is no merit in blocking spam that wouldn't have otherwise existed. Even if it's possible that such decoy hosts will attract spam away from the functioning MX, I believe it will cause zombies to consume even more bandwidth on the Internet. Overall, Nolisting has low impact, but adding nonfunctioning backup MX hosts will reduce that benefit.
- Why should I do this?
You shouldn't until you've weighed the risks and are prepared to test it on some low traffic domains before deploying it in evironments with a large user base. To recap, benefits include:
- less spam
- fewer viruses
- reduced load on destination mail server
- kinder to sending mail servers than conventional greylisting
- much shorter delays than with conventional greylisting
- smaller (and more concise) mail logs
- easy configuration (for administrators)
- no maintenance required
- no whitelisting necessary
- 100% RFC 2821 compliance
- no verifiable false positives to date
Nolisting also has its caveats:
- requires administrative expertise to configure
- requires coordination between protocols
- requires participation and cooperation of networking staff
- may tie up an IP address or pollute it for future MX use
- mail may be lost if an SMTP listener is unintentionally started on the primary MX, if it is a separate device
- may introduce delays in some configurations
- sending servers must retry delivery to secondary MX with every message
- difficult for senders to follow up with complaints from affected addresses
- challenging to monitor, as blocked messages will not appear in mail logs
- not in widespread use, so effectiveness hasn't been broadly confirmed
- How important is caching?
Caching is very important. Resolvers cache lookups. MTAs cache connections. Even malware will cache IP addresses to help escape detection. If you begin testing with a working primary MX (recommended), you may experience some delivery delays due to caching when you take it offline. This will typically not cause any problems. Malware that caches your MX addresses for eternity will attempt delivery to those addresses forever, which is something to consider if you intend to use the IP address for SMTP in the future.
- Enough talk. Show me how!
-
First, if you've skipped ahead, go back and read this document from the beginning. I normally start out with simple configuration instructions and explain them in detail afterwards, but it's extremely important to understand the concepts and caveats of Nolisting before using it.
Here is a sample Bind 9 DNS zone file for example.com (it uses bogons, so replace them with IP addresses within your control):
$ORIGIN . $TTL 3600 ; 1 hour example.com IN SOA ns1.example.com. admin.example.com. ( 2006052501 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 1209600 ; expire (2 weeks) 3600 ; minimum (1 hour) ) NS ns1.example.com. NS ns2.example.com. MX 5 mx1.example.com. MX 10 mx2.example.com. $ORIGIN example.com. ns1 A 192.0.2.1 ns2 A 192.0.2.2 mx1 A 192.0.2.3 mx2 A 192.0.2.4 www A 192.0.2.5
It is important to use short TTL values during initial setup, allowing the configuration to be easily and quickly reversed in the event of trouble. Do this well ahead of time so that the old TTL values are no longer in effect. Select TTLs that you think are reasonable for testing. When you are satisfied that Nolisting works well for your site, increase the TTLs for optimum performance. If you don't understand this, hire someone that does.
Be sure that no MTA is listening on the IP assigned to the primary MX, and you have a working Nolisting system. It is alright to have a device at that address, if:
- it doesn't, and will never, listen on port 25 while Nolisting is in effect
- it is also the secondary MX, with port 25 of the primary MX IP address blocked by a packet filter rule (recommended)
To reduce delays caused by connecting hosts waiting for a response, use a packet filter to issue a TCP RESET on port 25 of the primary MX address. A suitable iptables command would be:
iptables -I INPUT -p tcp -d 192.0.2.3 --dport 25 -j REJECT --reject-with tcp-reset
A pf rule would look something like this (where $exif has been defined as the external interface, and $primary as the primary MX IP address):
block return-rst in on $exif inet proto tcp from any to $primary port smtp
To introduce a convenient failover, configure another interface (or virtual alias interface) to use the primary MX IP address on the same machine as the secondary MX. If the MTA is listening on both interfaces, disabling the packet filter rule will simply render the primary MX operational again. This is also recommended for monitoring, allowing connections and mail logs to be viewed or parsed in one location. Keep in mind that when using this configuration, it is very likely that the MTA will have access to the primary MX IP in a typical firewall configuration, and might use it after looking up the primary MX of domains for which it is the destination. This is normally fine, and it's simpler to allow this than to add more complex configuration or filter rules.
That's it! There is no further configuration.
- How can I tell it's working?
-
Try it! Here's an example using telnet, to prove that the primary MX is blocking connections (using the firewalled approach) and the secondary MX is accepting them (in this example, the MTA is Postfix):
jorey@oshkosh ~$ telnet mx1.example.com 25 Trying 192.0.2.3... telnet: connect to address 192.0.2.3: Connection refused jorey@oshkosh ~$ telnet mx2.example.com 25 Trying 192.0.2.4... Connected to mx2.example.com. Escape character is '^]'. 220 mx2.example.com ESMTP Postfix quit 221 2.0.0 Bye Connection closed by foreign host.
The next crucial step is to use accounts at other ISPs to ensure they follow the RFC and try each MX host in order. Simply send yourself an email, and wait for it to show up in your INBOX. If it doesn't, you'll need to check your mail log for possible rejections, then monitor connections with a tool like tcpdump to see if the ISP is properly connecting to your secondary MX.
Some sites will notice a difference right away, due to the significant drop in spam. Sites that already have extremely effective antispam measures will see less of a change in mailboxes, but might notice a sudden decrease in MTA spam rejections, DNS queries, or CPU load.
The best evidence of the effectiveness of Nolisting requires the analysis of incoming SMTP connections. On the example system described earlier, where both MX host IP addresses are on the same box as the packet filter and MTA, one could watch connections with tcpdump:
tcpdump -nqt dst port 25 and dst net 192.0.2.0 mask 255.255.255.0
Tail the mail log in another window to see which connections actually get through to the MTA. Check the IP addresses of the ones that don't to see if they are from desirable hosts or if they are on any blacklists. Although the process is manual, it's extremely interesting to watch in real time, unless the volume is so high that the output is a blur. In that case, capture the connections to a file for later comparison against the same time period in the mail log:
tcpdump -w smtp.sniff -c 10000 dst port 25 and dst net 192.0.2.0 mask 255.255.255.0
This will capture 10000 packets to the file smtp.sniff, which you can read later with:
tcpdump -qnttttr smtp.sniff | less
Note that it's important to use the -n flag to suppress host resolution if you are also monitoring for a reduction in DNS queries. See the tcpdump man page for flags to format the output according to your needs. It's not too difficult to script parsers that will aid in analysis of the output.
- Will spammers adapt?
RFC-compliance, direct-to-secondary-MX connections, or direct-to-all-MX connections will easily bypass Nolisting. None of these approaches are new. Nonetheless, Nolisting is still extremely effective. Since Nolisting requires advanced configuration, it is unlikely to be widely adopted. Fire-and-forget spam will continue to be productive, so there is little incentive for spammers to develop a workaround.
- The decision to implement Nolisting lies with the PHB, who is nontechnical and largely responsible for the huge amount of spam and viruses directed at our domain. While your document is very informative, it is unlikely to sway him, as most of the concepts will be over his head. Can you provide a convincing argument in layman's terms?
- Yes. Nolisting increases ROI and improves manhood.
Acknowledgements
Wietse Venema, for suggesting the use of a packet filter rule that returns a TCP RESET to improve performance
Victor Duchovni, for clarifying the costs of NXDOMAIN, with a prescient warning against using it, as well as a request for more evidence
Source Documentation
RFC 2821: Simple Mail Transfer Protocol (SMTP)
BIND 9 Configuration Reference: Discussion of MX Records
Netfilter: Firewalling, NAT, and Packet Mangling for Linux