Can I safely block port 25 on my server?

October 26, 2007 12:55 AM

Can I block port 25 or not?

I'm working on the firewall of a public facing webserver at the moment, and want to block TCP port 25 (SMTP) to incoming traffic as I'm seeing many connections that I just don't want to accept. The server does not handle any incoming email so this would usually be a no-brainer, just block and forget about it.

However, the server is sending around 25000 emails to a distribution list, two or three times a week. I am sure that AOL, or some other big email providers will block emails coming from servers that do not have port 25 open.

I don't want to just block it to test this and have a load of failed emails to deal with.

Do you know if I need to leave port 25 open or not?

posted by ajbattrick to computers & internet (5 comments total)

You need to handle your bounces, or you'll be blacklisted. If you have proper MX records and proper debouncing on some other server, it's fine to block 25 on the sending machine. SOMETHING has to accept it, but nobody cares whether or not the sending machine is the one that does.

You can avoid the overhead of firewalling, if you're not already doing it, just by having your mail program listen only on the loopback. Inbound connection attempts will get an instant REFUSED; this takes almost no CPU time. If you're running a firewall, each and every packet has to be inspected by the firewall engine, which will reduce server performance somewhat.

If you're going to run a firewall anyway, then blocking inbound 25 is fine. You shouldn't even need an explicit block rule, just don't accept that traffic. You are using deny all by default, right? Trying to identify and block bad packets is a waste of time. Classify and allow only good ones, and drop everything else.

You may also want to do the 'listen' thing above, just in case the firewall gets shut off or that code is somehow compromised. Defense in depth. Firewalls are just one of many layers of netting you should have up to catch the bad guys.
posted by Malor at 1:48 AM on October 26, 2007

What Malor said. I'll state more firmly that you want to configure the firewall now if this is an internet facing server, even if you don't intend to use it. Why? Someday you may urgently need it in place and not understand how to do so or remember exactly what rules you need for this particular server.


However, the server is sending around 25000 emails to a distribution list, two or three times a week. I am sure that AOL, or some other big email providers will block emails coming from servers that do not have port 25 open.

Technically that's not the case, but you will occasionally have to play clean-up. The college where I work has inbound SMTP and outbound SMTP servers and I'm responsible for them. The outbound does not accept incoming SMTP connections and 99.99% of the time everything is ok. And we do run some mailing lists for internal and external entities.

I'm not convinced that the occasional problems we run into are caused by splitting inbound and outbound SMTP traffic. I think it's far more likely that it's relatively easy to get placed on 's blacklist.

For instance, if you send a lot of email to AOL they want you to get on their feedback loop and to also comform to their guidelines. Ok, so their demand don't seem so bad in itself, but it's really hard to do when you have untold numbers of entities within your organization sending bulk notifications (register for spring 2008 classes now!). If AOL notices you're sending too many messages to expired email addresses they can cut you off.

And once you've addressed the issues with AOL there are all the other ISPs out there. It sounds really complicated but usually it's not. In those rare instances where we run into an issue we go to that ISP and sort it out. Most of them refuse your emails until the problem is fixed, so that the messages remain in the mail queue. Some, like Comcast, reject the messages, bouncing them to the sender, never tell you why you landed on the block, and have no human contact. Ah, Comcast, why must thou be such a prick?
posted by dereisbaer at 3:52 AM on October 26, 2007

One more thing, the inbound and outbound SMTP split was entirely for practical reasons. The inbound SMTP was occasionally overwhelmed with spam filtering, so bringing up an outbound SMTP ensured timely delivery of our messages. I'm sure that most ISPs will not find that unusual. We have since switched to IronPort appliances for inbound SMTP which can easily handle our spam issue and could handle our outbound SMTP if we so desired.
posted by dereisbaer at 4:19 AM on October 26, 2007

Lots of organizations have separate inbound and outbound SMTP servers, so that in itself is not really a major issue.

What will get you blacklisted is not necessarily having inbound port 25 connections blocked on that server, but not having any inbound SMTP (because that would mean there's no way to contact you, and you look really spammy). So just make sure that the MX records for your domain point to some server that does inbound SMTP, and that you handle your bounces gracefully, and you provide opt-out and participate in everybody's little feedback schemes, etc. Basically, if you want to run a mailing list and not get blocked you're going to have to spend a lot of time admining it; that's just how things go these days.

But I'd nth Malor's suggestion about just refusing connections rather than, or in addition to, packetfiltering them. A web server shouldn't be listening on port 25 for anything.
posted by Kadin2048 at 6:06 AM on October 26, 2007

Thanks for your answers. I firewalled the port, as a packetfilter is already running

I've come across this now though:

http://www.locnar.net/drupal/?q=node/85
posted by ajbattrick at 5:55 AM on October 31, 2007