Digging to safety with stunnel
April 6, 2009,
Quite a long time ago the ISP we use (we are in an office building with a lot of small companies) decided to do their share of spam fighting by blocking all outgoing traffic on TCP port 25. Of course, this was done without actually telling anyone. All of a sudden we could not send mail anymore and it meant that we had to come up with something to reliably send mail. We already had a mail server somewhere in a datacenter.
The solution was simple and elegant: use stunnel to create a direct connection to our mail server and use that.
With stunnel you can easily create a secure connection between two places using SSL, without the burden of setting up a whole VPN. It is a client/server architecture, and it works perfectly for a protocol like SMTP, where a mail client initiates the connection to a mail server and not vice versa.
Setting up stunnel is quite trivial: generate public/private keys on both sides of the tunnel, exchange the public keys, start the tunnel on both sides and you're done (the stunnel documentation explains this in detail).
Some things we found out that are smart to do:
- If you run stunnel on port 25 on localhost some system maintenance scripts that send reports via email, such as logwatch, will also use the tunnel. Depending on your system setup you might have to change a few scripts to send mail to a different account.
- If you run it on port 25 on localhost, it is wise to restrict access to localhost, or you will open up your mail server to the whole LAN you are on, effectively turning your mail server into an open relay.
- Make a startup script so tunnels are started at boot time.