This page is part of the EmailServer article.
This article describes the necessary steps to set up
stunnel to provide alternate secured ports for postfix and dovecot (SMTP and IMAP/POP).
This technique is useful but it is not necessary since you can achieve the same result just by modifying your firewall settings to redirect traffic from any port to the secured SMTPS, IMAPS/POPS ports already provided out of the box by postfix and dovecot.
You can directly proceed to the AlternateAccess article if you don't need to use
Secure, encrypted email channels
With the proliferation of wireless hotpots, people have been able to enjoy a new freedom in accessing the web and their emails: airport lounges, coffee shops, public spaces.
While all this freedom is wonderful, public access points (and most private ones) usually don't use any form of encryption to protect your transfers.
This is especially an issue on publicly accessible networks where absolutely anyone can eavesdrop on your communication without you being the wiser.
In some countries (including the US it seems), internet communications are routinely filtered, taped or analysed for whatever purpose is deemed just, too often without any accountability.
One of the reasons that email can be the weak link in your organisation security is that most of the time authentication connections by your email client are still sent in clear text, meaning that every time you get email, you advertise your username and password.
A lot of organisations only use a single username/password for each of their users and their access needs, meaning that the same pair is not only used for authorizing access to email accounts, but also to login into your PC, domain or Intranet...
Stunnel to the rescue!
There are many ways to secure your email connections through SSL: most servers have their own configuration details allowing them to work through an encrypted channel.
Here though, will will use
Stunnel to provide secured channels to
postfix@2 and dovecot@@ rather than configuring each of them individually.
Stunnel is also easy to use and can allow you to create ad-hoc secure tunnels for any arbitrary network service as well.
Stunnel isn't on your machine yet (
whereis stunnel), just grab it from your
rpm repository (
yum install stunnel) or get the source code from stunnel.org.
To install from
yum as usual:
To install the source code:
# cd /usr/local/src
# wget http://www.stunnel.org/download/stunnel/src/stunnel-X.XX.tar.gz
# tar xzvf stunnel-X.XX.tar.gz
# cd stunnel-X.XX
# make install
Note that if you are installing on a RedHat machine, you may need to modify the files
tools/Makefile.in to replace any occurrence of
Note as well that the default installation directory is
/usr/local/bin. If you don't want this, use the
--prefix option of
configure (call it with --help to get more details about the available options).
Creating the private key and certificate
Creating a Self-Signed Certificate is only half of the story: since they are not issued by a recognised authority your mail clients will popup an information message to the user. The only way to solve this is to register your server with a recognized authority such as Verisign.
This isn't necessary, but larger organisations may want to look into the details of providing this extra-security to their users as it ensures that your server is really who it claims to be.
To be able to encrypt the communication,
Stunnel needs to have access to a secure and unique private key and a certificate that it can issue to the clients connecting to it.
the certificate will contain information about your organisation and a public key that will be used by to encrypt data that can only be decrypted by the server running stunnel.
This step is important: don't use any default key that comes with your system: the communication channels would still be encrypted, but since these keys are publicly available, your communications could be decrypted without too much hassle.
To create the necessary keys just do the following:
# cd /etc/stunnel
# openssl req -newkey rsa:1024 -keyout privkey.pem -nodes \
-x509 -days 365 -out cert.pem
You will be asked a number of questions regarding your organisation. These will be included in the certificate issued by
Stunnel when contacted by clients.
Also make sure you use the FQDN (Fully Qualitified Domain Name) of your email server when asked about your server name (for instance, mail.example.com).
Note that the certificate will only be available for the number of days specified when creating it. You can make your certificate valid for as little or as long as you wish.
Stunnel requires that both certificate be in a single file with extra blank lines after each certificate.
Like most encryption-related configurations, it also requires that the certificate have limited access.
After creating the proper key, we don;t need the original ones any longer.
# cat privkey.pem > stunnel.pem
# echo "" >> stunnel.pem
# cat cert.pem >> stunnel.pem
# echo "" >> stunnel.pem
# chmod 600 *
# rm privkey.pem cert.pem
Stunnel is ready to be configured:
/etc/stunnel/stunnel.conf with the following entries:
cert = /etc/stunnel/stunnel.pem
accept = 993
connect = 143
accept = 995
connect = 110
accept = 465
connect = 25
What this does is simply tell
stunnel to listen to ports 993, 995 and 465 and spit out the decrypted stream of data to ports 143, 110 and 25.
cert line should not be necessary unless you compiled
stunnel from source and it is expecting a different path (check what it could be by running
Now we can try to launch
stunnel manually to check that it works:
That's all that should be needed. If you are getting error messages, then try to add the path to your
If there are any other errors, we won't see them and
stunnel won't tell us whether eveything is fine or not.
To make sure everything is OK, have a look at the
/var/log/secure log file, it should end with the following lines:
... stunnel 4.08 on i386-redhat-linux-gnu PTHREAD+POLL+IPv4+LIBWRAP with OpenSSL 0.9.7f
... 500 clients allowed
If you get an error saying that the binding address is already in use check that your
protocols entry in the
/etc/dovecot.conf file doesn't contain
Stunnel to become a normal service like any other, we're going to install an init script for it.
A script is provided in the source code tree under
tools/stunnel.init but I recommend you get my copy instead as I have modified it to be manageable with the
Install the service and schedule it to run:
# cp stunnel.init /etc/init.d/stunnel
# chmod 755 /etc/init.d/stunnel
# chown root.root /etc/init.d/stunnel
# chkconfig --add stunnel
That's should be all. You can check that
stunnel will start and stop by using
service stunnel start or
service stunnel stop.
< Firewall | EmailServer | AlternateAccess >