Unlisting
Selective Unlisting
- What is Selective Unlisting?
Rather than applying Unlisting to all connections, it is possible to apply it to select networks using carefully crafted filter rules.
- What problem does it solve?
Selective Unlisting gives an administrator the ability to stop a significant amount of fire-and-forget spam originating from networks that are considered low priority sources of email. In particular, it is highly effective against direct-to-secondary-MX spam that bypasses Nolisting.
Unfortunately, when Unlisting is applied to all connections, a rare (but likely) problem is that a site using round robin techniques to retry delivery could be intermittently blocked, because the connection may originate from an IP address that hasn't recently tried the primary MX, a prerequisite for access to the secondary MX. To the packet filter, this appears to be a direct-to-secondary-MX connection, so it blocks it. In most cases, this will only delay mail, but, under the right combination of circumstances, a retrying host could be blocked long enough to cause the mail to be returned to the sender (but not lost).
Selective Unlisting does not solve this problem, but it mitigates it by narrowing the risk to specific networks. A site may suffer from so many direct-to-secondary-MX attacks that an administrator is willing to risk the possibility of false positives from offending networks that are not a significant source of legitimate mail.
- Does it work with Nolisting?
Yes. The combination of Selective Unlisting and Nolisting increases the defense against fire-and-forget spam. Nolisting can be applied to all networks with little or no risk to stop fire-and-forget spam aimed at the primary MX. Selective Unlisting can then be used to block direct-to-secondary-MX spam from the worst offending networks. To achieve this, the Unlisting rules targeting specific networks must be evaluated before the Nolisting rules, to properly set the flag that allows hosts to connect to the secondary MX after trying the primary MX.
- Doesn't this balkanize the Internet?
Perhaps, but some networks are worse than others. An administrator should be careful about how wide to cast the net when selecting networks for Unlisting. It's unlikely that many sites will focus on the same networks. Sites that process a lot of international mail should proceed cautiously, and focus on subnets containing the worst offenders, instead of entire registries.
- How do I configure Selective Unlisting?
Selective Unlisting requires a complete understanding and evaluation of Nolisting. You must set it up first. The following directions will be meaningless without a working Nolisting setup. It is also important to read and fully understand the concepts behind Unlisting, as well as its caveats, before proceeding.
Once you have Nolisting configured and working properly, all that's needed for Selective Unlisting is to place groups of rules before the Nolisting section (while it's no longer technically necessary to run Nolisting, it is still highly recommended). Each group will target a specific network. In our example, we'll use CIDR notation, but another option is to use the iptables
rangemodule.Our example uses a single machine with two IP addresses. The primary and secondary MX records are configured in DNS to use these IP addresses. In the example, the primary MX resolves to 192.168.1.3 and the secondary MX resolves to 192.168.1.4. An SMTP server is configured to listen on both of these addresses. The example machine uses iptables as the packet filter, and it must have the
recentmodule loaded into the Linux kernel. These iptables commands will allow Unlisting to be applied to the specified networks:iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.3 --dport 25 -m recent --set --name UNLIST -j REJECT --reject-with tcp-reset iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -m recent --rcheck --name UNLIST --seconds 4000 -j ACCEPT iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -j REJECT --reject-with tcp-reset
Order is important, and these rules should be appended in an appropriate location when using firewall scripts. Once again, these rules must appear before a Nolisting section. In the output from iptables -L, these rules should appear together, in this order:
Chain INPUT (policy ACCEPT) target prot opt source destination REJECT tcp -- 10.0.0.0/16 mx1.example.com tcp dpt:smtp recent: SET name: UNLIST side: source reject-with tcp-reset ACCEPT tcp -- 10.0.0.0/16 mx2.example.com tcp dpt:smtp recent: CHECK seconds: 4000 name: UNLIST side: source REJECT tcp -- 10.0.0.0/16 mx2.example.com tcp dpt:smtp reject-with tcp-reset
Our example targets the IP address range 10.0.0.0 - 10.0.255.255, or 10.0.0.0/16 in CIDR notation. To add more networks, simply add sections specifying new source networks.
Source Documentation
RFC 2821: Simple Mail Transfer Protocol (SMTP)
Netfilter: Firewalling, NAT, and Packet Mangling for Linux
IPTables/Netfilter Recent Module