Slashdot Mirror
Stopping Spammers Who Exploit Secondary MX?
drteknikal asks: "I'm the admin for a small law firm. We use our ISP as our secondary mx. We are receiving spam from our secondary mx even when our primary has been continually available. We suspect that spammers are routing to our secondary MX to bypass the DNS-based spam filtering on our primary. After examining some of the traffic, our ISP agrees. Neither of us sees an immediate solution, given the purpose and function of secondary MX. They already restrict relaying to hosts on their network. Has anyone else seen this? Does anyone have suggestions on how an ISP could secure their mail exchangers without interfering with the functionality required to function as secondary MX for an external domain?"
Is there any reason why the ISP can't set up some sort of SPAM filtering on their end?
Also, why not just set up the ISP's server as a backup server only? That way, you access your e-mail through the main server, which would make the mail go through your SPAM rules, right?
Karma: Chevy Kavalierma.
Does anyone have suggestions on how an ISP could secure their mail exchangers without interfering with the functionality required to function as secondary MX for an external domain?
There's a solution we invented down here in Texas involving guns, tars and feathers and truckloads of dynamite. However, physical proximity to the spammer is required, and your market may vary. PM me for details.
I'm not sure I understand the problem...why can't you set up restrictions like those on your primary MX on the secondary, and if you can, why do they work on one, but not the other?
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
I have seen a bunch of my spam at work come in from the secondary MX. Until this moment I'd assumed it was due to our primary MX being down, or due to the spammer's mail client picking the "closer" MX (our MXs are widely spaced geographically and in IP space).
However, the solution seems simple enough IF you control the secondary MX - install the same level of anti-spamming on the secondary MX as you have on the primary MX.
Of course, if you don't control the secondary MX.....
www.eFax.com are spammers
One solution would be to let the backup forward the mails normally to the primary MX, but our ISP can't do this; once the mail is in the POP account, it's gone from the mail queue...
Karma: none (due to not believing in reincarnation)
I noticed the same thing. While both of the main servers had the same level of spam filtering, I found it odd that the secondary was seeing a lot more spam. So as an experiment I added a thrid MX, the first two are of priority 0 and 10. The third I made 100 (not that it really matters). On this third server I set up even stricter anti-spam rules. The amount of spam fell of very quickly after that. The spammers would go for the trap. I would say that over 90% of the e-mail to that server is spam. I have almost considered just making it a black hole. But it does see a little valid traffic, and there is a chance that both of our main servers could be offline at the same time.
I do miss Texas. Heinlein was right: "An armed society is a polite society."
Never encountered a pushy type in a line, and people in the "N-items or less" lines always had N items or less.
If I murder someone in Texas, I fry. If I murder someone in Canada, I'd likely get 25 years, parole after 7, and the murdered person's family pays the taxes to support my room and board while I'm locked up. Almost beats working for a living. Of course, not liking the intimate company of people named "Bubba" kinda puts a damper on the "murder in exchange for free room and board idea" (While inmates in U.S. prisons are supposed to not suffer cruel and unusual punishment, such punishment is actually advertised as a deterrent in the province of Ontario, as a means of combatting drunk driving: "Drive drunk, go to jail, get sodomized.")
Uh, huh! We feed, clothe, and house our criminals here! And, if you're "Bubba's" type, you got it made! Just go and murder someone!!
You could've hired me.
Unfortunately, unless your ISP is willing to implement the same DNS based filtering, you are out of luck.
I guess you could set a filter to process the IP prior to the secondary MX and filter that. I don't know of any ready made solution for this tho, and it requires that your server receives the message and examines the headers.
No sig
Anmother trick that I'm starting to see pop up is control characters in the headers, so spamd/spamc get a screwed up byte count and allow the message through. I'm not running the latest version of SpamAssassin yet, though, so this may have been fixed already...
The core of your problem is the fact that your ISP is accepting SMTP traffic for you and does not support the same policies as your own mail server supports. If you want to get rid of the SPAM coming from your ISP, you need to be able to implement policies on the secondary MX server.
I would suggest one of the following:
- Collocation: Put one of your own servers at your ISP to which you have full control over
- In-house: Don't use your ISP as a secondary MX, set up a second server at your site instead (this still protects against primary server failure, but not against ISP connectivity problems)
- Paranoid: Implement the filters on mail coming in from the ISP. Depending on your filtering software, this might be a little more tricky but it will work.
With regard to the Paranoid option above, it should just be a matter of checking ALL of the Received headers instead of just the last one. Usually spammers can (and do) forge all of the Received headers except for the last one -- which they can't because your server adds it. In the case of mail received by your ISP, the last two Received headers are guaranteed to be valid.Checking all of the Received headers against the SPAM database would do the trick.
eg:
mail.myserver.net pri 10
mailbackup.myisp.com pri 20
mail.myserver.net pri 30
Works perfect for now. But some day the spammers will adopt to this too ....
RFC1925
I had that problem and fixed it by adding sendmail rules to check the host that sent the mail to my MX.
Check here for the script and my general spam article is here.
Your secondary MX should pick up anything that overloads yours so you should not dump any real traffic.
This was discussed a few months ago on slug.org.au on the mailing list. Take a look at the archives google with site:slug.org.au
what
Without their seatbelts on!!
There are quite a few options in order of preference:
I'm sure I missed some in the middle there...
As an aside -- you mention:
They already restrict relaying to hosts on their network.
This would defeat the point of their running a backup MX for you -- I'm sure that your secondary is relaying any envelopes addressed to your domain.
They mostly seem to be going for the lowest MX on the list, so simply:
The critical thing is that you need to be certain that this tertiary MX is only up when your primary MX is also up. No legitimate mail software will use an MX with a priority of 100 when it can connect to an MX with a priority of 1, so you can be certain that anything the 3rd MX gets is spam. If they're on different boxes, however, a simultaneous outage of the first 2 could cause you to accept then dump legitimate messages.
.sig: file not found
I suspect that some spammers have figured out that most complaints go to the first "Received" header (if not to the forged "From" headers), and most secondary MX's will forward the mail to the primary MX's, adding a "Received" header. So some complaints will go to the secondary MX instead of the open relay or the fool that actually sends the spam... So those will take a bit longer to get shut down.
I could add a procmail rule to pipe all those mails into a suspicious folder, but that would not help the rest of the company.
In Murphy We Turst
hmm no google hits
Apart from load balancing, a single MX is often enough - if it's unreachable, emails will stay queued on the sender's systems and get delivered later.
Put in two more servers (how important is this? otoh, two smtp servers can be, by today's standards "low-end" systems and perform just fine) and have the mail make one more stop on the way at these, and put the anti-spam machinery there. So the flow of mail would look like this:
MX1 --\/--A.S.1--\/--internal mail/pop/imap
MX2 --/\--A.S.2--/\--servers
so no matter what the spammer does, everything is still scanned, leaving you not to worry about CoLo'd servers, or what ISP(s) you use as MX'ers. You could, of course, do this with one A.S. server, but you've got all those backup MX'ers, so it'd be a shame to introduce a single point of failure now.
illigitimi non carborundum
Power corrupts. PowerPoint corrupts absolutely. E. Tufte
Obviously you need multi-phasic secondary MXs on a rotating modulation...
If that doesn't work, a penis shaped inverse tachyon pulse up their own MX will fix their little red wagon, quicksmart.
Opportunity knocks. Karma hunts you down.
...it would be worth experimenting to see if the attacking software is bright enough to notice the similar IPs, or if you need a second IP. If you need a second IP, you could pick a non-mail machine and port-forward 25 from it to your primary.
I'm guessing some spammers would focus on the second IP, some on the last, and some would choose at random, so it might be effective to set up four MXes, the second and fourth being echoes of the primary, and the third being the "real" MX.
If your primary's spam filters know what the connecting address was, they could block all traffic from it for an hour, and tell others (the ISP, for starters) about it so they could do the same. That way a spammer hitting the primary MX, getting rebuffed, then falling back to the secondary would be SOL.
Got time? Spend some of it coding or testing
Instead of blocking mail from an IP address, you should accept and discard the mail. If you don't even open a socket, or if you reject with one of many generic messages, most any mail package will continue with the secondary.
Most of the popular spmware (SendSafe, SuperMailer, etc) packages just choose an MX randomly. Or to be exact, the FIRST MX returned by your DNS server.
Remember, DNS servers return multiple records for the same record in a random order, regardless of prefrence or anything else.
Hence you need to hack your DNS servers to return your spam-filtered primary at the top of the list.
symetrix. We are building a religion, a limited edition.
Secondary MX shouldn't deliver to a non-filtered internal email system., but should wait for the primary to come back up.
That way any filtering on the primary is also used if spammers use the secondary to deliver, mail continues to be delivered as normal, with no other changes.
Works for us..
I was doing something like this for customers:
system:
virus/spam scanners --> mail system
dns:
MX 30 backupmx.domain.com
MX 20 virus/spam scanners
MX 10 mail system
and we were getting tons of undeliverable mail for our customer's domains at the 20 and 30 MX entries.
There was no reason to even bother with the backup solution since the virus/spam scanners would just queue it up anyways, so we now set it up like this:
system:
virus/spam scanners --> mail system
dns:
MX 10 virus/spam scanners
and then have the virus/spam scanners process every piece of e-mail and queue it if it cannot deliver to the mail system. We use qmail and smtproutes to move the mail to their server. If their server is down, it just stays queued up.
Why read the article when I can just make up a snap judgement?
We offer secondary MX mail relay service to our customers, intended as a low-cost backup service. Spam filtering is available, mainly intended for people who use us as their primary email service, and most of the secondary customers have their own spam filters that they like to tune for themselves, so they haven't been using ours. There are some things it can't do directly, like detect whether an email username really exists, especially if the customer has an old Exchange server protected behind a spam filter appliance or application-relay-type firewall.
Unfortunately, Dictionary Spam Attacks are really annoying in this model. If the spammer is contacting your mail server directly, and aardvark@example.com, aaron@example.com, etc. don't exist, your mail server will bounce the RCPT TO: and not accept the message, so there's minimal data transfer for the million or billion messages they try to send, maybe 50-100 characters of request and rejection message. However, if the secondary MX server doesn't _know_ that, it'll accept them _all_, complete with each 10KB of blather about how to Make Vi@gra F@$$T!!, and try forward it all to example.com's real mail server.
What's supposed to happen next is that example.com's primary server sees each RCPT TO: and rejects it, leaving us to queue up a bouncegram to YetAnotherForgedFromLine@yahoo.com, so example.com only gets flooded with requests but rejects them at the envelope stage, so their T1 line doesn't get stomped with the message bodies.
Unfortunately, Example.com's spam-filtering appliance also didn't have access to valid-vs-invalid user names, so it had to accept each message, and it couldn't handle the load, because the spammer's zombie farm and our big mail relay system were both a lot bigger than it was, so it collapsed and died. They were able to get it to stay up by rejecting all messages from our mail server, but far more unfortunately, some of Example.com's customers get outgoing mail relay service from us, so that wasn't a stable solution either. So we're turning on spam filtering for them, and if that doesn't keep the load manageable, they'll probably build their own secondary server or something.
- A machine that doesn't do SMTP on Port 25, so the connections get rejected.
- Verisign's SiteFinder Email Handler which rejects messages for anybody? (Might as well get _some_ use out of them
:-) Their first version would have worked better than the second one - it only rejected individual addresses at the RCPT TO: stage but didn't reject the whole session up front because some popular mailers reject brokenly to that (now it does both; not sure whether the spamware does or not.) - Your own reject-mailer, which can reject the connection with something more appropriate, like 452 "insufficient system storage - try again later", which has the advantage that if somehow a real user connects to it, their stuff should stay queued until your main mailer is working again. That's also a good place to run a VRFY that will happily claim that any address the spammer wants to test is a correct adddress (or if you're not worried about real mailers using VRFY, only spammers, you can have VRFY respond positively only for user names that don't exist, and negatively for user names that do exist.)
Of course, you can always teergrube the tertiary mailer, letting the sender get bogged down in something that _looks_ like it's accepting their messages, but doing so v....e....r....y.....s....l...ooooo.....wwww....lBill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks