Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Spam Technology

Stopping Spammers Who Exploit Secondary MX? 50

Posted by Cliff from the closing-the-holes dept.
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?"
This discussion has been archived. No new comments can be posted.

Stopping Spammers Who Exploit Secondary MX? More

Stopping Spammers Who Exploit Secondary MX?

Comments Filter:

  • Spam filtering on their end...? (Score:4, Interesting)

    by greenhide ( 597777 ) <`moc.ylkeewellivc' `ta' `todhsalsnadroj'> on Tuesday October 07, 2003 @05:49PM (#7157345)
    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?
    • Doesn't quite work that way. In terms of inbound SMTP, a secondary MX with a lower priority (higher numeric value) is already, techincally, a backup. However, it is a backup *route* that will accept mail at anytime, so if someone simply decides to ignore the primary-- or falls back to the backup because the primary said no-- well, you have the problem described.

      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)

    by Anonymous Coward
    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.
    • Sniff, snif :-(.

      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

    • There's a solution we invented down here in Texas involving guns, tars and feathers and truckloads of dynamite.
      Don't forget rope. You can't hang someone or draw and quarter them without rope. Rope is the vigilante's duct tape. It's good for everything. Especially spammers...
  • 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?
    • Presumably the ISP is servicing multiple customers and doesn't want to set up a configuration that would impact everyone else.
      • Presumably the ISP is servicing multiple customers and doesn't want to set up a configuration that would impact everyone else.

        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)

    by wowbagger ( 69688 ) on Tuesday October 07, 2003 @05:51PM (#7157366) Homepage Journal
    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.....

  • Same thing here (Score:3, Interesting)

    by beat.bolli ( 126492 ) <me+slash@drbe[ ]li ['at.' in gap]> on Tuesday October 07, 2003 @05:51PM (#7157367) Homepage
    I observe the same thing here. 90%+ of the mails that reach us through the backup MX are spam. Our problem is that we have to get this mail with a POP account, thus bypassing the normal spam check.

    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...

    • Wow, that's broken. So you have to check one account's mail on two different machines?

      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.
      • No, the mail from the POP account (just one for the whole mail domain) is parsed and redispatched to the appropriate mailbox(es) on our internal server. It's just a leftover from the days when we had to get *all* mail from this one POP account (we're a small shop, 13 ppl). The Python script that does this is available if you have similar problems.
    • Yea, in the last couple weeks I've been seeing this on our mail server as well. We use a commercial "store and forward" service, and a measureable amount (I'd say 10% or 15%) of our spam is coming through that. Fortunetly our email server has spam filtering built in, it doesn't matter what MX it comes through. Filter on sender address/domain, plus the standard rules based filtering.

  • How about a third MX? (Score:5, Interesting)

    by Neon Spiral Injector ( 21234 ) * on Tuesday October 07, 2003 @06:01PM (#7157472)
    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.
    • 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.

      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.
      • ...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 filte
    • Targetting lower priority MX's makes a lot of sense from the point of view of a spammer. A huge number of SMEs out there with their own mailserver are using an ISP's servers as their backup(s) and these are probably not going to have as high a level of anti-spam filtering. The additional MX approach sounds like a good backstop though.

      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

    • OK, ok, so spammers and spam blockers are in an arms race, and this will probably only work for 15 minutes if it gets deployed widely because spammers will change their spamware, but what happens if you give the spammer a broken third MX site? Some obvious ones are:
      • 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
  • 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.

  • Another new spam trick... (Score:4, Informative)

    by dmayle ( 200765 ) on Tuesday October 07, 2003 @06:04PM (#7157510) Homepage Journal
    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 way I see it... (Score:4, Informative)

    by wonkamaster ( 599507 ) on Tuesday October 07, 2003 @06:05PM (#7157513)
    The spammers seem to be exploiting a flaw in your methodology. I'm not sure there is a good way around the problem -- at least how you're doing things now.

    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.

  • Simple fix (Score:5, Interesting)

    by geirt ( 55254 ) on Tuesday October 07, 2003 @06:13PM (#7157585)
    Add your main server to DNS as the MX with both the highest and lowest priority.

    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 ....

    • Obviously you need multi-phasic secondary MXs on a rotating modulation...

      If that doesn't work, a penis shaped [mit.edu] inverse tachyon pulse up their own MX will fix their little red wagon, quicksmart.
    • How does this prevent the spammer from sending mail to the mailbackup server ?
    • This worked for me for about a week. I then peppered the primary with all sorts of different names all over the MX record list. That also failed to work. In the end I just gave up and deleted all MX records except the primary. Other servers will retry if they can't find mine. The amount of mail actually lost in the case of downtime is pretty much irrelevent compared to the amount of spam i now don't get. (it runs linux so uptimes are normally measured by numbers with 3 digits.)
  • I had that problem and fixed it by adding sendmail rules to check the host that sent the mail to my MX.

    Check here [pha.pa.us] for the script and my general spam article is here. [pha.pa.us]
  • They appear to use the last MX record, so create a third one and just delete anything coming into it.

    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

  • Direct to MX spamming should surprise you about as much as drunk drivers driving without their seatbelts on.

    Without their seatbelts on!!

    There are quite a few options in order of preference:
    • Augment your dns filtering with spam assassin and bayesian filtering in house.
    • root your secondary -- colo a spare machine and implement your current filtering there as well.
    • Educate your users to safeguard their e-mail address and install client side filtering
    • Give up the advantages of a secondary MX and do without

  • Use a local 3rd MX that feeds spamd (Score:3, Interesting)

    by petard ( 117521 ) on Tuesday October 07, 2003 @06:35PM (#7157779) Homepage

    They mostly seem to be going for the lowest MX on the list, so simply:

    1. Obtain an additional IP address for your primary MX box.
    2. Configure that as your tertiary MX, with, say, a priority of 100
    3. Configure the MTA on that box to feed your Bayesian filter with all the spam you'll get, then delete it without transferring to your inbox :-)

    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.

  • I am providing a secondary MX for our company, from my home machine. Not much of real traffic comes in that way, but a lot of spam does.

    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

  • In the past, a secondary MX should ensure email reception after a failure of the primary MX. Nowadays it's quite useless if the Internet connection between the secondary MX and the human recipient is interrupted - it's even contraproductive as a sender might have seen his email being delivered, with the recipient not knowing anything about it.

    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.

    • Yes, one is enough for a small site that doesn't care much about not losing any incoming email. But for a more serious site, it's necessary to have a backup. Here's why:

      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'

      • "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?"

        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
  • The suggestions thus far are all good, and here's another...

    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

  • If you're merely blocking these IPs, then of course they're using your secondary -- that's what the secondary is for, it's for when the first can't be reached.

    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.

  • 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..
    • Secondary MX shouldn't deliver to a non-filtered internal email system., but should wait for the primary to come back up

      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
      • yes blacklisting gets broke, given the current problem with RBL's....

        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.
  • 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

Slashdot Top Deals

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Close