Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Please consider the following:

192-168-1-106:~ michael$ telnet <remote_server_ip> 25
Trying <remote_server_ip>...
Connected to li*****
Escape character is '^]'.
220 ESMTP Postfix (Ubuntu)
221 2.0.0 Bye
Connection closed by foreign host.

Is this very bad? how to protect port 25 from malicious attackers? I've already set up a firewall, but not very sure what to do in this case.

Basically I'd like to use this server to only send emails as alert messages, not receiving any external emails.

Many thanks to the help in advance.

share|improve this question
-1 Telnet is a text protocol. This was on purpose for the explicit reason that you can debug problems using something as simple as telnet. If your honestly worried about attackers using telnet then you shouldn't be running a server connected to the Internet at all. – Chris S Dec 25 '10 at 3:13
up vote 6 down vote accepted

If you are not expecting to receive email via SMTP, then you can either (a) block port 25 on your firewall, or (b) configure your MTA so that it is not listening for incoming connections on port 25. The latter choice is in many ways a better solution, but exactly how you accomplish that depends on your MTA. It looks like you're running Postfix, so this might help:

share|improve this answer

You could simply block port 25 inbound. This would work if you are only interested in sending alerts to email accounts on email servers you control.

If you are sending to email accounts on servers you don't control then your alert emails may get dropped as spam unless you setup your DNS mx/spf records appropriately and configure your server correctly. This may require you to open port 25 inbound. As an alternative you could still block port 25 inbound and use a properly configured email server as a relay for the emails from the application server.

share|improve this answer

Maybe I'm missing something here but these are my thoughts...

The short answer, is no this is not bad at all. If you aren't an open relay and the malicious person doesn't know the username and password to an email account, then is how an email server is supposed to work. Removing banners is often security theater, IMHO.

The longer answer, Setting up a firewall is the first step to securing your server. The next would be making sure it isn't an open relay, which means that spammer can't use your Mail Server to send mail out of your server without, an account on your server. You can check that out at MX Toolbox. Next you can setup fail2ban with your server. It will prevent/alert you to bruteforce attacks against your server.

Also you should think about setting up Mx Toolbox mointoring it's free and alerts you to problems with your email server.

share|improve this answer

This is not bad as long as the connection was not made from outside of the firewall. From the origination address you are on a private network and I assume the destination is on the same network too. If the firewall is setup correctly (i.e. it sits between the internet and the smtp server) you are fine, as it can make outgoing connections to its smtp forwarder without any incoming requests reaching it.

The firewall will allow (if it is a simple kind) all outbound connections, with replies assumed, but not allow any incoming connections on port 25.

share|improve this answer
You assume. Don't. I never do because assumptions are often wrong. Too often to rely on them. So, we know the prompt says "192-168-1-106", which seems to imply it's But even that is guessing. Facts? We don't have any about the actual network (yes, even "I've set up a firewall" is not really helpful) – Jürgen A. Erhard Dec 26 '10 at 1:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.