14

I have a client that is getting heavily spammed.. It's the 15th of the month and POP3 bandwidth is almost 100 GB. There are only 7 e-mail accounts on this domain. I installed SpamAssassin set it to 5 and setup 10-20 filters reject most of the junk. I don't see much of a change in POP3 bandwidth. Correct me if I'm wrong, the server still receives the message using up bandwidth in order to analyze determine a spam score.

I stumbled across faking MX records, for thoes unaware--basically you set a bogus server as the lowest and highest MX records with the working server's MX record in the middle.

For example:

fake.example.com    1
realmx.example.com  2
fake2.example.com   3

The theory is, since majority of the spam is generated from Windows-based zombies and quite a few will query for the the highest MX record to spam since usually they're usually backup servers that don't filter spam. The lowest fake MX-record is for the rest of the spammers.. and generally spammers don't retry after failures.

Has anyone tried this? Does it help? Does it delay or cause issues with mail delivery? Does anyone else have a better solution?

10 Answers 10

15

Do yourself a favor and set them up with a gateway anti-spam service such as Postini. For a few dollars per mailbox per month, there's absolutely no reason not to and you'll not only eliminate 99% of your spam, you'll also enjoy having access to their spool service (handy for scheduled or unscheduled downtime), not to mention the bandwidth savings by letting someone else receive and process all that spam before it hits the edge of your network.

Not a Postini employee, just a happy user who's also setup dozens of clients with it.

6
  • thanks for the suggestion, that's plan B (plan C being renaming their e-mail address..lol) I do like the idea of SaaS or Front-end filtering
    – Mikey1980
    Sep 16, 2010 at 3:09
  • Although it's the the answer I wanted to hear.. my client went with Google Postini, the SPAM was out of control and without root access seemed like the only option--many thanks for the tip!
    – Mikey1980
    Sep 16, 2010 at 17:16
  • You'll love it man. Seriously: being able to turn on spooling when you're working on the server is great. Also I use them as an upstream smarthost and lock down the firewall accordingly so no matter what boxes get owned on my network(s) (including the mail server(s)), they can only talk to Postini's SMTP servers, which does outbound filtering as well.
    – gravyface
    Sep 16, 2010 at 20:02
  • Postini... huh, why not using Gmail then? ;-P
    – poige
    Feb 1, 2011 at 18:13
  • @poige: running a mail server with a gateway service is not the same as having your mail hosted with Google Apps (gmail).
    – gravyface
    Feb 1, 2011 at 20:27
12

I've tried this, and I can strongly recommend that you DON'T DO IT! It seemed like a good idea at the time, but after mail from various senders starting disappearing, I realized that it was a mistake. What I didn't realize was that there are lots of terribly written SMTP servers out there, that don't follow the spec and are fairly bad at handling errors, and people don't know or care because "this other guy got my email, so it must be you".

I second some of the other suggestions for handling SPAM. Postini is a great service, and even the built in anti-spam stuff in the free google apps isn't that bad. If you want more control you can buy an IronPort or other device, or roll your own.

3
  • 1
    Thanks Jed, exactly what I wanted.. a first-hand experience. I never thought about SMTP issues, too focused on the incoming +1
    – Mikey1980
    Sep 16, 2010 at 3:45
  • 1
    I work for an Anti-Spam company (Red Condor) and we have the highest priority records for most of our customers set to a blackhole address. However, we do have some customers remove that, because silly people write legit mailservers that only bomb that address. However, going with a SaaS hosted provider will let you offload the bandwidth load for cheap. Sep 16, 2010 at 7:42
  • @Ryan--thanks! Do you have your "blackhole" reporting server-busy or is it completely dead?
    – Mikey1980
    Sep 16, 2010 at 11:50
6

I've never heard of this method before and I can imagine it would delay legitimate email potentially by several hours. At the end of the day, the smtp protocols need to deliver your legitimate email. The valid servers will hit the bogus mx record and try to deliver to that server... I don't know what you might have running there (if anything), but they will keep trying until it's accepted.

Proper servers will keep trying the MX records until the mail is delivered. Spammers tend to get smarter and if this works for some spam software now, I doubt it'll work for long. I can't recommend it.

My suggestion is instead to look at using an smtp tarpit in addition to your existing spam filter. There are a number of these available now. I think you'll find it's much more effective than the fake mx record method.

Such tarpits come with smtpd on BSD. There are also some tarpitting features in sendmail 8.13.

Basically, a tarpit works by tying up spam server resources. They do that by delaying the responses they get. e.g. the spam server connects and receives about 1 byte per second.
Some of the tarpit servers look for spam patterns and can recognize a spam server. Legitimate servers will be prepared to wait through a slow response. In some tarpits servers they move the legitimately recognized server onto a whitelist automatically so there is no delay in the future.

Google SMTP Tarpit and take a look.

2
  • Thanks for the suggestion, but my client is a Web Design firm (their client is the one with the issue) running 100s of low traffic sites on shared host and the WHM has no root access or SSH.. stuck with SpamAssassin.. btw Exim is the exchange. Forgive me if this isn't clear.. my fortay is programming..I'd probably make a horrible sysadmin!
    – Mikey1980
    Sep 16, 2010 at 3:01
  • I'm a programmer as well, but have spent quite a number of hours running my old company's freebsd servers doing all manner of things.
    – hookenz
    Sep 17, 2010 at 0:34
5

You didn't mention it, so is there a reason you're not using a DNSBL?

Edit: SpamAssassin includes support for a few of them - without them, you'll be wasting a lot of CPU cycles analyzing spam.

5
  • Another great suggestion, however I am really limited since my clients WHM isn't root.. according to webalizer, enabling SpamAssassin has made next to no impact on bandwidth in the last 12 hours
    – Mikey1980
    Sep 16, 2010 at 3:07
  • 1
    ... then your best bet would be to push all mail services through Google Apps or use another third-party service to mitigate spam if your client's hosting provider is not willing to tinker with SpamAssassin's configuration.
    – danlefree
    Sep 16, 2010 at 3:23
  • Any idea if DNSBL or RBL are enabled by deafult? You'd think they would be. I agree, I'm starting to think a front-end MX filtering is going to be the only solution.
    – Mikey1980
    Sep 16, 2010 at 3:30
  • @Mikey1980 - "Any idea if DNSBL or RBL are enabled by deafult?" Sorry, couldn't say - best to inquire directly with the provider in any case because there is a possibility they apply their own configuration.
    – danlefree
    Sep 16, 2010 at 3:41
  • You can check if the emailserver filters spam based on the DNSBL: spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage#205
    – ZippyV
    Sep 16, 2010 at 12:53
4

I use this this fake MX (a variante of the nolisting) and it works very well.

I used a postfix MX with all the usual filters and after some spambot manage to overload the server for 2 or 3 times i decided to give it a try...here is the result: fake-mx, before and after

try to guess when i have implemented the fake-mx! 8)

The result is the same as postgrey, but unlike postgrey, you don't need to change your mail server

The spambots now will either try the high MX or the low MX, freeing the real MX from the load of trying to filtering then (even with DNSBL, the load was high) and real email arrives with minimal delay.

But be warned, there are risks:

  • Some servers might have high retry times. Most servers will retry the next MX after the first one timeouts, others will try in the few minutes next, but i already saw servers that only retry after one hour or one day. They are very rare and for the ones i could catch it was a bad config. talking with the other postmaster fixes the problem

  • All emails will have a delay. Actually i see no delay at all, almost all real mailservers will retry to the next MX after the the first timeout, so we are talking about 30s delay. They usually try at least 3 MX before queueing the message for a longer delay. but you might have contact with one broken mailserver that might not do this and delay every message for minutes. So this is a thing to monitor when deploying this solution.

  • Broken sites. Some webservers send email for passwords, notifications, etc and instead of delivering for a internal real mail server, they try to be a "fake" mail server and delivery directly. As its a webserver, they will never retry and the email is lost. Again its a bad configuration from the webmaster/web developers, as only real email servers should send email. every time i find this problems i talk with the webmaster about the problem and usually the problem is fixed.

  • No logs. As the fake MX poing to unconnected IPs, you have no logs of what tried to be delivered. you only know that something went wrong when someone complains. but this is also good. You can always claim that you have no attempt to deliver any email, so its a remote problem. The other side must check their logs and solve the problem. I can prove there is no connection at all to my real server, moving the pressure to resolve the problem to the other side. If the other side is unable to fix the problem it looked as untrusted, unreliable.

  • No whitelist. this applies to all servers via dns, so you can not whitelist one server... actually is just half-true, but is harder. the whitelist solution is that the lowest MX points to a IP where a smtp is running, but filtered by firewall for everyone. Those servers you want to whilelist needed to be permitted in the firewall. This way all servers will be rejected by the firewall and the whitelisted will be able to deliver to the mail server. It works, but only for IPs whitelist, not for email whitelist.

Unlike postgrey, where the remote sender have a log of a "rejected" delivery (and so can point at us as the problem), the fake-MX will show that the webserver could not even connect and didn't retry, giving no excuse for the remote side about the problem. A failing MX better accepted over postgrey, as we can always claim some "routing problem, but the backup MX is working fine, we get all other emails"

with that said, i get very little complains (about 1 every 3 months), so i consider it safe enough (every spam filter have risks).

Please note that i use valid ipv4 address for all the MX, but for the fake ones i use a IP that i control that is not in use (and so it gives timeout/host unreachable on any connection). this rules apply even if you don't use this. There are dns and smtp servers that require a perfectly valid dns config for the email to work. the fake-MX must also be valid, they should just not be reachable.

Do not use private IPs or IPs that you don't control for the fake MX (if you add ipv6 address, ALSO add a ipv4 one). This avoid problems with broken DNS and mailservers and surprises of other getting your email (by installing a smtp server on the IP you don't control). Also, CNAME are forbidden for MX, so don't use it also, just a plain A record

Finally, a tcp-reset should be sent for the fake MX, to improve performance (host or port unreachable) instead of a plain timeout (by dropping the packet), so it's recommended to add it to you firewall.

anyway, not only i still use it, as i recommend everyone to use it

2
  • This is nolisting, not just a variant. It does indeed work, but it's hard to measure since you're blackholing the fake servers' data (the graph above is merely anecdotal!). I recommend a high-priority server that is a real server (that you control!) with port 25 closed --but NOT dropped, you want a really fast failure-- and a low-priority server (in IP space you control!) that is either not up or else transparently drops that port's connections.
    – Adam Katz
    Jan 8, 2015 at 22:34
  • 1
    @AdamKatz Nolisting is just for highest priority MX, this variant also have the a fake server on the lowest priority... that is the difference! Also, if you read my last few paragraphs you will see that i say exactly what what you wrote! :)
    – higuita
    Jan 20, 2015 at 0:53
2

As far as mail filtering goes, I've been vary happy with combination of Spamassasin and policyd-weight, which checks sender hostname and blocklists during SMTP connection. That is a great thing for two reasons:

  1. you don't have to process the rejected e-mail with spamassasin, which spares you system resources (bayesian analysis takes some time) and bandwidth
  2. sender hosts get rejected, so in the unlikely event of blocking legitimate e-mail its sender gets a delivery failure notification

I'm using the setup on Postfix, but supposedly there is a way to install policyd-weight with Exim.

1

I didn't get completely the idea, honestly.

Ok, I'm saying my primary mailserver is Fake. Then so? Doesn't it exists at all or what? (Let's suppose it at last cut part of SPAMers either way.) The "survivors" would use secondary — no problem. But why there's 3rd server in this setup?


Since this supposed to be mine answer, not question, I'd conclude so: it's sick and a pale shadow of Greylisting. If you wanna see real effect try using Greylisting, man.

1
  • Extraordinary wording but you're quite correct. Greylisting IS the proper solution (other than a decent full-blown anti-spam filterings system). It will work as effectively as fake MX records, without all the drawbacks. Feb 1, 2011 at 21:18
1

I drop most of my spam by delaying connections to hosts are listed in the Spamhaus zen list. Spambots don't like delay. Detecting obvious server forgeries in the HELO command also clears out a lot of spam. Conditions I have found to indicate server forgeries include.

  • Using my hostname or IP address.
  • Using an unqualified hostname.
  • Using a domain literal ([192.0.2.15]) instead of a FQDN. (Yes the RFCs require it, but these days it is not used by Internet mail servers.)
  • Failing SPF for the HELO name not Mail (I block on fail, softfail, and neutral).

If you value automated or marketing mail, check on the HELO command that don't work include. My experience is that all other mail passes these conditions.

  • Using a second level domain name rather than a FQDN for the host.
  • Requiring the IP or HELO name to verify rDNS.
  • Requiring a valid second level domain for the FQDN. (local is not a valid domain nor is localdomain.)

Signing your return path allows you to block some spam. Although I am seeing far fewer faked bounces recently.

Unfortunately, I find a high percentage of legitimate automated or marketing mail forges their return path. These hosts often don't have a valid postmaster address either. I do find that requiring a valid domain in the return path is workable. I get far more SPF fail response on legitimate email than spam.

I recently posted my experiences with blocking spam with Exim

0

Besides the lost e-mails from legitimate people with broken gateways, it's been tried a long time ago (like 15 years ago +/-) and the spammers adapted to it almost immediately back then. I suspect it will prove to be a net loss to your e-mail reliability while having little if no impact on spam. However, should you try it, please send us the results!

0

Unfortunately, there are certain carriers out there that won't send you mail if the first MX record isn't reachable. I recently wrote up my experiences with this on a blog entry so I won't repeat it here. The summary though is that my first MX record was actually an IPv6-only MX record since I figured spammers don't use IPv6 (yet). Unfortunately, this caused problems and in the end I had to add a IPv4 address to the first MX record in my zone.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .