I talk about mutt a lot in this column, if you hadn't noticed. For me, in this day and age of large graphical mail programs and Web-based mail applications, you still can't beat the speed, power and customization of mutt. Let's also not forget the vi-style keybindings—I love those.

One thing you might notice the first time you use mutt, however, is that it is strictly a MUA (Mail User Agent) and not an MTA (Mail Transfer Agent). This means mutt is concerned only with acting as an e-mail client and doesn't actually contain any code to communicate with remote mail servers. That job is done by an MTA. Although many mail clients also include code so they can relay mail through an MTA, mutt opts to use the system's own local mail server. Traditionally, this hasn't been an issue on Linux, as most Linux servers have had some mail server installed and set up. These days, however, you might not have a fully configured mail server on your desktop install. That's okay though, because in this column, you'll see how simple it is to set up your own local mail server, thanks to Postfix.

Even if you don't use mutt, there are many advantages to having your own local mail server, if only to relay mail for you. For one, it can handle spooling all of your e-mail and will retry delivery automatically if it fails for some reason or another (such as if your wireless connection drops or you close your laptop) without having to leave your mail program open. For another, once you have your mail server set up how you want it, any other mail client on your computer can take advantage of it: simply point your client to localhost.

A number of different mail servers are available for Linux these days, each with its own set of advantages and disadvantages. Many holy wars have been fought over Sendmail vs. Postfix vs. Exim vs. using Telnet to connect directly to port 25 on a mail server and type in raw SMTP commands. I've tried them all over the years (yes, even Telnet), and for me, Postfix has the best balance between stable performance, security and most important, simple configuration files. So for this column, I discuss the specific steps for setting up Postfix as a mail relay.

The first step is to install the Postfix server itself. On most distributions, you'll find this package is split up into a main Postfix package plus a few extra packages that provide specific features, such as MySQL or LDAP integration. Because we are just setting up a basic mail relay here, all we really need is the main Postfix package. Now, if you install this package on a Debian-based system, you will be prompted by the post-install script that acts as a wizard to set up Postfix for you. If you want, you simply can walk through the wizard and pick “Internet Site” to send e-mail out directly to the rest of the Internet or choose “Internet with smarthost” to relay all of your mail through a second mail server (perhaps provided by your ISP) first. Either way, you will be asked a few simple questions, and at the end, you'll have a basic Postfix configuration ready to use.

On other systems (or if you choose “No configuration” on a Debian-based system), you might end up with an empty or very heavily commented Postfix configuration file at /etc/postfix/main.cf. What you'll find is that for a basic mail server, you really need only a few lines in your config. Postfix picks pretty sane and secure defaults, so if you want it to deliver mail on your behalf, you need only a few lines:

mynetworks = 127.0.0.0/8
inet_interfaces = loopback-only

Yes, that's basically it. Now, simply restart Postfix with /etc/init.d/postfix restart, and your mail server will be up and running. With the sane defaults in Postfix, you just need to hard-code those two settings to ensure that Postfix accepts mail only on localhost. The inet_interfaces line tells Postfix to listen only on the localhost address for e-mail so no clients can connect to your server from the outside. The mynetworks line adds to that security and tells Postfix to allow only mail from localhost to be relayed through the server.

It used to be that the above was all you needed for a functioning mail server on the Internet. With the rise of spam measures and countermeasures, however, these days, fewer and fewer ISPs are willing to allow port 25 traffic from clients through to the outside world. Even if they do, many mail servers on the Net won't accept traffic from hosts inside ISP networks. If you find yourself on such a network, you likely will need to add a relay host to your main.cf. The relay host is a mail server usually provided by your ISP through which your mail server can send e-mail. If you were setting up a client like Thunderbird, for instance, this would be the SMTP server you would configure for it.

To set up a generic relay host in Postfix, just add:

relayhost = mail.somedomain.net

to your /etc/postfix/main.cf. Replace mail.somedomain.net with the hostname of your ISP's relay host. Once you modify the file, simply type postfix reload as the root user to enable the new settings.

Of course, some mail servers won't just let anyone on their network relay through them (and rightly so). In that case, usually they require that everyone authenticate with them first. This takes a few extra steps with Postfix, but like with everything else, it's still not very difficult. First, add the following lines to the /etc/postfix/main.cf:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

This tells postfix to enable SMTP authentication and tells it to look in /etc/postfix/sasl_passwd for logins and passwords to use for hosts. The next step is to create the /etc/postfix/sasl_passwd file. If I wanted to log in to mail.somedomain.net with the user name kyle and the password muttrules, I would put the following line in the file:

mail.somedomain.net kyle:muttrules

There is a downside to this in that the password for the account is now in clear text. That's less than ideal, but you can at least make sure that only root can read the file. As the root user, type:

# chown root:root /etc/postfix/sasl_password
# chmod 600 /etc/postfix/sasl_passwd

Postfix actually doesn't read this file directly; instead, it reads a hash database created from this file. To create the file, run:

# postmap /etc/postfix/sasl_passwd

And, you will see that a new file, /etc/postfix/sasl_passwd.db, has been created. You'll need to run the postmap command any time you modify the /etc/postfix/sasl_passwd file. Now, reload Postfix one final time, and mutt should be able to relay mail through your local host. If you want to perform a quick test without mutt, you can type:

echo test | mail -s "test" user@remotehost

and it will send an e-mail message with a subject and body of “test” to the user you specify.

Postfix's logfile might vary a bit, depending on your system, but you should be able to find it in /var/log/mail.log or /var/log/maillog. That's the first place you should look if you find that some mail is not being delivered. The second place to look is the mailq command. That command will give you a quick status of all e-mail that is currently in the local spool along with its status. If all of your mail has been delivered successfully to other hosts, the output will look something like this:

$ mailq
Mail queue is empty

It's truly that simple. Of course, mail server administration definitely can become more complex than this when you want to do more than relay your own personal e-mail. But, it's good to know that simple configurations like the above are possible. If you are like me, saving time on the Postfix configuration just gives you extra time to tweak your mutt config.