Nolisting is a spam fighting technique that works by listing an unavailable MX as the highest priority (lowest MX value) mail server. The idea is that any proper mailer will detect the unavailable MX and automatically retry the next highest priority MX record.

On Feb 7th, 2012, I dedicated one of my IPs to the job of not listening for SMTP traffic, set up a host record, and then configured a few mail domains with my faux MX as the highest priority.

On March 5, I removed the faux MX records. Over the course of a month, the half dozen users of these mail domains had all experienced the loss of valid mail and noticed. Undoubtably, they lost more valid messages than they noticed.

Before I removed the faux MX records, I did some sniffing of the SMTP traffic hitting my faux MX. During observation, most of the failures I witnessed were being sent by an application written using JavaMail. Apparently it’s popular with banks (for sending account notifications), news organizations, and online photo processors.

3 Replies to “Nolisting”

  1. Hi [again] Matt,

    You’re famous (I found this article from Wikipedia). I’m curious if you recall how you were able to determine that the traffic to the faux MX was (in part) using JavaMail ? I can understand how you’d be able to log the attempted connection, but how did you see the client was JavaMail (did you actually have a mail server listening on the faux host)? It seems like the behavior of the sender could be different when dealing with a host that didn’t answer vs. one that rejected after message header data was sent. Thanks for any clarity you can add. I’m contemplating nolisting and/or greylisting at work, but first trying to get a handle on how pissed I can expect my users to get.

  2. Hi Chris,

    Short answer: I don’t remember.

    Longer answer: I did not have a server listening (see description above). I do heuristics scoring of incoming email. Some of the things I look at are the remote OS (p0f), IP, ASN number (for reputation scoring), geoIP location and distance, FCrDNS, sending MTA (again, using heuristics to determine), HELO identifiers, use or not of [opportunistic] STARTTLS, and a wide variety of headers including the Message-ID. Because I inspect and log all that info, if I needed to answer that same question today, I’d assemble a list of IPs that connected to the faux MX and not the legit MX. Then I’d cross reference that list with historical mail logs to determine what mail was lost.

    If you’re going to employ either greylisting or no listing, I recommend doing so very selectively. Maintain connection histories of legit mail servers your users use and except them from both types of listing.

Leave a Reply

Your email address will not be published. Required fields are marked *