Setting up a mail server using Postfix in 5 minutes

Hello, again! Continuing the (now lengthy) Server management series, this time we'll learn how to set up a mail server, using the famous and very secure Postfix mail server package.

For the record, I'm assuming that you'll be using your favorite distribution's packages for the installation. I'm also assuming that you have root access to your server.

Oh, by the way, I've getting several comments about users having issues with highlighted keywords on my articles. If you're one of those users, please get a Web browser that displays transparent PNGs properly. Microsoft Internet Explorer is not one of them. Any comments about highlighted keywords from IE users will go straight to /dev/null.

Postfix: the reliable mail package

Postfix is my favorite mail server package. Why? Postfix is unique in that:

• it's surprisingly easy to configure (contrast that to Sendmail, and you'll understand this point)
• it's very secure, featuring a security model with separate user contexts for each task
• it's also very popular
• it's fast

Configuring Postfix

Remember that I'm assuming you're installing Postfix from your favorite distribution's install CDs or download servers. With that in mind, I'd really like to assume that you've already installed Postfix, and skip to the configuration part.

To set Postfix up so it runs as a service, use the following commands:

/sbin/chkconfig --add postfix
/sbin/chkconfig --level 35 postfix on

And that's it. /sbin/service postfix start and see if it's running with a quick ps ax command. You should see several new processes.

Now, on to configuration. The Postfix configuration file is main.cf. You can usually find it in /etc/postfix (although your distribution's file layout may vary). The three most commonly changed configuration settings are the following:

• myorigin
• mydestination
• mynetworks_style and mynetworks
• inet_interfaces

Stick to this tutorial. We'll understand each one of these, in order.

Mail origin: myorigin

Your mail server needs to know how it should identify itself to other mail servers. And here's how.

The myorigin configuration key specifies the origin domain for all mail sent through your server. While, by default, myorigin is configured to use your server hostname, you may want to change it to your actual domain name. You can accomplish this by setting the configuration key as follows:

myorigin = $mydomain

$mydomain will automatically be filled in with the domain name your server is using.

Destinations: mydestination

Your mail server also needs to know which domains it serves. mydestination fills that need.

mydestination lets Postfix know which domains your server will accept mail from. In other words, mail sent to any of the domains listed in mydestination will be delivered to local mail boxes. The default value:

mydestination = $myhostname localhost.$mydomain

is not exactly useful, but it's very secure, though most of the time you'd like it to receive mail for your entire domain. If that's what you want, you should configure Postfix as follows:

mydestination = $myhostname localhost.$mydomain $mydomain

That, of course, assumes that an MX DNS record exists and points to your server as the final destination for e-mail. Don't forget the DNS step: it's very important (but, sadly, outside the scope of this 5-minute tutorial).

Of course, there's nothing stopping you from accepting mail for multiple destinations. An example:

mydestination = $myhostname localhost.$mydomain usm.edu.ec company.com

Relay control

Postfix has a relay control that's very simple to use. In short, relaying means using your mail server to transfer mail from a client to a destination which is not your mail server.

As you've probably noticed, most consumer-level ISPs have an outbound mail server set up for their clients. That's a good example of a relaying mail server: that mail server is configured to accept relay requests from customers' e-mail clients. Of course, all mail servers should have a properly tuned relay control configuration — overly zealous servers won't let their users send mail to other users, while overly permissive servers will let spam and all its consequences through.

You'll no doubt be in the same position in your organization: you'll need workstations in your organization to be able to relay mail through your mail server. Again, that's easy to accomplish. By default, Postfix is configured to accept e-mail from local networks. To change this, we'll explore two configuration options.

First of all, there's the mynetworks_style configuration parameter. This parameter can take the following values:

• subnet (default): Postfix will let e-mail clients relay mail, if they are in the same IP subnetworks Postfix is connected to.
• class: Postfix will let e-mail clients relay mail, if they are in the same class A/B/C networks Postfix is connected to.
  Trust SMTP clients in the IP subnetworks that Postfix is connected to.
• host: Postfix will let e-mail clients relay mail, only if they run in the same server

For most usage scenarios, you'll want to leave this configuration as subnet.

If you want more fine-grained control, there's the mynetworks parameter. Through mynetworks, you let Postfix know exactly which networks are allowed to relay mail. Keep in mind that the mynetworks_style parameter will be ignored if mynetworks is set.

mynetworks = 168.100.189.0/24, 127.0.0.0/8

is a good example. That will let e-mail clients relay mail, but only if they're originating either from the mail server, or any of the computers in the IP subnetwork 168.100.189..

Network configuration

The final, and perhaps most important, configuration parameter for Postfix, is the inet_interfaces parameter. Through inet_interfaces, you let Postfix know which network interfaces should use.

The default is usually:

inet_interfaces = all

though your distribution may have changed this to make Postfix only listen through the localhost network interface (Fedora Core is a good example of this). You can set this to one or more network addresses, domain names, or leave it as all. I recommend you leave it as all and do any securing through iptables.

Letting Postfix know you've changed its configuration

Once you've configured Postfix, restart it using the /sbin/service postfix restart command (though this may vary from distribution to distribution). You should have a Postfix server up and running. To test it, I recommend the following testing procedure:

• sending an e-mail from root in that server to root, and seeing if it arrives
• sending an e-mail from root in that server to another user in the machine, and seeing if it arrives
• sending an e-mail to a user in the machine, using a mail client within your organization (that is, one that falls in the mynetworks group), and seeing if it arrives
• sending an e-mail to a user in the machine, using Hotmail, Gmail or any other free e-mail provider, and seeing if it arrives
• sending an e-mail to a Hotmail or Gmail account, using a mail client within your organization, and seeing if it arrives
• sending an e-mail to a Hotmail or Gmail account, using a mail client outside of your organization's mynetworks, and configured using your newly installed mail server as the outbound mail server — and verifying that this test fails, which is a telltale sign that your server won't act as a spam server

Conclusions

I honestly don't want to start a religious flamewar but, in my own very humble opinion, Postfix is the best mail server out there. If you're not using Postfix, I seriously recommend it to you. Give it a spin — it'll probably stay in your organization for good.

There's more documentation about Postfix in the project's Web site. Be sure to peek into it as soon as you have more than 5 minutes to spare.

That's it for today. Happy hacking!