What is Postfix

Postfix SMTP server

Postfix is ​​an SMTP server. SMTP is the protocol for exchanging mail on the Internet. How exactly does an SMTP server work?


The graphic shows the usual way an email is sent via SMTP:

Alice wants to send an email to Bob. Alice is a customer of T-Online and has her email address [email protected] there. Bob uses GMX as a mail provider and has the address [email protected] there.

Alice sends an email to the address [email protected] (1). She uses the T-Online mail server to send. The protocol over which the mail is sent from Alice's PC to the T-Online mail server is SMTP. However, the T-Online mail server is not the final destination of the mail, as it is not responsible for mails that should go to @ gmx.net addresses. The mail server should actually reject such a mail because it is not the mail server responsible for the target domain. However, Alice is a T-Online customer. Therefore it is allowed to "relay" mails over the T-Online server.

A "relay" is a mail server through which email is only passed through for the purpose of final delivery. An open relay is a mail server through which anyone can send mail to any destination. Such open relays are of course an invitation to spammers. Therefore, mail servers are now generally configured in such a way that they only relay emails from their own customers who have identified themselves as such. Other emails are rejected if they are not addressed to the domain for which the mail server is responsible.

Originally, the SMTP protocol did not provide for authentication. Authentication was only retrofitted when the need arose due to the increased occurrence of spam. Therefore, Alice's PC identifies itself as a customer with the T-Online mail server via SMTP Auth. To do this, she has to send her username and password. In general, SASL is used nowadays for SMTP-Auth. SASL stands for Simple Authentication and Security Layer.

After the T-Online mail server has accepted the mail for relaying, it will try to deliver it to its actual destination. To do this, he has to ask a DNS server which mail server is responsible for the target domain (i.e. gmx.net) (2). This is called an MX query (MX is the so-called resource record in the DNS server in which the responsible mail servers are contained). DNS servers generally have the task of returning IP addresses to hostnames, since computers, unlike humans, only work with IP addresses. Why doesn't the T-Online mail server ask for the IP address for gmx.net directly? This is because gmx.net is a domain and not a host name. There can be many host names under the domain gmx.net. However, the T-Online mail server must know which of the gmx.net hosts is the mail server responsible for the entire domain. MX records point to a single host name in the domain, which is responsible for all mail sent to the domain. Theoretically, of course, someone could also send an email to a hostname. In this case the MX entry would not be required and the mail could be delivered directly to the addressed host. Such a mail would then have the form: [email protected], instead of [email protected] However, it has become generally accepted and is ultimately easier for everyone involved (users as well as mail administrators) to use domains.

The DNS server responds with the MX record for gmx.net (3).

The T-Online mail server can then deliver the mail to its actual destination. This delivery happens again via SMTP, this time without authentication, of course, since the gmx.net mail server has to accept the mail anyway, since it is the responsible mail server for the domain (4).

The GMX mail server will know from the left part of the email address to which mailbox it has to deliver the mail. He will then store the mail in his local message store (5). The task of the SMTP server is thus fulfilled. The email is delivered to the appropriate local mailbox on the mail server. However, Bob has not yet received the email because of this.

Bob has to pick up his mail first (6). However, this does not work via SMTP but via other protocols such as POP3 or Imap. POP3 and Imap are generally implemented by server programs other than SMTP. Postfix is ​​a pure SMTP server. For POP3 as well as for Imap there is various other software that is used together with an SMTP server. Examples of POP3 and Imap software are: popa3d (POP3 only), popper (POP3 only), Courier (POP3 and Imap), Dovecot (POP3 and Imap) and Cyrus (POP3 and Imap).


Postfix is ​​an SMTP server that is available as open source software, free for Unix-like operating systems (such as Linux, BSD or Solaris). It is released under the IBM Public License. Postfix was originally developed by Wietse Venema at IBM. However, IBM has expressly made Postfix available to the open source community for free further development and no longer controls the project.

Postfix was developed primarily as a secure and easy-to-use replacement for Sendmail. Until then, Sendmail was almost the only mail server that was used on the Internet. However, Sendmail had two main problems: On the one hand, Sendmail was noticed in the past mainly due to security gaps, on the other hand, Sendmail is also extremely complicated to administer. In the past it was said that you are not a real Unix admin until you have configured Sendmail, but anyone who has configured Sendmail once does not do it a second time.

The vulnerabilities in Sendmail were mostly closed quickly, but Sendmail is also not designed for security in terms of its basic architecture. Sendmail is a single large program that must run with root privileges in order to be able to deliver email to the local mailboxes of different users. Therefore, anyone who manages to exploit a vulnerability in Sendmail also automatically has root rights in the system into which they have broken into.

Postfix was designed with security in mind from the start. Its creator Wietse Venema is a recognized security expert who has mainly dealt with IT security research. Postfix is ​​not a monolithic block like Sendmail, but consists of various individual program parts. This enables each part of Postfix to be run only with as many rights as are absolutely necessary. No part of Postfix that communicates with the network runs with root privileges.


Postfix consists of different parts: The master process is started first (with root rights). His only task is to start the other parts of Postfix when necessary and control them. The master process itself is configured via the configuration file master.cf. The master.cf contains the parameters with which all other processes are started, such as whether they are started as an unprivileged user or with root rights, or whether they run in a chroot. The master.cf file therefore does not have to be changed in most cases and should remain as it is for the time being.

Some of the other important parts of Postfix are the Queuemanager qmgr (is responsible for all queues in which mails are temporarily stored), postdrop (records local mails), smtpd (listens for mails from the network), smtp (sends mails to the network) , trivial-rewrite (does some simple header rewriting) and local (puts mails locally in mailboxes). There are more parts of Postfix, but these are some of the most important ones.


The directory with the Postfix configuration files is created as / etc / postfix on most systems. In this directory you will find the already mentioned master.cf and the main configuration file main.cf is also located here. The overall behavior of all parts of Postfix is ​​determined by the main configuration file main.cf.

What does Postfix need to know from its configuration file in order to do its job? As we have seen, Postfix has to know which mail domain it is actually responsible for. Incidentally, this can also be several domains on one server. Second, he has to know how to handle mail that is not addressed to his domain or, in other words, who is allowed to use the server as a relay. Thirdly, the server must also know where to store mails for which it is the ultimate destination, in other words, where the local message store is located. Of course, there are also many other aspects and subtleties that can be configured, but these 3 aspects logically result from the above and thus a simple basic configuration of Postfix can be achieved.


The main.cf generally consists of name / value pairs. The first term on a line on the left is the name of a configuration parameter. This is followed by the value assignment. Space and the = sign are optional. Comment lines start with a #.

Some parameters can have multiple values. Multiple values ​​can be separated by both commas and spaces. Multiple values ​​can also be distributed across multiple lines if the new line begins with spaces or tabs.

The values ​​of parameters can be reused if another parameter with a preceding $ sign is used as the value. For example: mydestination = $ mydomain. That the value of mydestination should be set to the same value as mydomain.

The following part shows a simple configuration for Postfix in main.cf, which I will explain below:

# Who am I and for which domains am I responsible
myhostname = mail.example.com
mydomain = example.com
mydestination = $ myhostname, $ mydomain
localhost. $ mydomain, localhost, example.net

# Who can relay mail
mynetworks_style = subnet

# Where do locally stored mails end up?
mail_spool_directory = / var / mail

Who am I?

The server is informed of its own host name via myhostname. The domain is set explicitly with mydomain. If mydomain is not set, Postfix automatically uses the value of myhostname without the first part of the name. So if myhostname is given with host.example.net and mydomain is not set, then mydomain is automatically example.net.

mydestination determines for which domains the server feels responsible. Several values ​​can be listed here. If this parameter is not set, the default value is: $ myhostname, localhost. $ Mydomain.

Relay control

mynetworks_style determines which computers can also use the mail server as a relay. Or more correctly actually: Which clients have more rights on the mail server, whatever this "more rights" may look like. Normally, more rights simply means permission to use the mail server as a relay. The default value of mynetworks_style is subnet (as indicated, so this could also be omitted in the example). The values ​​of mynetworks_style can be host, subnet or class, where host means that only the server itself is allowed to relay (i.e. locally generated mail), subnet means that all clients that are in the same subnet as the mail server are allowed to relay and means class that all computers in the same class A / B / C network are allowed to relay.

mynetworks_style = subnet is useful when the mail server is the central mail server within an internal LAN, but on the Internet this setting could be dangerous and should be set to host. SASL authentication as a way to enable authenticated clients to relay requires a whole series of additional steps that I will not explain in this basic configuration here.

But what if I operate a LAN with several subnets? In addition to mynetworks_style, there is also the mynetworks parameter, which I can use to replace mynetworks_style. If mynetworks is set, mynetworks_style is no longer taken into account. In mynetworks, I can list IP addresses or subnets that relaying is allowed. As an an example:

mynetworks =,,

Mail repository

The system directory under which the local mailbox files are located is determined with mail_spool_directory. A POP3 / Imap server that is also installed must access the same directory in order to be able to deliver mail. There are 2 different storage formats and 4 different options for how Postfix delivers locally for local delivery.

The two storage formats are Mbox and Maildir. Both storage formats are widely used as Unix email storage formats and at least one of the two formats is also understood by every POP3 or Imap server. Mbox is a format in which all mails are stored together in a single file. Maildir is a format in which each email is a separate file. The mails are in a directory, which must have special sub-folders in order to separate new emails from the rest. Since not every POP3 server or Imap server understands every format, the choice of the respective POP3 server will generally also determine the choice of the storage format used for Postfix. If you have the choice between both formats, I recommend Maildir, as Maildir causes fewer problems with large mailboxes than Mbox.

The four types of local delivery that Postfix can handle are system mailboxes, delivery to the home directory, delivery to commands and LMTP.

System mailboxes are directories that are specially provided by the operating system to provide mailboxes for the users of the system. Often this is / var / mail or / var / spool / mail. System mailboxes are always defined by the parameter mail_spool_directory. The mailboxes themselves are created there as mbox files with the name of the user account.

If the parameter home_mailbox is used in the main.cf instead of mail_spool_directory, the mails are delivered to the home directory of the user. With the value home_mailbox = mybox, e.g. B. an Mbox file mybox can be created in the respective home directory of the user in which the mails are then delivered. A maildir directory instead of an mbox file can be easily defined with a trailing slash. E.g .:

home_mailbox = Maildir /

This would put all mail in a maildir directory called Maildir in the home directory. The Maildir directory itself would have to already exist. Required subdirectories would be created automatically.

It is also possible not to deliver mails directly to the mailboxes, but to use an additional program that is responsible for the mailbox storage. This can be B. be a filter program or the like. A well-known example of this is the procmail program, which can perform actions on mails using filter expressions. An external program for delivery can be specified with the mailbox_command parameter. E.g .:

mailbox_command = / usr / bin / procmail

Finally, there is the possibility of delivering mails via LMTP. LMTP is its own protocol which is similar to SMTP, but simpler than SMTP and is specially designed for the local delivery of mails. LMTP is mainly needed if you use a POP3 or Imap program that uses its own special format for your message store, or if you have to make very large complex setups where the message store and SMTP server are 2 different machines. This is e.g. This is the case, for example, with the Cyrus Imapserver, which uses its own format for storing messages. I will not go into the configuration of LMTP in the context of this basic configuration.

Check and reload

After changing the main.cf, Postfix has to reload the configuration. This is done with the command:

postfix reload

This means that Postfix reads its configuration again. Connections that are currently in place at this point in time are not interrupted, as this is not a complete restart of all Postfix processes. A complete stop of Postfix works with postfix stop. Postfix can then be started again with postfix start. However, a complete stop is not required for simple changes to main.cf.

All settings that apply to Postfix can also be viewed using the postconf command. postconf -n shows all configuration parameters that have been set in main.cf. A simple postconf without parameters shows all parameters, regardless of whether they were set in main.cf or whether they are set to their default values:

postconf -n

User, group and paths

In case Postfix should not start expecting again with this configuration file. Could this be because the Postfix does not know under which unprivileged user it should start and under which path the queue directory and the binaries belonging to Postfix are located. This could be in the log file e.g. B. express it like this:

fatal: file /etc/postfix/main.cf: parameter mail_owner: unknown user name value: postfix

Postfix uses default values ​​for these parameters that do not necessarily have to be correct on your system. If this is the case, you have to enter some additional values ​​in your main.cf. The following is an example of these values, which is correct on an OpenBSD system:

mail_owner = _postfix
setgid_group = _postdrop
command_directory = / usr / local / sbin
daemon_directory = / usr / local / libexec / postfix
queue_directory = / var / spool / postfix
sendmail_path = / usr / local / sbin / sendmail
newaliases_path = / usr / local / sbin / newaliases
mailq_path = / usr / local / sbin / mailq

The Postfix package on your system may contain an example main.cf from which you can then often use the values ​​that are valid on your system

Lookup tables

How does the server actually know which mail users are on the system? Quite simply, every user created on the system is automatically also a mail user. This also defines which mail addresses can precede the domain part. So if there is a user with the user name "Heinrich" and mydestination is set to example.net, example.org, then there are automatically the two mail addresses [email protected] and [email protected]

Sometimes you want to have a different name for the email address than the user name of the account or there should be several email addresses for one user. This wish can be fulfilled through aliases.

Aliases are additional mail names for user accounts. Aliases are listed in a separate file. This file is in the format alias: username. E.g .:

info: Heinrich
heinrich.klein: heinrich
root: mirijam
postmaster: mirijam
mirijam.mueller: mirijam

In this case there are users heinrich and mirijam. The addresses info @ and heinrich.klein @ are forwarded to the user account heinrich. The addresses root @, postmaster @ and mirijam.mueller @ are forwarded to the user account mirijam. External addresses, other aliases, or multiple addresses can also be listed as destinations. An example:

postmaster: root
root: klaus
irene: [email protected]
support: klaus, hans

In this case mail to postmaster @ will be forwarded to root, but mail to root @ will be forwarded to klaus. Ultimately, mails to postmaster @ end up with klaus. Mails to irene @ are forwarded to an external address, mails to support @ are forwarded to both klaus and hans. So support @ is a distribution list.

Such external lists that are processed by Postfix are called lookup tables. However, Postfix does not use these text files directly. Instead, the text files must first be converted into a database file, which Postfix then uses. The command with which the alias file is converted into a database is called postalias. There is also the Sendmail command newaliases. This is also understood by Postfix (Postfix tries to remain as compatible as possible with Sendmail).

So that the alias database is also used, you have to announce it in the main.cf for Postfix:

alias_database = hash: / etc / postfix / aliases
alias_maps = $ alias_database

With alias_database and / or alias_maps you set the path to the alias file. The prefix hash: indicates the database type. Hash is the default type on most systems. The database types available on the system can be viewed with postconf -m.

Why are there 2 parameters, both alias_maps and alias_database? This is related to Postfix's Sendmail compatibility. The alias_database file is created with the sendmail command newaliases. alias_maps is generated with the postalias command and can include not only local files but also other non-local data sources. Sendmail or newaliases cannot do this.

After the file has been created and entered in the main.cf, the file must also be created as a database. To do this, simply pass the file name to the postalias command. So assuming you are currently in the / etc / postfix directory, you can just type:

postalias aliases

This then creates the database file aliases.db. Please note that the file has the extension .db, but this extension is not included in the configuration of the main.cf. In the main.cf the file is still as / etc / postfix / aliases. postalias creates the file without further specification in the standard database format of the system (usually hash). If you want to specify a special database format, the following syntax can be used:

postalias btree: aliases

This will create the database file in btree instead of hash format.

If you make changes to the original text file, the database file must of course also be recreated with postalias every time. A reload of the postfix configuration using postfix reload is not necessary after changing the aliases. Postfix automatically detects that the alias database has been changed.

Here again a new main.cf as an example for some of the additional parameters you have learned about:

# Who am I and for which domains am I responsible
myhostname = mail.example.com
mydomain = example.com
mydestination = $ myhostname, $ mydomain
localhost. $ mydomain, localhost, example.net

# Who can relay mail
mynetworks =,,

# Where do locally stored mails end up?
home_mailbox = maildir /

# Aliases
alias_database = hash: / etc / postfix / aliases
alias_maps = $ alias_database

Email and DNS

From what has been explained above, it can also be seen that email is highly dependent on DNS, the Domain Name System. So that a mail server can receive emails for a domain, an MX entry must be stored in the DNS for this domain. It is also possible to create multiple MX entries for one domain. A priority must be given. This priority is given as a number, the smaller the number, the higher the priority.

If another mail server wants to deliver mail to a domain, it asks for the MX entries. If there are several MX entries, the mail server should first try to deliver the mails to the entry with the highest priority. Only if this does not work does it contact the mail server with the next higher priority instead. This is intended to increase reliability and failure safety if the primary mail server cannot be reached. Such downstream mail servers are therefore also referred to as backup MX.


Postfix sends its log messages to the system's syslog service in the "mail" facility. Check the configuration of your syslog service to which file messages from the "mail" facility are written. Often this is /var/log/mail.log. The log messages are often helpful in the event of problems.

In Germany, for reasons of data protection, there may be legal or, depending on the company, operational regulations that prohibit the storage of mail server logs for too long or even generally prohibit the storage of certain log information, such as recipient address, destination address and time. In any case, inquire beforehand which regulations apply to you.

Postfix configuration part II


Kyle D. Dent: Postfix, A Secure and Easy-to-Manage MTA for Unix, O'Reilly Publishing 2004.

Tobias Wassermann: Postfix ge-packed, MITP Verlag, 2006.

René Maroufi, lecturer (at) maruweb.de