I am having an issue due to a "smart" sysadmin that made some choices while I was away for two months: Spam.
I manage probably close to 10,000 web/mail sites. He decided to allow all mail to everyone of those domains go to /dev/null if the user did not exist instead of bouncing it back. Which is OK in some cases but the problem with that is that it says recipient OK for unknown users which makes spammers believe they are hitting a valid address.
So, with all that said I am now seeing TONS of attempted spam coming into all of these sites and I can't figure out a fix on server a by server basis.
Right now they are back to getting a user unknown so bandwidth on the network has dropped a decent amount since the actual content is not being delivered, however since the mail is still making it to me I am losing a good amount of bandwidth on DNS lookups per message as well as my inital bounceback. Doesn't seem like it would take a lot but with the volume of sites we are talking about it is relatively significant.
I am using sendmail on CentOS 5. I have full root access to the machines and I am really comfortable with IPTables, tcpdump, kernel modifications, sendmail modifications as well as access list and such on my core routers.
The catch, the company has not purchased a global antispam service. Ideally if there was a way I could configure sendmail to not do a DNS lookup if mail is sent to an unknown user that would be a start.
Answer
I'm assuming that bandwidth is the problem you are facing and the solution you are looking for. Please correct me if there is a different problem.
Is this all in one homogenous internal network or is it a bunch of independent sites/data centres? I'm wondering if it's feasible to run your own caching DNS resolver to cut down on the bandwidth caused by DNS lookups. If not a central one for all mail servers, maybe local caching nameservers at all sites would be feasible.
Another plan would be to block any IP address at the firewall from hitting port 25 that has caused more than 90% unknown user response (minimum of 10 send attempts). You could likely use fail2ban for this purpose.
Can you cut down on the size of your bounce messages?
Other things you should do:
Start measuring. See if you can measure how much bandwidth is "wasted" due to spam and at which point in the SMTP conversation it is happening. How much are the DNS lookups contributing? How much is the HELO? How much is headers? How much is the bounce messages? How much does all of this bandwidth cost?
Get a spam filtering service. Once you know how much the bandwidth costs and how much of it should be reduced if you had no spam, you can justify the cost of a spam filtering service. If you have measured the bandwidth and you can't reduce it any more, you're going to be paying the money anyway. Change who you pay it to and put one more problem on the "fixed" pile.
Comments
Post a Comment