Full Mail Server Solution w/ Virtual Domains & Users (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Page 10

VII. Secure Email

In an ideal world, our users would be able to send/receive email whenever they were on the net, from any place in the world. Unfortunately, that's incredibly insecure... passwords are being tossed back and forth in plain text via the SMTP and IMAP protocols, and that means anyone who wanted to could just 'snoop' the password.

If your users don't need direct access to the mail solution, then don't give it to them! There's no point in stressing over a secure email setup if all your users need is Webmail! Just make their connection to the webmail server secure, and make sure that the webmail server uses a secure network connection when talking to your mail servers. Problem solved! If, on the other hand, your users do require the ability to send/receive mail via the internet without using webmail, well then, that just makes things more difficult. Not impossible, just difficult.

So, here's your problem: SMTP and IMAP send passwords over clear text. You can have them send passwords using MD5, but basic MD5 can be hacked. You can have them send passwords using MD5CRYPT, but then you're dealing with multiple implementations (not to mention the fact that not all email clients support MD5 passwords). The solution? TLS (Transport Layer Security). We're going to set up our solution to support an encrypted connection over the internet. While we could modify some of our existing servers to handle this, there's no point in over-complicating their setups. We're just going to run a seperate server to handle all of this: secure-mail.example.com

NOTE: In the original scenario, the small business had multiple static IP addresses. Since this is the case, we were able to run SMTP+TLS on port 25, if you don't have multiple IP addresses, then that is not possible. The reason is simple enough: While IMAPS(secure IMAP) runs a different port (993) than standard IMAP (143), SMTP+TLS runs on the SAME port as SMTP (25). So, using a firewall to route based on ports allows you to run seperate IMAP and IMAPS servers, but no firewall in the world can route port 25 to two different machines. Even with all of that though, you could always just run SMTP+TLS on a non-standard port... heck, it would even be more secure.

So, with all of that in mind, we're going to setup a secure mail server, which uses SMTP+TLS for sending mail, and IMAPS for receiving it.

A. SSL Certificates

The simplest form of encryption is having a simple self-signed certificate on the server. This will generate a warning message when the clients first connect, but they should be able to save it for further use. It is not really secure, since anyone can execute a man-in-the-middle attack if you don’t save the certificate.

The next level is using a server certificate signed by a Certificate Authority (CA), either a commercial one, or perhaps the company internal CA. This way, the server certificate will be trusted, and if you now receive a warning, there is potentially something bad going on.

Last but definitely not least is using client certificates for logging in to the server, and using a server certificate to authenticate the server to the clients. This is quite secure, but it is not supported in all mail clients. Thunderbird among others do have support for it.

1. Self-signed server certificate

First create the directories, create the private key, and lastly create the certificate.

# mkdir -p /etc/ssl/example.com/mailserver/
# cd /etc/ssl/example.com/mailserver/
# openssl genrsa 1024 > mail-key.pem
# chmod 400 mail-key.pem
# openssl req -new -x509 -nodes -sha1 -days 365 -key mail-key.pem > mail-cert.pem

Note that “Common Name (eg, YOUR name)” MUST match the name of the server, which in this case is secure-mail.example.com

2. CA-Signed Certificate

Using a real CA-signed certificate is no different from using a self-signed one. It’s just another step in the key-pair creation. If your company has its own CA, then they should issue a certificate for the mail server. A Google search for be your own ca will give you enough answers to create one yourself, if you have the need.

Share this page:

Sub pages

5 Comment(s)

Add comment

Comments

From: at: 2008-03-27 06:06:28

Hi Vector,

I would just like to know how the mail gets transferred from the MX's to the delivery server (postman). I'm trying to understand how this full mail server setup works because I would like to implement something similar to this but using centos and ldap users.  

From: Stefan at: 2008-11-01 18:07:49

There is no explanation on how the mail is actually transfered from the MX server to the Mail Delivery Server. Using the steps in the guide will make the MX server try to deliver the mail directory into the NFS shared vmail folder, which isn't the desired behaviour.

From: Matt at: 2009-06-15 13:16:16

"NOTE: This is a temporary setup, just because we hadn't finished the DSPAM virtual user install prior to writing this guide. Ideally, you'd want DSPAM looking at the same virtual user table as Postfix in order to get all the token information stored correctly. I'll update the guide as soon as we've completed that change-over."

 Has this been updated anywhere? can anyone shed some light on what changes should be made?

 

From: mbsouth at: 2009-09-10 10:02:01

Would be nice to have an updated howto (based an this one) with Debian Lenny, Postfix 2.5(6), Dovecot 1.1(2) on three nodes (2xSMTP Postfix, 1x Dovecot IMAP/POP3)

 

From: at: 2007-11-15 20:55:15

Heads up when using the configuration examples for the mailbox path. Since maildir:/vmail/%d/%u is used in dovecot.conf, you should do the same in dovecot-sql.conf.

Such as:

# Get the mailbox
user_query = SELECT '/vmail/%d/%u' AS home, 'maildir:/vmail/%d/%u' AS mail, 150 AS uid, 8 AS gid, CONCAT('dirsize:storage=', quota) AS quota FROM mailbox WHERE username = '%u' AND active = '1'
# Get the password
password_query = SELECT username AS user, password, '/vmail/%d/%u' AS userdb_home, 'maildir:/vmail/%d/%u' AS userdb_mail, 150 AS userdb_uid, 8 AS userdb_gid FROM mailbox WHERE username = '%u' AND active = '1'

Otherwise mail is delivered to /vmail/domain/user@domain and then IMAP checks /vmail/domain/user

Or change dovecot.conf to maildir:/vmail/%d/%n if you prefer the latter.