Fight Spam With Nolisting

An anonymous reader writes with the technique of Nolisting, which fights spam by specifying a primary MX that is always unavailable. The page is an extensive FAQ and how-to guide that addressed the objections I immediately came up with. From the article: "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 behavior 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)."

Comments

Re:Oblig.

[AchiIIe]

in response to:
> (x) It will stop spam for two weeks and then we'll be stuck with it

There is another anti spam technology called (doubleverify?), if a message smells like spam the smtp server rejects it saying unavailable and waits for the sender to send it again (an hour or so later). For people who use it it works fine, but people who use it are in the minority, thus spammers won't bother writing new systems that keep track of what was rejected etc. They appeal to the (cheap) masses.

Same here, unless this becomes widely popular few spammers will adopt it. Thus there's a chance for this to work (hopefully, unlike doubleverify this is not patented)

I run a high volume mailserver, this is a bad idea

[chathamhouse]

I run a mail system that pushes ~3million messages per day. Not huge, not small.

We have thousands of domains pointed to our mail servers and secondary MX servers. Looking at the long run stats, I'd be tempted to completely disregard this technique.

When we take a primary down for maintenance, the secondaries and alternate primaries (same weight MX) see the load almost immediately.

I second the opinion that if this has any effect, it's only for low volume applications, with few/one domain.

We generally see more hits straight to the secondaries by spammers hoping for less rigorous checking. It would be interesting to profile IPs connecting to secondaries without being seen at the primary assuming a primary is always available - I bet that a very high percentage of these connections to secondaries could be viewed as spam.

The problem remains that most tricks of this sort - including greylisting - are eventually circumvented by spammers once the trick gains critical mass. Lets not forget that there are a lot of broken, yet not open relay, mail servers out there. Good engineers and administrators quickly find that Jon Postel's words ring true with their customers "Be liberal in what you accept, and conservative in what you send." - don't let your RFC enforcing configuration be responsible for delaying/blocking the delivery of that big contract your PHB was waiting for!

Re:That's "greylisting".

[Anonymous Coward]

Just an aside on greylisting: I run a large mail server and we WERE using greylisting. However we have found that many firewalls and anti-spam appliances that act as email proxies cannot respond to the 451 or 421 "try again" response used by greylisting. The appliances bounce the message back to the sender reporting it as a server failure. Unfortunately, this user group includes an ever growing number of goverment agencies and public schools. My best guess is that these appliances have no way to store the message should the first attempt at delivery fail.

I sincerely doubt that most of them would ever try more than the primary MX when delivering mail either.

Non-complience with the standards by email handling programs just makes it easier for the spammers by taking away a postmasters anti-spam tools :-(

Re:Address Book

[dgatwood]

Flowchart:

• in addressbook: goto NOTSPAM.
• address present as envelope sender in any incoming mailbox: goto NOTSPAM
• address present as recipient in any outgoing mailbox: goto NOTSPAM
• address has ever been present as envelope sender in any incoming mailbox:
  • at least one of those messages was flagged as spam: goto SPAM
  • none were flagged as spam: goto NOTSPAM
• goto SUSPECT

Re:That's "greylisting".

[RazzleDazzle]

Remember, the spammers have, effectively, unlimted bandwidth and unlimited processing power at their disposal. If the big companies started doing this with OpenBSD's spamd and generating public logs, we could get some seriously entertaining data I am sure.

From the link...

--snip log example--
This spammer got stuck for 47 minutes. Current spamd sets its socket receive buffer size to one character, forcing the sender to send one TCP packet for each byte of data, even if its a non-compliant "dump and disconnect" mailer. Of course, the spammer nearly immediately tries to retransmit the spam. Repeatedly.