Chris-Linfoot.net

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 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. 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.).

If this sounds familiar, it should.

As I pointed out at the time, my attempt at what is now called "nolisting" failed. However, there is a difference between nolisting the way I implemented it and nolisting as documented here.

• My nolisting had an SMTP service listening on port 25 of a preferred (i.e. lowest preference number) MX, but returning a 421 transient failure. In this way we can count attempts to connect there, however it seems to confuse some remote SMTP clients.
  
  
• Nolisting done this new way has a host named as preferred MX for the domain, but not listening at all on port 25.

That might actually work better, though it is not possible to measure its efficacy.

Nonetheless, I may still give it a try.

Category: Domino: Administration
Technorati: Nolisting

1. Chris Siebenmann08/02/2007 06:01:24
Homepage: http://utcc.utoronto.ca/~cks/space/blog/

In theory, it would be possible to use an IP accounting system to count how many different IP addresses tried to connect to the non-responding primary MX (or, with slightly more data collection work, get a list of them). Then you could compare it with connection logs from your secondary MX to find out how many actually bothered to fall back to your secondary MX.

(You could also use the data in reverse, to find IPs that only tried to connect to your secondary MX and never tried to connect to the primary.)

2. Scott Iver16/02/2007 16:36:27

Previously you've shown (quite convincingly) that when the primary MX is up and running, 100% of connections to the 2ndary MX were spam. By setting up a "bogus" primary MX (thus forcing all sending servers to try connection, fail and retry to 2ndary MX) aren’t we going to see more spam, since the spammers are hitting your 2ndary MX record in the first place (now actually your primary MX)?

About the only way I see around the above, would be to create 3 MX records, Primary ("Fake" no SMTP), Actual Mail server, and 3rd "Fake" MX. Setting someting like Fake1 10 , Real 30 , Fake2 60

My thinking is that with this, spamware trying to hit your lowest priority MX is foiled, and spamware trying to hit your highest priority MX is foiled, but legit server's trying to connect will retry and get the middle (real) MX.

Thoughts?

3. Chris Linfoot19/02/2007 09:30:19

Correct.

4. Scott Iver19/02/2008 18:18:05

Chris,
Just wanted to post a follow up note. I implemented the "no listing" with a twist (per my prior comment) just a few days after posting my last comment. So it's been running for about a year now.

It actually does seem to help a bit with the volume of SMTP connections to the mail server. The number of connections dropped nearly 30%, and no ill effects have been reported due to this configuration.

My suggestion: If your experiencing a very high number of SMTP connections by "direct to MX bots", then give this a try if you know what your doing with DNS. You can expect to see a significant drop in total volume of connections.

Unable to post a comment? Please read this for a possible explanation...