Protecting Your Small Domain from Spam Hijacking?

Black Cardinal asks: "I have a small domain which I mostly use to post family photos and some software. I also use it to manage a few e-mail addresses that my wife and I use. A spammer recently hijacked my domain name, using it to construct fake return addresses for sending spam (without actually cracking my host account), and caused a flood of undeliverable mail messages to be sent to my domain hosting service, which promptly suspended my account. At the moment it looks like I may never be able to have any @gelhaus.net e-mail again. What can I and my domain hosting service do now to protect their incoming mail servers and my account from this kind of attack, and how can I protect my small domain from this kind of hijacking and allow me to keep it running?"

"My domain hosting service, CubeSoft, has been a good host for my domain for the past three years, and they have been very helpful in re-enabling most of my account, but at the moment they don't want to re-enable my e-mail because of the flood of returned spam coming in (30,000 messages per day). Since the return addresses are all invalid (e.g. 'nonexistent_address@gelhaus.net'), I would think it would be simple to filter out all messages that aren't specific ones I've set up (e.g. 'valid_address@gelhaus.net'). I can't believe my domain is the first to have experienced this problem. It would be a tragedy to have to just shut down my domain because of this. CubeSoft says there isn't any way to prevent it because there is nothing that stops a spammer from using a fake return e-mail address. What have others with small domains done to protect themselves?"

Comments

Just wait it out

[Lord Grey]

Your problem may be due to the worms working their way around the Internet rather than due to a spammer intentionally using your domain. My email server recently suffered the same fate (though not quite that high of a volume) and I spent a bit of time tracking down the emails' origins through the bounces. In my case, they turned out to be coming from just a few unique systems and the volume slowly trickled to nothing after several days -- presumably because someone finally got around to patching their systems.

All the above is conjecture, of course. But it may be something for your ISP to think about. It may be possible to re-enable the MX for your domain in a short while without having to do anything.

Get a new domain host.

[aridhol]

Preferably one who knows how to read the headers in a bounce message. This includes the "Received" lines in the original message, which should show that none of them came from your domain. A little bit of due process before shutting you down wouldn't hurt, either.

BTW, this is generally known as a Joe Job.

One small thing that you can do

[martinde]

We have had the same issue, unfortunately. I asked on the debian-isp mailing list about it and the only real suggestion was to report the spammer in question to their ISP, which I believe to be in Russia.

The long and short of it is that we couldn't do much about it, other than try to minimize the resource waste. In our exim configuration we turned on "receiver_verify" in our exim configuration, which means before the incoming message enters the delivery phase, it's verified that there is a valid receiver. (Before doing this, the incoming message would run through spamassassin and then generate a bounce, using CPU time, memory, etc.) I know it's not much; I hope someone comes up with more suggestions.

Re:As long as email isn't replaced...

[anthony_dipierro]

But nobody seems interested in a modern-day email alternative.

Just about everyone is interested in a modern-day email alternative. The problem is getting everyone to agree on which particular one to use.

Re:Use SPF to protect against "Joe Jobs"

[oni]

I don't see anything in his account of the problem that indicates the spam was sent from his domain - only that his domain was listed as a return address. So, I don't think SPF would have helped him, even though it is good advice.

There's not much you really can do

[dacarr]

If you get Joe Jobbed, there isn't much you really can do about the problem except weather it out and set up an autoresponder for those bozos that send you flames (and thusly are what keep spam going, you insensitive clods!).

If you find that the jobber is indeed an American, though, if I recall correctly, you can sue for damages. Of course, you generally have to find the scumbag first.

Not much you can do at all

[BrynM]

CubeSoft says there isn't any way to prevent it because there is nothing that stops a spammer from using a fake return e-mail address.

Unfortunately, they are 100% correct. The spammer is just using your server as a destination for MX record lookups. When a spam is sent, most receiving e-mail servers will try to do a reverse lookup on the "from" or "recip" address via a DNS lookup or an MX lookup. This prevents the spammer from just blanketing a server with a completely made up "from" addresses (which used to be a popular tactic). The spammer now has to have a legit domain, so he used yours and just made up the account portion.

So, what happens when the receiving e-mail server tries to verify account name too? The spammer has to use someone's real account name (which has happened to me more than once). Since the spammer is using his own mail server to send the messages, your account and domain names don't only get checked ageanst your mail server when the recipient server tries to verify that they exist and not when the spam is originally sent. Thus, it's almost impossible to prevent.

Your only hope is finding the spammer somehow and making them miserable in some way (getting their ISP to cut them off, legal action), but that usually leads to the spammers friends making an exaple out of you (yet more unfortunate personal experience). I would just wait it out. Your ISP is doing the only thing they can by disabling your domain's e-mail. Soon, the "from" lookups will start failing for the spammer and he/she'll have to pick someone else to impersonate. I hope that your ISP will let you re-enable your domain's e-mail when it blows over. Good luck!

Publish 'spf' records for your domain(s)

[rthille]

http://spf.pobox.com/

Sure, not many MTA/MUAs check SPF records yet, but the fact that you are working to keep people from 'joe-jobbing' you should make your isp happy.

Host your own domain

[Tor]

I am nearly in the same situation like you, except that I have complete control of my domain name (slett.net). I run my own DNS, my own SMTP server (Exim with SpamAssassin at SMTP Time), etc.. A nice side benefit is the ability to teergrube spammer hosts.

If you are technically inclined, and you have a broadband connection, this is definitely the best way at present to take control of spam.

Incidentally, I believe the ultimate solution to spam must involve banks and financial institutions - basically, an international mandate for these to not honor payment requests (e.g. credit card payments) to spammers. In the mean time, a mandatory upgrade or replacement to the SMTP protocol, to provide foolproof sender validation (by way of private/public keys or similar), will certainly go a long way towards solving the problem.

-tor

Just get rid of the email addresses

[toygeek]

I work for a hosting company, and yes we've had this problem, although not on such a massive scale. We found that by removing any catch-all type setup, and bouncing the email address, the end users are much happier. This of course doesn't change the loading on the server much. IF however you know which IP's the emails are being sent from, your ISP can block those IP's with iptables, or, even in their router.

You shouldn't be so SOL, in my opinion.

Re:Oh no, I use CubeSoft too!

[BrynM]

Can't you just get a different host, then go to your registrar and change your DNS?

Just make sure that you own your domain name and not your registrar. A while back, a few registrars were offering dirt cheap registration, but they retained the rights to the domain name (essentially renting it to you). These types of registrars are trying to make money by forcing you to pay for hosting and since they own the domain name, you can't take your ball and go home. I don't think CubeSoft tries to pull any of this crap, but always read the TOS of a domain name contract very carefully. Even reputable registrars will try to hide stuff in there.

Re:You're smart...

[Just Some Guy]

Exactly. I went through this about two months ago. I was getting about 2,000 bounce mails per hour until I added a bunch of lines to my Sendmail's "access" file, recompiled access.db, and restarted sendmail. Here's an example entry:

erin@honeypot.net "550 This account was spoofed by some jackass spammer. It doesn't exist and never has."

Add one for each falsified account. You will still get the incoming SMTP connections, but your server will reject the mail before the sending host transmits the whole thing. Advantage: you lose the bandwidth that it takes to build a TCP connection and send a single RCPT line, rather than losing the bandwidth and storage required to process and bounce a whole message.

My SMTP bandwidth graphs dropped about 85% after adding those filters. Do the same on your end (or have your ISP do it for you) and sit back while the storm blows over.

Oh, yeah: you may want to put a prominent notice on your website's main entry point stating that you are not the originator of the spams. The flood of mail to my "abuse@" address tapered off greatly once I explained things to visitors. I still get a few twits with an axe to grind but there's not much you can do about that.

Re:get your ISP to change your MX record

[Jeremiah Cornelius]

geez.

Set rules in yer MDA. Alias work for this. Legitimate addressies get delivered to the appropriate box. Yer last alias is *. This one has a mailbox /dev/null.

Any mail not intended for a named recipient /will/ use bandwidth - then go "poof"...

Re:An Idea - which does not work

[squisher]

Yep, would help the guy but _not_ his ISP. His ISP probably does not want to waste the bandwidth created by 30k messages and that is whey they disabled his email. Bouncing, forwarding to /dev/null etc do not help because he will already have accepted the email (and thus wasted the bandwidth).
So either you scan already while receiving the email (as several people mentioned before, scan the header for invalid sender ips and then discard the bounces immediately BEFORE the whole email is accepted) or just wait it out.

I feel sorry for everyone out there whose domain gets used that way... =( I hope it dies down soon as his ISP does not seem to want to try to filter.

~Squisher

Find a lawyer

[bluGill]

It is a long shot, but if you can track these people down, you have plenty of grounds for a lawsuit against them. Just prove they used your idenity without your permission. Even if they are in one of the few countries that won't help you out, there is a good chance that they have backers in a country, and you can sue the backers. Or if you can find who they are, and who the customers are, you can get the goverment to watch money transfers, and force all customers money inro your account (A very big maybe here). But you need a lawyer to 1) win the case for you, and 2) tell you how you can collect.

Good luck, but I urge you to do this. You should have plenty of grounds, and you might join the few guys who have actually shut down a spammer.

Re:Push the emails back toward the spammer

[Zocalo]

The beauty of setting the MX records to point at one of the spammer's servers is that it doesn't touch your bandwidth at all. The ISP generating the autoresponse resolves the MX records, gets the spammer's IP and tries to talk directly to that. Your server will stop seeing *any* email for the domain once DNS caches have expired, bounces or legitimate. Of course, if you want to continue accepting the bounces and forward them to the spammer via your MTA with the attendant resource costs, that's potentially more effective. For a start you can send the emails to the spammer's published contact addresses extracted from the spam bounces you are getting, essentially a mailbomb on thier mail box instead of yours.

Setting the MX record has no bearing on whether the email is legit or not though, MX records are purely concerned with delivery, not dispatch. True, someone doing some investigation might notice the IPs matching and jump to the wrong conclusion, so you might want to use something like this in DNS:

@ IN MX 10 send-bounces-back-to-spammer1
@ IN MX 20 send-bounces-back-to-spammer2

send-bounces-back-to-spammer1 IN A <spammer IP 1>
send-bounces-back-to-spammer2 IN A <spammer IP 2>

Which should make it a little clearer what's going on to anyone doing any digging.

Thanks for the replies

[Black Cardinal]

Thanks to everyone who's posted replies on my topic. I've worked with my hoster to change my default alias to route messages with an invalid address to oblivion. Until this happened I didn't even realize that I had a default alias set up, which shows how dangerous a little ignorance can be. We're now re-enabling my aliases one at a time and watching closely to make sure these valid addresses are not being overrun with this returned spam.

By the way, I should mention that my hosting service, CubeSoft, has been very good through all this. I've been in constant contact with them through e-mail (but not my domain e-mail, hah), and they have been very helpful in suggesting solutions and in trying to work with me rather than just blowing me off as not their problem. After this, I can strongly recommend them as a hosting provider.

Re:Thanks for the replies

[quantum bit]

My postfix setup goes even farther. Given your example:

220 mail.somewhere ESMTP Postfix
HELO localhost
250 mail.somewhere
MAIL FROM:test@somewhere
501 Bad address syntax

Hint: RFC821 states that address must have angle brackets like <test@somewhere>. Legit MTAs always put these in -- I've only seen bulk mailers and people telnetting omit them.

And to continue the example (with a very dumb mailer that ignores error codes):

RCPT TO:invalid@somewhere
503 Error: need MAIL command
DATA
503 Error: need RCPT command
From: FREE special OFFERS <sdfgo34@hotmail.com>
221 Error: I can break rules, too. Goodbye.
(Connection closed)

With a progressively longer pause before the error codes are returned, to help slow down mass mailings :-P

Disable catch-all

[Blackknight]

Your host should be able to disable the catch-all account for your domain, which will result in any message not sent to a specific account being bounced.

You should also be able to set up filters in your accounts control panel. If your host does not support this, you need a new host.