Securing SMTP mail servers

There’s no way we can live without e-mail these days. But anything that lets us communicate freely to anyone, anywhere, must leave us wide open for security problems. Here are a few areas to watch for when using SMTP in general, with guidelines on how to minimise the risks.

Too much information?
It’s never a good idea to offer too much information to potential intruders. SMTP banners typically provide the client with information on the version of code running, which just gives a helping hand to anyone trying to access your system illegally. Similarly the SMTP help command can provide this information, so disable it if you can.

Commands which offer information on your users include VRFY, which returns a positive or negative answer to the querier, depending on whether the e-mail address exists on your system, and also provides the full user name and login name. This can be used to test for valid user IDs; if the user has used a weak password, access isn’t too difficult from there.

Disabling the command helps prevent spoofing by not allowing someone outside your network to check if a user id is valid. If you select this option, when the SMTP server receives an SMTP VRFY request, it will return the message: 252 Cannot VRFY user, rather than an explicit yes or no to the user’s existence.

Be aware that some systems still make use of this facility to legally perform security checks on someone signing up for their services, however.

The EXPN command also provides more information that you might want to willingly give out - it can be used to expand on a mailing list alias to provide the individual e-mail addresses of everyone on that list.

Depending on the SMTP server you are using, you should be able to customize your configuration here: for example sendmail allows you to enable VRFY and EXPN only for users who have identified themselves, using the PrivacyOptions settings.

Validating incoming mail
If someone is trying to send you mail that will cause disruption, either targeting your users or using your server as a pass-through point, they may try to hide by not providing a source e-mail address. You should configure your mail server to check that the user's mail address is specified in the MAIL FROM or REPLY-TO line of any incoming mail messages; otherwise the message should be discarded. In some systems there is a separate way to handle null addresses (< >) in the MAIL FROM line by enabling or disabling a Refuse NULL < > Senders option.

You may also be able to check for large blocks of data which are sent outwith the actual data phase of SMTP. Sending more than 512 characters in anything but the SMTP DATA command will look like an attempt to hack in to your server and should be blocked.

The SMTP kill file lets you specify a mail address or a particular mail host that you do not want to accept mail from. You can edit this to restrict access from hosts or domains; however this doesn’t scale very well.

If you have e-mail aliases, you should also consider whether you want them accessible to outside users or not. For instance, you probably don’t want customers sending technical support queries on your products direct to an internal mailing list

Mail Relay
Mail relay allows e-mail received by your e-mail server to be passed onto the intended recipient even if that user is not registered on your server. While this is often a necessary feature to have, to provide for scalability and resilience, the problem occurs where malicious individuals send your server a message to relay on to potentially hundreds of other users. This will at best use up your server’s resources (especially if a large number of those addresses are out of date, and your server then gets hit with numerous message-sending-failed reports) and worse, get your server blacklisted since the spam e-mails may look as if they came directly from your mail server.

So don’t set your server to relay mail for just anyone. If you do need to have relay enabled, your best option is to allow it for authenticated users only. Authentication is done either via IP address or user id and password - your users will need to select the "user authorisation" option in their mail client. For instance in Outlook or Eudora, you must select "my server requires authentication”, although this wording will change slightly from client to client.

Be aware also that these capabilities vary from server to server. For example, in Exchange 5.0, you could enable or disable relay and that was pretty much it. It wasn’t until 5.5 that the options to add in authentication, or to allow relay only from pre-specified network address ranges were added.

This story, "Securing SMTP mail servers" was originally published by

Copyright © 2010 IDG Communications, Inc.

Shop Tech Products at Amazon