www.joreybump.com/code/howto/nolisting.html
Nolisting fights spam by specifying a primary MX that is always unavailable. 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.
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 violators of this specification exist for 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. 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 many noncompliant clients exist as sources of spam or viruses. 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. 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. Nolisting is simple to set up, but requires privileges that are only available to administrators. 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 decreased 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. 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. 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. 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). 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. 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 believ...
|
http://csua.com/feed/