Stopping Spammers Who Exploit Secondary MX? 50
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?"
Spam filtering on their end...? (Score:4, Interesting)
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?
Re:Spam filtering on their end...? (Score:1)
If you wish to leave the boundaries of the SMTP protocol there are probably all kinds of things you can think up, but if you aren't willing to im
well (Score:2, Funny)
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.
Re:well [OT] (Score:1)
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 "B
Re:well (Score:2)
Re:well (Score:1)
Well... (Score:1)
Re:Well... (Score:2)
Re:Well... (Score:2)
They should be able to implement it selectively, based on the recipient address/domain.
It's really not hard to do - all modern MTAs support this type of operation.
I, too, have seen this (Score:4, Informative)
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.....
Same thing here (Score:3, Interesting)
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...
Re:Same thing here (Score:2)
The whole purpose of a back-up MX is to collect mail while the primary is down. But just to hold it in queue. When the primary comes back on-line, it then delivers the mail there.
So the back-up(s) should be configured to accept mail for the domain name, but not for local delivery. This is a basic function of all SMTP servers.
Re:Same thing here (Score:1)
Re:Same thing here (Score:1)
How about a third MX? (Score:5, Interesting)
Re:How about a third MX? (Score:2)
Sounds like that could be the answer. Just make a local 3rd mail exchanger with spam controls and maybe the traffic will be diverted off the second one.
Even simpler... point 3rd MX at 1st (Score:2)
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 filte
Re:How about a third MX? (Score:2)
I'll have to check my SpamAssassin rule set, but I think a small positive score if a backup MX was used as a relay might be in order. What would be really slick would be t
Do Broken Third MXs work? or Teergrubes (Score:2)
Secondary MX filtering (Score:2)
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.
Another new spam trick... (Score:4, Informative)
The way I see it... (Score:4, Informative)
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:
Checking all of the Received headers against the SPAM database would do the trick.
Simple fix (Score:5, Interesting)
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 ....
they will adapt. unless..... (Score:1)
If that doesn't work, a penis shaped [mit.edu] inverse tachyon pulse up their own MX will fix their little red wagon, quicksmart.
Re:Simple fix (Score:1)
Re:Simple fix (Score:2)
Check the headers coming from your MX (Score:2, Informative)
Check here [pha.pa.us] for the script and my general spam article is here. [pha.pa.us]
create another MX (Score:1)
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
a few options (Score:1)
Without their seatbelts on!!
There are quite a few options in order of preference:
Use a local 3rd MX that feeds spamd (Score:3, Interesting)
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.
Me too (Score:2)
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
Secondary MX are often unneccessary. (Score:2)
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.
Re:Secondary MX are often unneccessary. (Score:3, Insightful)
Let's say you have some scheduled downtime of your main server. Let's imagine that the downtime lasts more than four hours. Do you want all the senders to get delay notifications?
What if the downtime is worse, due to a total disk failure, for example. It could easily take more than a day to get back online. Many sender systems won'
Re:Secondary MX are often unneccessary. (Score:2)
Actually yes, if the recipients can't get their mail whilst the main server is down.
Nowadays much email gets stale very fast. See the Ask Slashdot story about smtp timeouts.
The only time I can see backup MXs (or DNS servers for that matter) being useful are if you have multiple connections to the internet or you use crappy ser
two more servers (Score:1)
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 abou
How are you filtering? (Score:1)
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.
They don't prefer secondaries... (Score:1)
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.
secondary MX forwards to primary MX (Score:2)
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..
Re:secondary MX forwards to primary MX (Score:2)
it does
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.
there is a change, the sending host is now one that you can't blacklist. if the mail gets sent to the primary directly then it can look up the IP of the sending server in a dns blacklist.
dave
Re:secondary MX forwards to primary MX (Score:2)
Also RBL's should NOT be the only mechanism for spam blocking anyhow, you need a complete set of things: including whitelists, blacklists (homegrown or provided), baysian, simple text, virus filters.......an of course a policy to police the whole thing.
What I did (Score:2)
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