Locking Spammers Out Of Your Mailserver

It's amazing what you can do with SSL certificates. In an earlier posting I showed you how to secure your email access by using SSL certificates. To achieve this, we had fortified our mail server to always establish pure SSL secured connections for the retrieval of an users' email. We did that to stop network snooping folks to read email passwords in transit and to make sure that someone who got to know a user's password would even need another secret information (the user's SSL secret key) to get at the mailbox content.

Now we will use the certificates we needed to fortify our IMAP server to make the other half of the mail system, the SMTP server, secure too. The SMTP servers today are used to accept email messages that are bound for a certain destination for which the server is authorative. But to deny spammers the chance to indulge in their nefarious activities SMTP servers usually refuse to relay email messages to other servers under normal circumstances. There's nothing wrong with it as long as the machine that is used to send the email has a public IP address that was never used to send spam before.

But once you've tried to send email via a dial-up connection or a public wireless access point, chances are that your dial-up IP address is marked as a dubious source and you cannot send your email because you are blocked by some intelligent software that pretend to know your're a spammer. There is no point in arguing, your only chance is to send your email into the internet via a "clean" relay host, with a static IP address, that is able to make a difference between you and all the spammers that pretend to be you.

In essence, we have to find a way to authenticate ourselves to the clean SMTP server in a secure way. Obviously, all the system users that are listed in the mail server's user database should be allowed to use the server as a mail relay host. But then, they have to submit their passwords to the mail server to authenticate and, as you probably would have known by now, this should only be permitted through a secure link using SSL or TLS.

Switching On Authentication

Most people sending email don't think about having to prove their identities to a mail server, they expect to be able to send email the same way as they are used to stuff anything into a real letter box. From the perspective of the mail server, a correct username password pair is the only thing that differentiates a valid user from the spammers. That's why it is important to educate people, that giving a password is not too much of an annoyance for the benefit of sending email while on the move. Anyway, once we have set up the system to use SSL certificates with an outgoing mail server, users will not see much of a difference except that they have to provide their password when sending the email out.

Adding A Secure Tunnel To SMTP

As the mail server is our main secure entry point for email into the internet our main objective is not to hide our message but to convince the mail server that we are the good guys that are allowed to inject email into the system.

SASL, the Simple Authentication and Security Layer, is being used to enable our mail server software to perform the necessary authentication checks. But before we can enable the use of SASL inside postfix, we have to start a deamon, the saslauthd

chkconfig saslauthd on
/etc/init.d/saslauthd start

The following code is used to enable sasl in postfix and has to be added to the main postfix configuration file:

# SASL support for authentication
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

# TLS support for postfix
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/postfix/mailserver.key
smtpd_tls_cert_file = /etc/postfix/mailserver.cert
smtpd_tls_CAfile = /etc/postfix/CA.cert
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

The last few lines of code will tell postfix to use TLS (the replacement for the older SSL mechanism) and the location where to find the mail server certificate and key as well as the CA file to verify the trust chain.

With these modifications of the server side, we have essentially locked out everyone from using our mail server who is unable to provide the correct username and password over the TLS connection to our mail server.

Don't Forget Your Client!

The first thing we'll notice when we send our next email is that it won't go out as our email software used to ignore TLS so far for outgoing mail. To be able to send email out again you have to change your settings in the "SMTP" section of you email client software. After selecting TLS encryption and providing the username for the mail server you should be back on track again. In my case I had to upgrade my email software to ALPINE 2.0 to get busy, because my old software (pine) didn't know a thing about TLS. But that could only happen to me as I tend to stick to the old reliable programs when the rest of the world has already moved on to the cutting edge solutions.