Adverts
Introduction
I recently moved this website and a number of others that I own on to a dedicated server. This site had simply out grown it's old home so it was time to move on. One of the things that I had to do was move the mail servers to the new server as hosting a mail server off an ADSL connection is far from ideal. My ADSL connection has served me well - I was fortunate enough to have a static IP address so mail delivery wasn't really a problem but email is getting ever more locked down so a dedicated IP in a server farm is a better bet for getting mail through. As I have to reconfigure the mail servers from scratch I thought now would be a good time to update this document. I've decided to stick with Courier as it's served me well even though it is not the most popular of mail servers. There is a little voice that says I should switch to sendmail but I'll be honest I really can't be doing with the hassle of the configuration settings. Maybe courier will get a decent configuration tool one day (the current web administration interface is far from ideal). This guide is part of a series of guides detailing setting up a complete Courier mail system on Debian.
Courier SMTP
The SMTP server is the very core of the mail system it handles all the sending and receiving of mail to the outside world. Fortunately it is moderately simple to set up a basic server. Without further ado install the packages: courier-maildrop and courier-mta. They will select a number of other required packages that you should simply let aptitude (or other package manager) install.
Specifying the Mail Servers Scope
The first step is to configure the Courier SMTP server to start accepting mail for your domain or domains. In my case I have a number of domains that I want to accept mail for - either way the configuration is very similar. Open the file /etc/courier/locals and add the domains to accept mail for - this defines the domains that Courier believes are local to the server. Local domains are handled slightly differently to remote domains in that they don't need to jump through quite as many security hoops to get mail delivered. You also need to create the file /etc/courier/esmtpacceptmailfor.dir/domains and add to it the domains listed in the locals file. This is a list of domains that the mail server accepts mail for from external sources.
The Courier documentation is a little vague on exactly what the difference is between these two files. It implies that you only need to make an entry in the /etc/courier/esmtpacceptmailfor.dir/domains file if the mail server is acting as a backup mail server. In my experience I have been unable to configure a mail server to accept external mail for a domain that wasn't listed in this file. That is not to say that this file doesn't also include mail for domains that this server is acting as a backup for - it does - it just has to exists and contain all the local domains as well.
The format of both the above files is very simple. If you receive mail addressed foo@example.com you need to add example.com to this file. You can use wild cards in this file at the start of a domain so for instance .example.com accepts mail for all subdomains of example.com such as a.example.com but (strangely) not example.com itself. My file looks like this:
localhost crazysquirrel.com shallowsea.co.uk shallowsea.com ruralescapes.co.uk
It's worth noting at this point that you should always leave a blank line at the end of all configuration files. There was a bug, which I presume is fixed, that would cause the last line to not be read. Once you have finished creating these files run the script makeacceptmailfor to create the database file /etc/courier/esmtpacceptmailfor.dat.
Aliasing
Now that we have told the mail server which domains it accepts mail for it is time to tell it what to do with the mail it gets which is done with aliasing. The first thing to do is specify who is going to receive mail sent to root. Strictly speaking that's not true as the default configuration is to send mail destined for root to postmaster but postmaster doesn't receive mail on most systems so you have to then forward that onto someone else - typically a standard user. This aliasing is done by opening the file /etc/courier/aliases/system and changing postmaster: to postmaster: fred where fred is the name of a standard user account.
At the bottom of the /etc/courier/aliases/system file add any other aliases that you want to create. On a large multi-user system it is unlikely you would want to create a lot of aliases as they could quickly become a maintenance nightmare but on my small mail server it is useful to be able to wear multiple hats. It is probably worth putting in an aliases for mail and www-data as some pieces of software seem to send mail to these users. Once you have finished editing this file you must run makealiases to build the aliases database. This should create a file called /etc/courier/aliases.dat.
At this point you can test your mail server to see if it can send mail. It should probably just work but I give it a quick /etc/init.d/courier-mta restart to make sure it all comes up cleanly. If you are already running a mail server somewhere else and are trying to configure this one on another machine then you might want to tweak your hosts file (/etc/hosts) so that you can test sending mail to example.com on the new mail server without actually affecting example.com. Try the following:
echo "To: fred" | sendmail
A mail should arrive, one way or another, in fred's mail box within a couple of seconds. If fred's account is completely new and you haven't created a Maildir for him the mail will be delivered to a newly created file called Maildir. If you cat this file, cat /home/fred/Maildir, you should see the mail you just sent. Delete this file and then switch user to fred, su - fred, then in the root directory of fred's account runt he command maildirmake Maildir. It is imperative that this command is run by the user you are creating the Maildir for. This will create a Maildir for the user which will now hold all the users delivered mail. Test that the user can receive email again. This time you will have to check in the directory ~/Maildir/new or curr. There should be a file in there that holds the mail you have just sent. You probably also want to check that the aliases that you set up work so replace fred with postmaster in the above command.
If you want to create a default catch all address for Courier you need to use the dot-courier system. This is described well in the dot-courier documentation but I'll quickly cover global catch all addresses here. After searching the alias database and looking for dot-courier files in the expected users home directory Courier will then check the /etc/courier/aliasdir for dot-courier files that describe how to deliver a mail. The one that I am interested in here is called .courier-default which is the last file that is checked before Courier gives up trying to deliver mail. In this file simply enter the name of the user you would like to receive all misdirected mail. This user will get a lot of spam as many spammers simply make up random names to send mail to - it can be useful for training SpamAssassin though and if you are paranoid about losing mail due to misaddressing..
Accepting Mail from Other Machines
In the above test we showed that the SMTP server can deliver mail that is given to it. This mail originated from the the same machine that the mail server is running on so there isn't much of a security issue - someone would need to be working on the box to send mail. The problem is that for a mail server to be useful it must be able to accept mail for delivery from other mail from other machines as well. This process is referred to as relaying and it is important that you set up relaying correctly.
When an MUA (Mail User Agent such as Thunderbird or Outlook) wants to send mail it contacts an SMTP server and passes it the mail. The SMTP server then handles the job of actually routing the mail to it's destination typically by passing the mail on to the mail server at the destination address. The problem here is that if the SMTP server is set up to accept mail from just anyone then it will accept and relay mail from spammers. When spam first started to become a problem this was how the majority of it was spread. To counter the problem with spam SMTP servers are now set up to only accept mail from the machine they run on (127.0.0.1) and the non-routable ip address ranges (10.0.0.0 and 192.168.0.0). This stops a lot of spam but also means that if your mail server is remote from the rest of your network you have a problem sending mail. It is also possible to accept mail for relaying from other IP addresses but if your network is on a dynamic IP address, because it's connection is via ADSL for example, this isn't going to work.
If you do want to change which machines can relay though your SMTP server you need to modify the file /etc/courier/smtpaccess/default the file is pretty self explanatory. Because my mail server and my mail sending machines are on different networks I have commented out the access granted to all but localhost (127.0.0.1). Once you have finished modifying this file you need to run makesmtpaccess to build the database file /etc/courier/smtpaccess.dat.
There is a gotcha here: most text editors such as emacs create backup files when they save a file. These backup files normall end with a ~ (tilde) and they confuse the makesmtpaccess script. If you get an error message such as:
Cannot store record for 127.0.0.1 - duplicate or out of disk space.
then it is a good bet that you have forgotten to remove the backup file. I really wish the script would ignore backups like this but it doesn't and it trips me up every time. If like me you need to have your mail server on a different network to your mail users agents then you need to use authenticated SMTP which I will cover below in the additional set up section.
Additional Setup
Authenticated SMTP and TSL/SSL
First enable authenticated SMTP by setting the ESMTPAUTH setting in /etc/courier/esmtpd to ESMTPAUTH="LOGIN PLAIN CRAM-MD5 CRAM-SHA1". The setting is about 80% of the way down the default configuration file. This is all that is needed to start using authentication to allow remote hosts to relay through the mail server.
In order to use SMTP over TLS/SSL you will first need to install the package courier-mta-ssl which may additionally install the package courier-ssl. When this package installs it will create a self signed key that will enable you to use SMTP over an SSL connection, the key is stored in the file /etc/courier/esmtpd.pem which must not be world readable. The key created doesn't say anything concrete about your domain so your users can't use it to verify who you are and they will (should) receive a warning when they first connect. If you are concerned about your users being able to verify they are talking to the correct mail server you will need to purchase an independently signed key which costs a few hundred pounds. If the SMTP server detects a key (the .pem file) then it will automatically enable ESMTP STARTTLS which will allow it to make secure connections. Once you are happy the key file is in place restart Courier with /etc/init.d/courier-mta-ssl restart and restart courier-authdaemon with /etc/init.d/courier-authdaemon restart to be on the safe side - this makes the secure server read the certificate. Will will need to open port 465 on your firewall in order to use secure SMTP. You can check that courier has bound port 465 with the command lsof -i :465.
Problems with Thunderbird
KMail was set up to send using SMTP over SSL (port 465) with authentication and, while a little slow, it worked flawlessly. I decided then to try Thunderbird as everyone else who connects to the mail server uses it. Disaster. No matter what I did Thunderbird flatly refused to send email using SMTP over SSL with authentication. I tried every different setting I could find but looking at the log files from Thunderbird it appears that it never properly handshakes with the server. There is a connection made as I get a message on the server that reads:
esmtpd-ssl: Unexpected SSL connection shutdown.
once Thunderbird gives up. TheThunderbird SMTP log file only ever reports Thunderbird attempting to make a connection to the server. As clients have to be able to connect using Thunderbird I decided to investigate other ways for them to connect. Ideally I only wanted to mail clients to relay over port 465 (SMTP over SSL) but Thunderbird (and most other mail clients) can also use TLS which runs over port 25. I made the following changes to the configuration files for Courier to allow this:
/etc/courier/esmtpd-ssl - I set AUTH_REQUIRED to 1 to force all clients to authenticate when they are using STMP over SSL.
/etc/courier/esmtpd - I set ESMTPAUTH="LOGIN PLAIN CRAM-MD5 CRAM-SHA1" to specify which authentication methods we will accept.
It turned out that I was unable to get CRAM-MD5 and CRAM-SHA1 to work with KMail but PLAIN and LOGIN worked fine - I eventually traced this to the fact that I am using authpam as the security back end and it doesn't support anything other than LOGIN and PLAIN so it wouldn't have worked with any client. This isn't much of an issue though as the link is encrypted so the password isn't flying around in the plain.
Ideally I would have liked to have AUTH_REQUIRED and ESMTP_TLS_REQUIRED turned on in esmtpd but doing this would stop the server from receiving email from remote servers - because they can't authenticate. As long as the server is correctly configured this isn't a huge problem though - see the note on relaying below. There is one downside in that a misconfigured client could authenticate over a non-TLS link on port 25 which could allow password sniffing.
A Note on Relaying
I felt it was necessary to say a little something about relaying and why the above configuration works. Imagine the situation where you are hosting the mail server for example.com and the set up of the mail server is as follows: The two files /etc/courier/esmtpacceptmailfor.dir/domains amd /etc/courier/local would contain only localhost and example.com. The file /etc/courier/smtpaccess/default specifies that you only accept relay mail from non-routable IP addresses. Port 25 is wide open to the work for anyoen to make a connection to.
A black hat on an external machine (external to your network) attempts to send a mail to foo.com relaying it through your mail server. The mail server first checks to see if the IP address is in the accepted range of relaying address which it isn't it but it is unable to decide whether to drop the mail yet. It then checks the destination against it's list of domains it accepts mail for. The domain foo.com is not in it's list of domains so the mail gets rejected as improper relaying. A white hat with a machine on the internal network can send mail to foo.com because when the mail server checks the IP address it is in the range of addresses the mail server trusts. The situation is more complex when the mail server and network are separated. In this case the mail server will accept mail for relay if the host that is trying to relay authenticates itself with the mail first.
While it would be nice to have port 25 closed it is not generally not possible if you are going to be receiving mail from external sources. Testing mail from sources such as Google Mail indicates that most commercial mail servers won't even try SMTP over SSL and, of course, they can't authenticate with your server. In order to assure yourself that your mail server isn't an open relay you might like to try out an on-line relay tester such as http://www.abuse.net/cgi-bin/relaytest.
BOFH Settings
By default Courier handles mail with corrupt formatting in a very annoying way (IMHO), it creates a new mail and then attaches the old mail to it. While this does stop a lot of viruses in their tracks it also confuses SpamAssassin and garbles mail from poorly written but popular mail clients (Outlook and Outlook Express for example). This set up is changed by creating a file called /etc/courier/bofh and entering the following setting:
opt BOFHBADMIME=accept
After making any changes to this file you need to restart Courier. These settings can also be made on a per-IP basis using smtpaccess but they are generally more useful site wide.
Creating a New Self Signed Certificate
If you intend to use TSL/SSL security you need to have a certificate to secure it with. When the courier-mta-ssl package installs it creates a self signed certificate that will do for testing. Once you start using your mail server, however, you may find a problem. The CN in the automatically created certificate is set to localhost (a sensible default) which generally works. Thunderbird, unfortunately, doesn't like this setting and will complain constantly about it (every time you send a mail). The solution is to create a new self signed certificate with you domain name in place of localhost. Remove the file /etc/courier/esmtpd.pem and then open the file /etc/courier/esmtpd.cnf. Change the setting in the "req_dn" section to match your mail server and save the file. Run the script mkesmtpdcert to create a new certificate. You will need to create a new certificate once a year.
Slow Mail Sending
Ever since I first set up Courier I have been plagued by exceedingly slow sending of mail. Watching the mail logs didn't turn up any obvious problems and the server was very lightly loaded so there was much to be going on with. I decided to just leave it as it was since mail was getting though. Recently, however, I've come across an application that times out before Courier can respond and the imeout can't be changed. I had always suspected that the problem was DNS related and it would appear that is the case. The solution is to add two options (-nodnslookup -noidentlookup) to the TCPDOPTS setting. My setting now looks like this:
TCPDOPTS="-stderrlogger=/usr/sbin/courierlogger -nodnslookup -noidentlookup"
Setting a Sending Size Limit
I discovered the other day that users of my mail server needed to send mails large than I was used to. The mail in question weighed in at just over 10MibB and the mail server rejected it. I checked around for a size limit in the courier settings and couldn't find one anywhere. Turns out there is a default size limit of 10MibB for emails. This can be changed by creating a file called "sizelimit" in "/etc/courier". The file must contain only the maximum size of emails in bytes, for example 20000000 for a 20MB limit. If the value is 0 in the file then the limit is the amount of available disk space on the server.