# LPI Linux Certification/Using Email Servers
## Detailed Objectives (211.1)

(LPIC-2 Version 4.5)
Weight: 4
Description: Candidates should be able to manage an email server, including the configuration of e-mail aliases, e-mail quotas and virtual e-mail domains. This objective includes configuring internal e-mail relays and monitoring e-mail servers.
Key Knowledge Areas:
* Configuration files for postfix.
* Basic TLS configuration for postfix
* Basic knowledge of the SMTP protocol
* Awareness of sendmail and exim
Terms and Utilities:
* Configuration files and commands for postfix
* /etc/postfix/
* /var/spool/postfix/
* sendmail emulation layer commands
* /etc/aliases
* mail-related logs in /var/log/

## Using Postfix

Postfix is written and maintained by Wietse Venema who has also written tcp_wrappers, and Satan. Postfix began its life as VMailer but Wietse has released the software under the IBM GPL and IBM's lawyers discovered that VMailer was too similar to an existing trade mark so the name had to be changed. Postfix is written as a drop in replacement for sendmail and it comes very close to hitting the mark on this. There are a few ?gotchas? which can bite you but they are not serious. Wietse actively supports Postfix through the postfix-users mailing list and there is also a developers mailing list. You can subscribe to the postfix-users mailing list this way:
You can subscribe to the developers list in this way:
One last list we should mention is the announce list. You can join the announce list in this way: echo subscribe postfix-announce | mail majordomo@postfix.org. Postfix development is on-going and these mailing lists are quite active as of this writing. Archives for the mailing lists may be found at: http://www.egroups.com/group/postfix-users/ and at: http://msgs.SecurePoint.com/postfix/.
When a message enters the Postfix mail system, the first stop on the inside is the incoming queue. The figure below shows the main components that are involved with new mail.
The figure shows the main Postfix system components, and the main information flows between them. Yellow ellipsoids are mail programs, Yellow boxes are mail queues or files. Blue boxes are lookup tables.
Programs in the large box run under control by the Postfix resident master daemon. Data in the large box is property of the Postfix mail system.
Mail is posted locally. The Postfix sendmail program invokes the privileged postdrop program which deposits the message into the maildrop directory, where the message is picked up by the pickup daemon. This daemon does some sanity checks, in order to protect the rest of the Postfix system.
Mail comes in via the network. The Postfix SMTP server receives the message and does some sanity checks, in order to protect the rest of the Postfix system. The SMTP server can be configured to implement UCE controls on the basis of local or network-based black lists, DNS lookups, and other client request information. Mail is generated internally by the Postfix system itself, in order to return undeliverable mail to the sender. The bounce or defer daemon brings the bad news.
Mail is forwarded by the local delivery agent, either via an entry in the system-wide alias database, or via an entry in a per-user .forward file. This is indicated with the unlabeled arrow.
Mail is generated internally by the Postfix system itself, in order to notify the postmaster of a problem (this path is also indicated with the unlabeled arrow). The Postfix system can be configured to notify the postmaster of SMTP protocol problems, UCE policy violations, and so on.
The cleanup daemon implements the final processing stage for new mail. It adds missing From: and other message headers, arranges for address rewriting to the standard user@fully.qualified.domain form, and optionally extracts recipient addresses from message headers. The cleanup daemon inserts the result as a single queue file into the incoming queue, and notifies the queue manager of the arrival of new mail. The cleanup daemon can be configured to transform addresses on the basis of canonical and virtual table lookups.
On request by the cleanup daemon, the trivial-rewrite daemon rewrites addresses to the standard user@fully.qualified.domain form. The initial Postfix version does not implement a rewriting language. Implementing one would take a lot of effort, and most sites do not need it. Instead, Postfix makes extensive use of table lookup.
The primary configuration file for Postfix (the working equivalent to /etc/sendmail.cf) is main.cf. The install.cf file contains the initial settings for Postfix which were set up during the RPM installation. The file master.cf is Postfix' master process configuration file. Each line in the master file describes how a mailer component program should be run. In the debugging section we will talk some more about this file. The postfix-script is a wrapper used by Postfix to execute Postfix commands safely for the Linux environment. Let's take a closer look at the install.cf file as this file contains some data which we will need when we start to configure Postfix with main.cf.
The install.cf file is really just a list of the default settings used by the installation program built into the RPM.
Here is the main.cf file with comments by Wietse Venema and our suggested changes interspersed throughout :
This is the same directory that sendmail uses for the incoming mail queue.
The line above must be corrected. The RPM installs the Postfix binaries into /usr/libexec/postfix by default.
The line above is correct and may be left as is.
The line above is correct and may be left as is.
The line above is correct and may be left as is.
The line above is correct and may be left as is but it should be uncommented (e.g. Remove the leading pound sign).
Set the value in the line above to the Fully Qualified Domain Name (FQDN) for you machine. E.g. if your hostname is turkey and your domain is trot.com then your FQDN would be ?turkey.trot.com?. You will also need to uncomment this line.
The line above is redundant for most configurations and can usually be left commented.
The line above should be your domain name only without the hostname prepended to the front of it. As in the example we gave above the correct value here would be trot.com. Don't forget to uncomment the line as well.
The instructions here are pretty good. Typically what's done here is to let this default to $mydomain. Be sure to uncomment your choice.
Once again the instructions here are good. Just uncomment the above listed line and you should be fine. Unless you have some odd requirement the next two entries can be left commented. You shouldn't need them.
The most common practice is to select the line immediately above as your choice here. Be sure to uncomment it and put a comma between the last two entries as it appears to have been omitted.
If you are behind some sort of a firewall or you need to masquerade the envelope (which will be covered later in this document) you would set the ?relayhost? value to the MTA for your domain. If this host is to be *the* MTA for the domain then leave all of these commented out.
In most cases the above line would be uncommented and left as is.
The alias_maps line is pointing at the /etc/aliases file which we preserved prior to removing sendmail. Best practice (recommended) usually prefers that all the Postfix config files be kept together so it might be a good idea to change this line to read:
and also make sure that you put the aliases file in /etc/postfix. Otherwise Postfix will complain on startup and fail to run. The default db type on Red Hat Linux is hash so be sure and use it as we have here. One common error which people have is when they use dbm instead of hash. Don't fall into that trap.
As the instructions say if you want to use the newaliases command to handle the aliases file (recommended) you should uncomment the above line but be sure (if you made the path change we recommended in the alias_maps section) and change it to read:
Then be sure to uncomment the line and run the newaliases command before starting Postfix.
If you happen to run majordomo then you should use the line above instead of just the aliases line. Be sure the path to the file majordomo is correct. The best practice convention is to put it into /etc/postfix. Most Red Hat Linux sendmail installations would have had it in /etc/mail/. We will discuss this a bit more when we get to the listserv section of this document.
The defaults will work fine so you can leave this section commented out unless you have some special need or preference.
This one can be left commented out also, unless you have some special need or preference.
On Red Hat Linux systems you should leave this alone unless you know what you're doing. If you're converting from qmail to Postfix (doubtful) then it would probably be useful.
The previous line is correct for Red Hat Linux defaults so it should be uncommented and left as is.
The default MDA on Red Hat Linux systems is procmail. You can use the command ?which procmail? to verify the path but unless you've changed procmail's location it is located in ?/usr/bin/procmail?. Don't forget to uncomment the line.
On a default Red Hat Linux system you should leave the above line alone.
On a default Red Hat Linux system you should leave the above line alone.
It's your choice what you do here but it can be quite annoying to receive a bazillion bounces a day. Leave this alone (recommended).
The above section enables a filter which you can use to detect and ?bounce? mail which matches a certain regular expression (REGEXP). The difference between using procmail and regexp or PCRE is that these two catch the mail prior to delivery and can effectively block unwanted mail at the SMTP port.
For anyone who knows already how MX records work this is a critical component in the Postfix configuration. Home users probably won't need this line but anyone who handles mail for mutiple domains will.
Here's a sample of how it can be used:
In this example the domains you want to relay for would be placed in the file /etc/postfix/relay-domains. One to a line like so:
Note: this file is *not* hashed or mapped. It is a simple text file. You can also use IP addresses instead of names.
The line above is another critical component in the configuration of Postfix. As the instructions say it specifies the list of networks that are local to this host. For those unfamiliar with the syntax used, it's called Classless Inter-Domain Routing (CIDR) or supernetting. For those familiar with the network classes (A, B, C etc.) it is a way of dividing IP addresses up without reference to class.
The above config entry is a matter of personal preference. It is not required and is up to the administrator to choose.
As the text above says this section is really about rate limiting. It is, essentially, the gas pedal for Postfix. Unless you have some really good reason to change these the defaults should be fine. Once you've run Postfix for a while (particularly those who use it in a professional setting) you may have a better idea of how this should be set for your environment.
We recommend the default here unless there is some overriding reason to change this. Debugging will be covered in a later chapter of this document. For what it's worth this section has no real relevance unless the next is enabled.
This section is used in combination with debug_peer_level so if that's not enabled then this one is moot. This is actually a very neat feature of Postfix. Think about it for a minut. If everything works fine but there is this one host which seems to have problem receiving or sending mail to or from your host then you could use this feature to increase the logging level for just that host.
Leave this section alone for now. We will cover debugging in some detail in a later section of this document. That's it. We've made it through the main.cf file and we're almost ready to start it up.

### master.cf

The master daemon is a supervisory application which controls and monitors all of the other Postfix processes. The master.cf file is the master daemon's configuration file. The master.cf file is the throttle for Postfix. Here you set all of the daemon process count limits. A good example of a useful limit would be to set a limit on the number of SMTP processes which can be executed simultaneously, after all, you might not want to receive 50 messages inbound all at the same time. The key thing to understand here is that any process without an express limit defaults to a 50 process limit.
In general terms the master.cf file is fine with the defaults as they are so you can leave it alone.

### aliases

This is simply the default aliases file and it could be exactly the same one you used with sendmail (recommended) and it works the same way it always has with the newaliases command. If you use majordomo your majordomo aliases will work the same way they always have and they will work with the newaliases command as well.
Control of the postfix server is done through the init.d scripts Don't forget to issue a postfix reload command after changing the configuration ! If you modify the aliases database (/etc/aliases), don't forget to activate the changes by issueing a newaliases command (as with sendmail)
Key terms, files and utilities : /etc/aliases /etc/postfix/main.cf /etc/postfix/master.cf /var/spool/postfix