Mail bomb

[unco]

Has anyone else seen this?

A user has received thousands of messages - probably over 100k per day. All of them are from unique IP addresses and all of them contain "User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)" in the header. We had no recourse except to delete her mailbox, which she did not want to have happen, but the mail queue was so huge that nobody else's mail could be delivered.

We don't have spamassassin installed on this server. We use an external appliance for spam and virus filtering, but they didn't subscribe to the service until after the email bombing started. Therefore, spammers were still hitting the server because the DNS had not yet propagated.

There's no rescuing them, because she will be hosting elsewhere since we won't let her use that email address for now. I'm just curious about how anyone would have handled the email bomb situation. Our customer service person said that they transferred their domain to us a year or so ago when the same thing happened at their last ISP.

Thank goodness it doesn't happen often. I really can't think of another such incident in our nearly 13 years of doing this.

Beth

 

[Amin Taheri]

I would recomend putting up an incomming mail scanner appliance in front of all mail servers, perhaps even in a cluster if you get millions of messages - it really depends on your size. An enterprise can have a rack full of mail servers while a mom and pop will only have one.

 

[nvoth]

I've seen similar behavior and one way I was able to save our servers was to nuke the MX record in the customer's domain. Obviously that kills everything, but the inbound flow was so massive it was eating 100% of the servers resources.

Since then we have a Barracuda Spam Firewall cluster in front of all of our mail servers. They can really handle a lot and do active rate limiting. In fact, when we're under a huge attack like that, we limit the number of connections per 30 minute period WAY down and that usually kills it.

Without something in front of your mail servers, I'm not sure there's a good way to stop something like that.

-Nick Voth

 

[breun]

xinetd also lets you set limits like a maximum number of SMTP connections (unlimited by default!), a maximum number of connections per IP address, and a maximum load above which no new connections will be created. You can set these manually in /etc/xinetd.d/smtp_psa (and smtps_psa). See man xinetd.conf for the available options. I have already requested that Parallels make these settings tunable from the Plesk web interface: http://forum.swsoft.com/showthread.php?t=55053

At least this applies to CentOS/RHEL/Fedora. I believe Debian uses inetd and Plesk's setup might be different in that respect.