Postfix

Postfix is a powerful Mail Transfer Agent (MTA) and the de facto standard.

Pre-installation
As only one MTA can be installed at the same time on a system, you might be required to unmerge an installed MTA. 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 (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 and  are the files responsible for this. In this example, the mail server is named  on the domain.

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.

If you wish to have your mail appear as coming from example.com instead of mail.example.com then

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

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 :

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 first, if no such user is found, it will be delivered to testuser, 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 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  USE flag is set, a  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/ 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 :

Verbose SMTP
Before testing the basic mail server setup, the verbose flag of the smtp server can be enabled by adding a  to the smtpd daemon invocation in :

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.

Storage for address rewriting / routing tables
Optionally, as per the USE flags, there are quite a number of possible databases/mechanisms by which to store address-related rewrite rules and routing information. If you wish to use a database (sqlite, mariadb, etc.) then now is the time to read the documentation. If you don't change anything, postfix will still work fine, and you can come back to this later.

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 ) 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 database contains default local accounts required by various RFCs and common internet practice, as well as some pseudo accounts. Simply run the newaliases 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. By default, postfix logs to the syslog but this can be filtered, which will be covered later in this chapter. 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
Postfix should be running properly now and accept connections on port 25, the default SMTP port, and send email anywhere in the world. If available, the sendmail compatible program (installed by postfix) can be used to send a test e-mail.

If not available, or test from a remote machine (which is allowed to relay e-mail) is used, the following can be used also. As SMTP is a simple plain-text protocol, you can easily send email manually using a client. Replace the example address &lt;(username)@(validdomain).(tld)&gt; 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 yellow:

Looking at the 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:

Logging
By default, syslog does not filter mail logs to a separate file, which can be very usefull on a busy mail server. For syslog-ng we create file to define the filtering.

And then include it in the main syslog-ng configuration file

Remember to reload syslog-ng to activate the filter.

Safety net
While testing, you may not want mail get rejected just yet. By default, postfix rejects mails to unknown mailboxes. As a safety feature, it is possible to ask the sender to try again later using error code 450, from the default 550, reject.

Related Articles
You may wish to view a full guide for setting up a postfix server with ClamAV, Amavisd-new, Vipul's Razor, DCC, and SpamAssassin (also available in Japanese, Korean and Russian), though that guide is apparently somewhat dated and misses now common (arguably critical) mail server configuration responsibilities like DKIM and DMARC.

Alternatively, you can selectively add features from the articles below. The non-optional ones are highly recommended, and features are listed in roughly suggested order of implementation:


 * Inbound (receiving mail to your server)
 * Blacklisting, or banning the work of spammers already identified by third parties
 * Checksum-based systems
 * Distributed Checksum Clearinghouse, a global bulk mail detection system
 * Vipul's Razor
 * Greylisting, or delaying accepting mail from new senders (long enough for blacklists to kick in)
 * Miscellaneous anti-spam measures
 * Optional
 * policyd-weight, a weighted rejection policy daemon
 * Investigate all of the various packages in
 * Outbound (sending mail to others from your server, and actually having it received)
 * Sender Policy Framework (SPF), to set IP address ranges allowed to send email from your domain
 * DomainKeys Identified Mail (DKIM), to set cryptographic protection for outbound mail proving it is from your domain
 * Domain-based Message Authentication, Reporting and Conformance (DMARC), to get feedback on issues third parties have processing mail you have sent, and to inform them how you'd prefer them to handle such issues
 * Optional
 * Relaying (sending mail on behalf of connecting clients to third-party servers)
 * Simple Authentication and Security Layer (SASL), for identifying clients authorized to supply mail for relay