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
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
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:
Stick to this tutorial. We'll understand each one of these, in order.
Your mail server needs to know how it should identify itself to other mail servers. And here's how.
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.
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
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
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 = 220.127.116.11/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
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
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
rootin that server to
root, and seeing if it arrives
- sending an e-mail from
rootin 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
mynetworksgroup), 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
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!