What is postfix linux

The Postfix Home Page

All programmers are optimists — Frederick P. Brooks, Jr.

First of all, thank you for your interest in the Postfix project.

What is Postfix? It is Wietse Venema’s mail server that started life at IBM research as an alternative to the widely-used Sendmail program. Now at Google, Wietse continues to support Postfix.

Postfix attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.

As of July 2015, all supported Postfix releases have new TLS default settings that no longer enable export-grade ciphers, and no longer enable the SSLv2 and SSLv3 protocols. These ciphers and protocols have little if any legitimate use today, and have instead become a vehicle for downgrade attacks. See the announcement for more.

Logjam Attack: this has mostly the same countermeasure as FREAK: disable EXPORT ciphers on the SMTP server side, as described under the next bullet.

FREAK Attack: To protect vulnerable clients execute as root «postconf smtpd_tls_exclude_ciphers=EXPORT; postfix reload«. This command removes EXPORT ciphers with opportunistic as well as mandatory TLS. The impact of this attack was already low because each Postfix SMTP server process computes its own own «ephemeral» RSA key and terminates after a limited time.

GHOST Attack: Postfix does not call gethostbyname() since 2005. There is no Postfix code that invokes this function unless Postfix is specifically built for operating systems from more than 10 years ago (this requires the compile-time option «-DNO_IPV6«).

About this website

This website has information about the Postfix source code distribution. Built from source code, Postfix can run on UNIX-like systems including AIX, BSD, HP-UX, Linux, MacOS X, Solaris, and more.

Postfix is also distributed as ready-to-run code by operating system vendors, appliance vendors, and other providers. Their versions may have small differences with the software that is described on this website.

Источник

Postfix

attempts to be fast, easy to administer, and secure, while at the same time being sendmail compatible enough to not upset existing users. Thus, the outside has a sendmail-ish flavor, but the inside is completely different.

This article builds upon Mail server. The goal of this article is to setup Postfix and explain what the basic configuration files do. There are instructions for setting up local system user-only delivery and a link to a guide for virtual user delivery.

Contents

Installation

Configuration

See Postfix Basic Configuration. Configuration files are in /etc/postfix by default. The two most important files are:

• master.cf , defines what Postfix services are enabled and how clients connect to them, see master(5)
• main.cf , the main configuration file, see postconf(5)

Configuration changes need a postfix.service reload in order to take effect.

Aliases

You can specify aliases (also known as forwarders) in /etc/postfix/aliases .

You should map all mail addressed to root to another account since it is not a good idea to read mail as root.

Uncomment the following line, and change you to a real account.

Once you have finished editing /etc/postfix/aliases you must run the postalias command:

For later changes you can use:

/.forward , e.g. /root/.forward for root. Specify the user to whom root mail should be forwarded, e.g. user@localhost.

Local mail

To only deliver mail to local system users (that are in /etc/passwd ) update /etc/postfix/main.cf to reflect the following configuration. Uncomment, change, or add the following lines:

All other settings may remain unchanged. After setting up the above configuration file, you may wish to set up some #Aliases and then #Start Postfix.

Virtual mail

Virtual mail is mail that does not map to a user account ( /etc/passwd ).

Check configuration

Run the postfix check command. It should output anything that you might have done wrong in a config file.

To see all of your configs, type postconf . To see how you differ from the defaults, try postconf -n .

Start Postfix

For more information, see Postfix TLS Support.

Secure SMTP (sending)

By default, Postfix/sendmail will not send email encrypted to other SMTP servers. To use TLS when available, add the following line to main.cf :

To enforce TLS (and fail when the remote server does not support it), change may to encrypt . Note, however, that this violates RFC:2487 if the SMTP server is publicly referenced.

Secure SMTP (receiving)

By default, Postfix will not accept secure mail.

You need to obtain a certificate. Point Postfix to your TLS certificates by adding the following lines to main.cf :

There are two ways to accept secure mail. STARTTLS over SMTP (port 587) and SMTPS (port 465). The latter was previously deprecated but was reinstated by RFC:8314.

To enable STARTTLS over SMTP (port 587), uncomment the following lines in master.cf :

The smtpd_*_restrictions options remain commented because $mua_*_restrictions are not defined in main.cf by default. If you do decide to set any of $mua_*_restrictions , uncomment those lines too.

To enable SMTPS (port 465), uncomment the following lines in master.cf :

The rationale surrounding the $smtpd_*_restrictions lines is the same as above.

Tips and tricks

Blacklist incoming emails

Manually blacklisting incoming emails by sender address can easily be done with Postfix.

Create and open /etc/postfix/blacklist_incoming file and append sender email address:

Then use the postmap command to create a database:

Add the following code before the first permit rule in main.cf :

Hide the sender’s IP and user agent in the Received header

This is a privacy concern mostly, if you use Thunderbird and send an email. The received header will contain your LAN and WAN IP and info about the email client you used. (Original source: AskUbuntu) What we want to do is remove the Received header from outgoing emails. This can be done by the following steps:

Add the following line to main.cf :

Create /etc/postfix/smtp_header_checks with this content:

Postfix in a chroot jail

Postfix is not put in a chroot jail by default. The Postfix documentation [1] provides details about how to accomplish such a jail. The steps are outlined below and are based on the chroot-setup script provided in the Postfix source code.

First, go into the master.cf file in the directory /etc/postfix and change all the chroot entries to ‘yes’ (y) except for the services qmgr , proxymap , proxywrite , local , and virtual

Second, create two functions that will help us later with copying files over into the chroot jail (see last step)

Next, make the new directories for the jail:

Find the localtime file

Copy localtime and some other system files into the chroot’s etc

Make sure resolv.conf is owned by root:

Copy required libraries into the chroot using the previously created function cond_copy

And do not forget to reload Postfix.

DANE (DNSSEC)

Resource Record

DANE supports several types of records, however not all of them are suitable in Postfix.

Certificate usage 0 is unsupported, 1 is mapped to 3 and 2 is optional, thus it is recommendet to publish a «3» record. More on Resource Records.

Configuration

This article or section needs expansion.

Opportunistic DANE is configured this way:

To use per-domain policies, e.g. opportunistic DANE for example.org and mandatory DANE for example.com, use something like this:

Full documentation is found here.

Extras

• PostfixAdmin — A web-based administrative interface for Postfix.

http://postfixadmin.sourceforge.net/ || postfixadmin

Postgrey

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Postgrey can be used to enable greylisting for a Postfix mail server.

Installation

Install the postgrey package. To get it running quickly edit the Postfix configuration file and add these lines:

Then start/enable the postgrey service. Afterwards, reload the postfix service. Now greylisting should be enabled.

Configuration

Configuration is done via editing the postgrey.service file. First copy it over to edit it.

Whitelisting

To add automatic whitelisting (successful deliveries are whitelisted and do not have to wait any more), you could add the —auto-whitelist-clients=N option and replace N by a suitably small number (or leave it at its default of 5).

. actually, the preferred method should be the override:

To add your own list of whitelisted clients in addition to the default ones, create the file /etc/postfix/whitelist_clients.local and enter one host or domain per line, then restart postgrey.service so the changes take effect.

Troubleshooting

If you specify —unix=/path/to/socket and the socket file is not created ensure you have removed the default —inet=127.0.0.1:10030 from the service file.

For a full documentation of possible options see perldoc postgrey .

SpamAssassin

This section describes how to integrate SpamAssassin.

SpamAssassin stand-alone generic setup

Edit /etc/postfix/master.cf and add the content filter under smtp.

Also add the following service entry for SpamAssassin

Now you can start and enable spamassassin.service .

SpamAssassin combined with Dovecot LDA / Sieve (Mailfiltering)

Set up LDA and the Sieve-Plugin as described in Dovecot#Sieve. But ignore the last line mailbox_command. .

Instead add a pipe in /etc/postfix/master.cf :

And activate it in /etc/postfix/main.cf :

Alternately, if you do not want to use virtual transports you can use. mailbox_command . This runs with the local user and group, whereas the pipe runs with with the specified user using the user setting.

SpamAssassin combined with Dovecot LMTP / Sieve

Set up the LMTP and Sieve as described in Dovecot#Sieve.

Edit /etc/dovecot/conf.d/90-plugin.conf and add:

Create the directory and put spamassassin in as a binary that can be ran by dovecot:

Create a new file, /etc/dovecot/sieve.before.d/spamassassin.sieve which contains:

Compile the sieve rules spamassassin.svbin :

Rule-based mail processing

With policy services one can easily finetune Postfix’ behaviour of mail delivery. postfwd and policyd ( policyd-mysql AUR , policyd-pgsql AUR or policyd-sqlite AUR ) provide services to do so. This allows you to e.g. implement time-aware grey- and blacklisting of senders and receivers as well as SPF policy checking.

Policy services are standalone services and connected to Postfix like this:

Placing policy services at the end of the queue reduces load, as only legitimate mails are processed. Be sure to place it before the first permit statement to catch all incoming messages.

Sender Policy Framework

With spf-engine or python-postfix-policyd-spf

Edit /etc/python-policyd-spf/policyd-spf.conf to your needs. An extensively commented version can be found at /etc/python-policyd-spf/policyd-spf.conf.commented . Pay some extra attention to the HELO check policy, as standard settings strictly reject HELO failures.

In main.cf file, add a timeout for the policyd:

Then add a transport

Lastly you need to add the policyd to the smtpd_recipient_restrictions . To minimize load put it to the end of the restrictions but above any reject_rbl_client DNSBL line:

Now reload the postfix service.

You can test your setup with the following:

With postfix-policyd-spf-perl

Do the same process with postfix as with python-postfix-policyd-spf, but with the following differences:

Timeout for the policyd in main.cf file:

Add the policyd to the smtpd_recipient_restrictions :

Sender Rewriting Scheme

To use the Sender Rewriting Scheme with Postfix, install postsrsd AUR and adjust the settings:

Enable and start the daemon, making sure it runs after reboot as well. Then configure Postfix accordingly by tweaking the following lines:

Restart Postfix and start forwarding mail.

Troubleshooting

Warning: «database /etc/postfix/*.db is older than source file ..»

If you get one or both warnings with journalctl:

Then you can fix it by using these commands, depending on the messages you get:

Host or domain name not found. Name service error for name=.

If you get the following warning with journalctl:

Источник

Postfix Basic Configuration

Introduction

Postfix has several hundred configuration parameters that are controlled via the main.cf file. Fortunately, all parameters have sensible default values. In many cases, you need to configure only two or three parameters before you can start to play with the mail system. Here’s a quick introduction to the syntax:

The text below assumes that you already have Postfix installed on the system, either by compiling the source code yourself (as described in the INSTALL file) or by installing an already compiled version.

This document covers basic Postfix configuration. Information about how to configure Postfix for specific applications such as mailhub, firewall or dial-up client can be found in the STANDARD_CONFIGURATION_README file. But don’t go there until you already have covered the material presented below.

The first parameters of interest specify the machine’s identity and role in the network.

The default values for many other configuration parameters are derived from just these.

The next parameter of interest controls the amount of mail sent to the local postmaster:

Be sure to set the following correctly if you’re behind a proxy or network address translator, and you are running a backup MX host for some other domain:

Postfix daemon processes run in the background, and log problems and normal activity to the syslog daemon. Here are a few things that you need to be aware of:

If your machine has unusual security requirements you may want to run Postfix daemon processes inside a chroot environment.

If you run Postfix on a virtual network interface, or if your machine runs other mailers on virtual interfaces, you’ll have to look at the other parameters listed here as well:

Postfix configuration files

By default, Postfix configuration files are in /etc/postfix. The two most important files are main.cf and master.cf; these files must be owned by root. Giving someone else write permission to main.cf or master.cf (or to their parent directories) means giving root privileges to that person.

In /etc/postfix/main.cf you will have to set up a minimal number of configuration parameters. Postfix configuration parameters resemble shell variables, with two important differences: the first one is that Postfix does not know about quotes like the UNIX shell does.

You specify a configuration parameter as:

and you use it by putting a «$» character in front of its name:

You can use $parameter before it is given a value (that is the second main difference with UNIX shell variables). The Postfix configuration language uses lazy evaluation, and does not look at a parameter value until it is needed at runtime.

Postfix uses database files for access control, address rewriting and other purposes. The DATABASE_README file gives an introduction to how Postfix works with Berkeley DB, LDAP or SQL and other types. Here is a common example of how Postfix invokes a database:

Whenever you make a change to the main.cf or master.cf file, execute the following command as root in order to refresh a running mail system:

What domain name to use in outbound mail

The myorigin parameter specifies the domain that appears in mail that is posted on this machine. The default is to use the local machine name, $myhostname, which defaults to the name of the machine. Unless you are running a really small site, you probably want to change that into $mydomain, which defaults to the parent domain of the machine name.

For the sake of consistency between sender and recipient addresses, myorigin also specifies the domain name that is appended to an unqualified recipient address.

Examples (specify only one of the following):

What domains to receive mail for

The mydestination parameter specifies what domains this machine will deliver locally, instead of forwarding to another machine. The default is to receive mail for the machine itself. See the VIRTUAL_README file for how to configure Postfix for hosted domains.

You can specify zero or more domain names, «/file/name» patterns and/or «type:table» lookup tables (such as hash:, btree:, nis:, ldap:, or mysql:), separated by whitespace and/or commas. A «/file/name» pattern is replaced by its contents; «type:table» requests that a table lookup is done and merely tests for existence: the lookup result is ignored.

IMPORTANT: If your machine is a mail server for its entire domain, you must list $mydomain as well.

Example 1: default setting.

Example 2: domain-wide mail server.

Example 3: host with multiple DNS A records.

Caution: in order to avoid mail delivery loops, you must list all hostnames of the machine, including $myhostname, and localhost.$mydomain.

What clients to relay mail from

By default, Postfix will forward mail from clients in authorized network blocks to any destination. Authorized networks are defined with the mynetworks configuration parameter. The current default is to authorize the local machine only. Prior to Postfix 3.0, the default was to authorize all clients in the IP subnetworks that the local machine is attached to.

Postfix can also be configured to relay mail from «mobile» clients that send mail from outside an authorized network block. This is explained in the SASL_README and TLS_README documents.

IMPORTANT: If your machine is connected to a wide area network then the «mynetworks_style = host» setting may be too friendly.

Examples (specify only one of the following):

You can specify the trusted networks in the main.cf file, or you can let Postfix do the work for you. The default is to let Postfix do the work. The result depends on the mynetworks_style parameter value.

Specify «mynetworks_style = host» when Postfix should forward mail from only the local machine.

Specify «mynetworks_style = subnet» (the default) when Postfix should forward mail from SMTP clients in the same IP subnetworks as the local machine. On Linux, this works correctly only with interfaces specified with the «ifconfig» command.

Specify «mynetworks_style = class» when Postfix should forward mail from SMTP clients in the same IP class A/B/C networks as the local machine. Don’t do this with a dialup site — it would cause Postfix to «trust» your entire provider’s network. Instead, specify an explicit mynetworks list by hand, as described below.

Alternatively, you can specify the mynetworks list by hand, in which case Postfix ignores the mynetworks_style setting. To specify the list of trusted networks by hand, specify network blocks in CIDR (network/mask) notation, for example:

You can also specify the absolute pathname of a pattern file instead of listing the patterns in the main.cf file.

What destinations to relay mail to

By default, Postfix will forward mail from strangers (clients outside authorized networks) to authorized remote destinations only. Authorized remote destinations are defined with the relay_domains configuration parameter. The default is to authorize all domains (and subdomains) of the domains listed with the mydestination parameter.

Examples (specify only one of the following):

What delivery method: direct or indirect

By default, Postfix tries to deliver mail directly to the Internet. Depending on your local conditions this may not be possible or desirable. For example, your system may be turned off outside office hours, it may be behind a firewall, or it may be connected via a provider who does not allow direct mail to the Internet. In those cases you need to configure Postfix to deliver mail indirectly via a relay host.

Examples (specify only one of the following):

The form enclosed with [] eliminates DNS MX lookups. Don’t worry if you don’t know what that means. Just be sure to specify the [] around the mailhub hostname that your ISP gave to you, otherwise mail may be mis-delivered.

The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled and/or dial-up networks.

What trouble to report to the postmaster

You should set up a postmaster alias in the aliases(5) table that directs mail to a human person. The postmaster address is required to exist, so that people can report mail delivery problems. While you’re updating the aliases(5) table, be sure to direct mail for the super-user to a human person too.

Execute the command «newaliases» after changing the aliases file. Instead of /etc/aliases, your alias file may be located elsewhere. Use the command «postconf alias_maps» to find out.

The Postfix system reports problems to the postmaster alias. You may not be interested in all types of trouble reports, so this reporting mechanism is configurable. The default is to report only serious problems (resource, software) to postmaster:

The meaning of the classes is as follows:

bounce Inform the postmaster of undeliverable mail. Either send the postmaster a copy of undeliverable mail that is returned to the sender, or send a transcript of the SMTP session when Postfix rejected mail. For privacy reasons, the postmaster copy of undeliverable mail is truncated after the original message headers. This implies «2bounce» (see below). See also the luser_relay feature. The notification is sent to the address specified with the bounce_notice_recipient configuration parameter (default: postmaster). 2bounce When Postfix is unable to return undeliverable mail to the sender, send it to the postmaster instead (without truncating the message after the primary headers). The notification is sent to the address specified with the 2bounce_notice_recipient configuration parameter (default: postmaster). delay Inform the postmaster of delayed mail. In this case, the postmaster receives message headers only. The notification is sent to the address specified with the delay_notice_recipient configuration parameter (default: postmaster). policy Inform the postmaster of client requests that were rejected because of (UCE) policy restrictions. The postmaster receives a transcript of the SMTP session. The notification is sent to the address specified with the error_notice_recipient configuration parameter (default: postmaster). protocol Inform the postmaster of protocol errors (client or server side) or attempts by a client to execute unimplemented commands. The postmaster receives a transcript of the SMTP session. The notification is sent to the address specified with the error_notice_recipient configuration parameter (default: postmaster). resource Inform the postmaster of mail not delivered due to resource problems (for example, queue file write errors). The notification is sent to the address specified with the error_notice_recipient configuration parameter (default: postmaster). software Inform the postmaster of mail not delivered due to software problems. The notification is sent to the address specified with the error_notice_recipient configuration parameter (default: postmaster).

Proxy/NAT external network addresses

Some mail servers are connected to the Internet via a network address translator (NAT) or proxy. This means that systems on the Internet connect to the address of the NAT or proxy, instead of connecting to the network address of the mail server. The NAT or proxy forwards the connection to the network address of the mail server, but Postfix does not know this.

If you run a Postfix server behind a proxy or NAT, you need to configure the proxy_interfaces parameter and specify all the external proxy or NAT addresses that Postfix receives mail on. You may specify symbolic hostnames instead of network addresses.

IMPORTANT: You must specify your proxy/NAT external addresses when your system is a backup MX host for other domains, otherwise mail delivery loops will happen when the primary MX host is down.

Example: host behind NAT box running a backup MX host.

What you need to know about Postfix logging

Postfix daemon processes run in the background, and log problems and normal activity to the syslog daemon. The syslogd process sorts events by class and severity, and appends them to logfiles. The logging classes, levels and logfile names are usually specified in /etc/syslog.conf. At the very least you need something like:

After changing the syslog.conf file, send a «HUP» signal to the syslogd process.

IMPORTANT: many syslogd implementations will not create files. You must create files before (re)starting syslogd.

IMPORTANT: on Linux you need to put a «-» character before the pathname, e.g., -/var/log/maillog, otherwise the syslogd process will use more system resources than Postfix.

Hopefully, the number of problems will be small, but it is a good idea to run every night before the syslog files are rotated:

The first line (postfix check) causes Postfix to report file permission/ownership discrepancies.

The second line looks for problem reports from the mail software, and reports how effective the relay and junk mail access blocks are. This may produce a lot of output. You will want to apply some postprocessing to eliminate uninteresting information.

The DEBUG_README document describes the meaning of the «warning» etc. labels in Postfix logging.

Running Postfix daemon processes chrooted

Postfix daemon processes can be configured (via the master.cf file) to run in a chroot jail. The processes run at a fixed low privilege and with file system access limited to the Postfix queue directories (/var/spool/postfix). This provides a significant barrier against intrusion. The barrier is not impenetrable (chroot limits file system access only), but every little bit helps.

With the exception of Postfix daemons that deliver mail locally and/or that execute non-Postfix commands, every Postfix daemon can run chrooted.

Sites with high security requirements should consider to chroot all daemons that talk to the network: the smtp(8) and smtpd(8) processes, and perhaps also the lmtp(8) client. The author’s own porcupine.org mail server runs all daemons chrooted that can be chrooted.

The default /etc/postfix/master.cf file specifies that no Postfix daemon runs chrooted. In order to enable chroot operation, edit the file /etc/postfix/master.cf, and follow instructions in the file. When you’re finished, execute «postfix reload» to make the change effective.

Note that a chrooted daemon resolves all filenames relative to the Postfix queue directory (/var/spool/postfix). For successful use of a chroot jail, most UNIX systems require you to bring in some files or device nodes. The examples/chroot-setup directory in the source code distribution has a collection of scripts that help you set up Postfix chroot environments on different operating systems.

Additionally, you almost certainly need to configure syslogd so that it listens on a socket inside the Postfix queue directory. Examples of syslogd command line options that achieve this for specific systems:

FreeBSD: syslogd -l /var/spool/postfix/var/run/log

Linux, OpenBSD: syslogd -a /var/spool/postfix/dev/log

My own hostname

The myhostname parameter specifies the fully-qualified domain name of the machine running the Postfix system. $myhostname appears as the default value in many other Postfix configuration parameters.

By default, myhostname is set to the local machine name. If your local machine name is not in fully-qualified domain name form, or if you run Postfix on a virtual interface, you will have to specify the fully-qualified domain name that the mail system should use.

Alternatively, if you specify mydomain in main.cf, then Postfix will use its value to generate a fully-qualified default value for the myhostname parameter.

Examples (specify only one of the following):

My own domain name

The mydomain parameter specifies the parent domain of $myhostname. By default, it is derived from $myhostname by stripping off the first part (unless the result would be a top-level domain).

Conversely, if you specify mydomain in main.cf, then Postfix will use its value to generate a fully-qualified default value for the myhostname parameter.

Examples (specify only one of the following):

My own network addresses

The inet_interfaces parameter specifies all network interface addresses that the Postfix system should listen on; mail addressed to «user@[network address]» will be delivered locally, as if it is addressed to a domain listed in $mydestination.

You can override the inet_interfaces setting in the Postfix master.cf file by prepending an IP address to a server name.

The default is to listen on all active interfaces. If you run mailers on virtual interfaces, you will have to specify what interfaces to listen on.

IMPORTANT: If you run MTAs on virtual interfaces you must specify explicit inet_interfaces values for the MTA that receives mail for the machine itself: this MTA should never listen on the virtual interfaces or you would have a mailer loop when a virtual MTA is down.

Example: default setting.

Example: host running one or more virtual mailers. For each Postfix instance, specify only one of the following.

Note: you need to stop and start Postfix after changing this parameter.

Источник