Postfix

Over the years, Postfix has become the new de facto standard amongst Mail Transfer Agents (MTA). It has beaten qmail which in turn had taken down sendmail from the throne. This document describes how to setup and test a basic Postfix server.

Pre-installation
As only one MTA can be installed at the same time on a system, you might be required to unmerge all other installed MTAs like, , , or any of the qmail packages. The package manager will report a block when another MTA is still installed. You can resolve this block by manually unmerging the old mail server. For example you can remove ssmtp (which might have been installed as the default when a program requested a mail server to be installed) with this command:

Installation
has several USE flags that may be desired for certain bigger setups. As this article aims at installing and configuring a basic Postfix setup, none of them will be required initially.

Fully Qualified Domain Name (FQDN)
Though not entirely related, for a MTA to function properly, it is imperative that its hostname is set up correctly. Under Gentoo /etc/conf.d/hostname and /etc/conf.d/net are the files responsible for this. In this example, the mail server is named foo on the domain example.com.

Verifying that the FQDN is setup properly for the domain.

If for any reason the FQDN cannot be set properly, Postfix needs to be told what its FQDN is. Otherwise leave it at its commented out default.

Trust and Relay
This one is a really important thing to get right. By default, a Postfix installation is pretty tight, only allowing users on the same subnet as the mail server to relay email through Postfix. If this gets messed around with, it can potentially open the door to all users from anywhere. This is called an open relay and is begging for abuse by spam merchants, likely resulting in your domain to be quickly blacklisted. This defeats the purpose of setting up a personal mail server, if nobody will talk or listen to it.

There are means and ways, like SMTP Authentication, that allow you to secure access to your mail server even further. Depending on the trustworthiness of the users connected to the local network, it might be beneficiary to restrict access even for machines within the own subnet. This also has the benefit of not letting potentially compromised machines in the local network abuse the mail system, but entails additional configuration. To only allow the mail server itself to relay email without authentication, make a change to main.cf

Address extensions
Address extensions allow you to encode additional information besides the recipient in a valid email address. The recipient is separated from the additional information usually by a + character, but it is configurable. To enable support for address extensions, edit your main.cf:

The way this works is, when trying to deliver a message to testuser+spam@example.com, Postfix will try to deliver the message to testuser+spam</tt> first, if no such user is found, it will be delivered to testuser</tt>, the part of the email address before the delimiter. This feature can be quite useful for sites that require email address registration. Signing up with testuser+somesite@example.com</tt> allows to easily filter and trace where a message originated from. If for example some unsolicited mail was delivered to that address, it likely comes from somesite. Even better filtering of unsolicited email can be achieved by using Spamassassin or AMaViS.

maildir
When Postfix completes merging and the mailbox</tt> USE flag is set, a home_mailbox</tt> directive is added at the bottom of the file. To make future updates easier, it's a good idea to move the home_mailbox = .maildir/</tt> to its appropriate location in the file.

For testing purposes, the following two features can be temporarily enabled:

Soft bounce
Soft bounce decreases the chances of endless bounce loops caused by an invalid email setup. To enable soft bouncing, add this to your main.cf</tt>:

Verbose SMTP
Before testing the basic mail server setup, the verbose flag of the smtp server should be enabled by adding a -v</tt> to the smtp daemon invocation in master.cf</tt>:

That rounds up basic configuration. Postfix offers a vast amount of other features, including virtual domains and users, that exceed the current scope of this article.

Starting Postfix
Before starting Postfix for the first time, the local alias database has to be compiled. If this is not done, Postfix may appear to have started normally, but won't work and the log (usually found in /var/log/mail.log</tt>) will be spammed with errors: Mar 16 11:40:32 foo postfix/smtpd[18923]: fatal: open database /etc/mail/aliases.db: No such file or directory

The alias</tt> database contains default local accounts required by various RFCs and common internet practice, as well as some pseudo accounts. Simply run the newaliases</tt> command to generate the database:

Now it is time to start postfix for the very first time.

It can be very useful to monitor the mail log file using tail -f</tt>. A successful start looks like this: Nov 23 15:26:42 foo postfix/postfix-script[13433]: starting the Postfix mail system Nov 23 15:26:42 foo postfix/master[13434]: daemon started -- version 2.8.4, configuration /etc/postfix

Testing Postfix
For the lay person, email your self, and don't forget to check the spam box. (if your email were to happen to be bunnyfoofoo@gmail.com)

Now that Postfix is running properly, it should accept connections on port 25, the default SMTP port, and send email anywhere in the world. As SMTP is a simple plain-text protocol, you can easily send email manually using a telnet</tt> client. Replace the example address &lt;(username)@(validdomain).(tld)&gt;</tt> with a real email address to see it work. This is an example SMTP conversation with the parts the client (in this case that is you) sends are highlighted in blue color:

Looking at /var/log/mail.log it can be verified that the message got properly relayed: Nov 23 16:13:02 foo postfix/smtpd[28494]: connect from foo.example.com[127.0.0.1] Nov 23 16:13:49 foo postfix/smtpd[28494]: 6705C20E32: client=foo.example.com[127.0.0.1] Nov 23 16:13:51 foo postfix/cleanup[28508]: 6705C20E32: message-id=<20111123151349.6705C20E32@foo.example.com> Nov 23 16:13:51 foo postfix/qmgr[28490]: 6705C20E32: from=<me@somewhere.com>, size=314, nrcpt=1 (queue active) Nov 23 16:13:52 foo postfix/smtp[28510]: 6705C20E32: to=<(username)@(validdomain).(tld)>, relay=mail.(validdomain)(.tld)[5.6.7.8]:25, ⏎ delay=19, delays=18/0.02/0.37/0.32, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 469A684F8) Nov 23 16:13:52 foo postfix/qmgr[28490]: 6705C20E32: removed Nov 23 16:13:54 foo postfix/smtpd[28494]: disconnect from foo.example.com[127.0.0.1]

Performing the same test from a different host should fail, as it is untrusted: