Which port does Dovecot use

Mail server with postfix and dovecot

The configuration file ¶

Postfix is ​​essentially configured through the file. In general, the following rules must be observed:

  • All settings are specified according to the syntax. The specification of can also extend over several lines, whereby from the second line onwards all information must be indented (usually with four spaces).
  • If the value of a certain variable has been determined in this way, you can then "reuse" this value, i.e. assign it to another variable by using the syntax. In front of the name of the original variable, all you have to do is put a -sign, the new variable is then assigned the same value.
  • If an external list (“lookup table”) is to be assigned as a value, the syntax for this is as follows. With indicates the form in which the tabular data is available. The name of the external file from which the data is to be read is specified with.

A common data type for tabular data is. If this data type is specified, Postfix automatically appends the extension to the specified file name: This extension stands for the binary database format "Berkeley Database"; By using binary stored data, Postfix works faster than its predecessor. Such tabular data are important for alias definitions, for example.

After the initial configuration described in the previous section, the file has roughly the following content, which has only been changed at this point with regard to the comments:

# smtpd_banner specifies the text with which Postfix # presents itself to other MTAs: smtpd_banner = $ myhostname ESMTP $ mail_name (Debian / GNU) # mydomain should contain the name of your own domain: mydomain = example-one.de # myhostname should be as Value have the hostname of the server. # This can be displayed with the shell command hostnamectl # or adjusted with hostnamectl set-hostname.myhostname = $ mydomain # myorigin specifies the domain name for local e-mails that are sent without # explicit Domain information will be sent. myorigin should match # myhostname. The only entry in the / etc / mailname file should be the correct host name of the server! Myorigin = / etc / mailname # mydestination specifies the domain name for which incoming emails should be # saved in a local mailbox. # (Postfix is responsible for the domain (s) # specified here as the target domain for incoming emails) mydestination = $ mydomain, localhost # relayhost specifies domain names or IP addresses to which emails # that are not intended for a local delivery # are provided. To be on the safe side, email forwarding # ("relaying") to other hosts should be deactivated: relayhost = # mynetworks specifies the addresses from which emails may be sent without # authentication. Such # sending should only be allowed from the local network: mynetworks = 127.0.0.0 / 8 # biff is a service that informs local users about new mails. # Without linking local accounts to the mail accounts, this is # superfluous: biff = no # No size restrictions for local email and mailbox sizes: mailbox_size_limit = 0 # Enable email reception via all network interfaces: # (Changes to these parameters require a restart of Postfix!) inet_interfaces = ipv4 inet_protocols = ipv4 # No automatic domain completion of email addresses: # (This is at most the job of the mail clients) append_dot_mydomain = no # General parameters: recipient_delimiter = + readme_directory = no # Compatibility mode (standard): compatibility_level = 2 # Location of the alias File: alias_maps = hash: / etc / aliases alias_database = hash: / etc / aliases # TLS encryption parameters: smtpd_tls_cert_file = / etc / ssl / certs / ssl-cert-snakeoil.pem smtpd_tls_key_file = / etc / ssl -cert-snakeoil.key smtpd_use_tls = yes smtpd_tls_session_cache_database = btree: $ {data_directory} / smtpd_scache smtp_tls_session_cache_database = btree: $ {data_directory_authorized_works_authority = $ {data_directory

If changes are made to the configuration file (or in rare cases also the), the settings must be reloaded. Before reloading the configuration file (s) it is advisable to make sure that they do not contain any syntax errors:

# Syntax check for configuration files: postfix check # Reload mail server configurations: sudo systemctl reload postfix

For further settings, you can, for example, take a look at the extensively commented example file, which is stored under by default. This is recommended because the file provides a good overview of important setting options. An overview of all Setting options including short descriptions are available here.

The settings that are active by default in Postfix after a new installation can be displayed as follows:

# Show standard Postfix settings: postconf -d

Individual settings can also be made from a shell using; Postfix automatically takes changes into account. As soon as the basic settings have been made and the mail server is "in operation", it is advisable to only make changes step by step and test whether the mail server is still working properly (for example using tail) using possible warnings or error messages in the files ; with you get a list of all emails that should be sent, but (for whatever reason) could not be sent.

After a successful configuration of the mail server, a backup of the configuration files is recommended (for example using tar).

Alias ​​files

As already mentioned, there is a valid email address for each user account. Usually, however, you want to have email addresses for a domain that do not match the names of the user accounts; on the other hand, several email addresses should be possible for one user.

This is possible by using so-called alias files. By default, Postfix pays attention to the file when delivering emails to local accounts. In this alias file, new email names are defined line by line for existing user accounts, with the syntax being. As the following example shows, multiple redirects are also possible:

# / etc / aliasesmailer-daemon: postmasterpostmaster: rootwebmaster: rootwww: rootsecurity: root # forwarding to external address: root: [email protected]

These settings would mean that emails to would first be forwarded to the account, which in turn is defined as the alias for the account. Alias ​​names of this type can also be entered and linked to the account of a "normal" user. Likewise, several user names can be specified for an alias, separated by a comma and a space: Thus, for example, one could achieve that two users are notified of support requests at the same time.

In order to create a binary database that can be read by Postfix from this data, the following statement must be executed:

# Create / update alias database: sudo newaliases # Or: sudo postaliases aliases

The first instruction still exists for reasons of compatibility with the Postfix predecessor program; the second instruction works identically, but can be applied specifically to individual alias files and, if necessary, can also generate other database variants. Changes resulting from these two instructions are automatically communicated to Postfix (even during operation).

In the file, the variable specifies which alias files should be taken into account by Postfix. The setting specifies which alias files are to be generated or updated by calling.

Virtual domains

The variable specifies the domain (s) for which the mail server is the target address. In the example above, only a domain was specified, but several domains can also be specified, separated by a comma and a space, for example:

# Domain setting for a shared user: mydestination = localhost, example-one.de, example-two.de

In this case, all specified domains are regarded as synonyms: If there is an email address because a user name exists or an alias has been set up for, for example, emails that are written to are stored in the same place (by default in the file ). This can be useful if a domain has been reserved with different top-level domains (TLDs), for example, and both domains are configured in the same way and are managed by the same person.

However, if emails to and from two different people are intended, "virtual" domains must be used. In this case only contains the main domain of the mail server, for example. The other domain (s) are specified using the variable:

# Domain setting for different users: mydestination = localhost, example-one.devirtual_alias_domains = example-two.de, example-three.de

In this case, too, several (virtual) domains can be specified separated by commas and spaces. In order for Postfix to know which users the messages are intended for, “virtual aliases” must also be defined. This is done in a similar way to the normal alias definitions, with the difference that not only the alias name but also the associated domain must be specified.

# /etc/postfix/[email protected]@[email protected]@ Adresse.de

Instead of a user account, you can also specify an external email address for each individual email address; in this case, the mail is not stored locally in the user's mailbox, but forwarded to the external address.

Please note that with files like the no colon is provided as a separator, but a whitespace character (one or more spaces, or a tab character). The virtual alias file can be brought into a binary form using:

# Create / update virtual alias database: sudo postmap virtual

The file can then be supplemented with an entry for the lookup table created in this way:

# Location of the virtual alias file: virtual_alias_maps = hash: / etc / postfix / virtual

Finally, the configurations must also be reloaded. The "own" mail server is ready for use in its basic function, even if several domains are to be hosted on the server: Received emails are stored under and can be read there using mutt, for example; e-mails from the server can also be sent to external mail servers using other programs. One major disadvantage, however, remains: To read and write the emails, an SSH login must first be made on the server. To get around this, for example Dovecot can help out as an authentication service.

Mbox and Maildir, Virtual Mailboxes

With the previous settings, Postfix stores emails in files in mailboxes of the type. This means that the mails can only be delivered for existing user accounts, so that a separate account would have to be set up for each mail service user. This ailment can be remedied through so-called "virtual" mailboxes.

A second question is connected with the filing of the incoming emails: Should the emails be written in a single, possibly quite large (text) file, or should each email be stored individually in a directory?

  • The first variant, in which any number of emails can be written to a single file, is called; it is mostly used when an email client such as Thunderbird or mutt is configured as the transmission protocol.
  • In the second variant, each email is written individually in a. This configuration is usually used in combination with the transmission protocol.

Both and are widely used as mailbox options. The second variant, however, seems to be gaining more and more acceptance, as it enables easier synchronization in particular.

To use with Postfix instead of the basic setting, you can set the setting in the file (this setting then takes precedence over the standard set variable that refers to). You can also choose a different name, the only important thing is that a slash is placed at the end. Without any further settings, emails are saved as individual files in the directory.

If you want to manage the emails (either in or in the format) independently of the user accounts, a separate user must first be created to manage the virtual mailboxes:

# Set up user and group for virtual mailboxes: sudo groupadd -g 5000 vmail sudo useradd -g vmail -u 5000 -s / usr / bin / nologin vmail

Then it has to be changed or the following entries have to be added:

# Settings for the virtual mailboxes: virtual_uid_maps = static: 5000virtual_gid_maps = static: 5000 # Allocation of email addresses and mailboxes: virtual_mailbox_maps = hash: / etc / postfix / vmaps # The emails are stored in this directory by domain: virtual_mailbox_base = / var / vmail # These domains should be handled as virtual domains: virtual_mailbox_domains = example-two.de, example-three.de # Domains that are listed as virtual_mailbox_domains have # no "real" users assigned. Therefore, the domains # must be removed from the virtual_alias_domains: virtual_alias_domains =

The setting for causes the emails to be stored in directories of the type.

Now it has to be determined under which virtual user name the incoming emails are to be stored. Usually two different target email addresses also stand for two different addressees. Postfix therefore provides a mapping file that links each email address with a directory path relative to the base path of the virtual user accounts:

# File / etc / postfix / vmaps # Storage in mbox format: user1 @ example-one.deexample-one.de / user1user2 @ example-one.deexample-one.de / user2 # Storage in Maildir format: user3 @ example -two.deexample-two.de/user3/

As you can see, when assigning email addresses to mailboxes with virtual users, the decisive factor is whether the path ends with a slash or not.

Several emails can also be assigned to a virtual user. It is also possible to enter an email address without a preceding address name in order to add a "catch-all" mailbox: In this case, all emails that cannot be assigned are stored in the mailbox of the specified (virtual) user.

The file must in turn be converted into a binary database file using:

postmap / etc / postfix / virtual-mboxes

Finally, the directory and the individual domain directories etc. have to be created and the owner and group of these directories have to be adapted to:

# Set up storage directories for virtual domains: mkdir / var / vmail chown vmail: vmail / var / vmail mkdir / var / mail / example-one chown vmail: vmail / var / vmail / example-one # (...)

The directories for the virtual users of the individual domains are created automatically.