From b5896ba9f6047e7031e2bdee0622d543e11a6734 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Mon, 6 May 2024 03:46:30 +0200 Subject: Adding upstream version 3.4.23. Signed-off-by: Daniel Baumann --- proto/ADDRESS_CLASS_README.html | 279 + proto/ADDRESS_REWRITING_README.html | 1246 ++ proto/ADDRESS_VERIFICATION_README.html | 658 ++ proto/BACKSCATTER_README.html | 409 + proto/BASIC_CONFIGURATION_README.html | 681 ++ proto/BDAT_README.html | 178 + proto/BUILTIN_FILTER_README.html | 488 + proto/CDB_README.html | 109 + proto/COMPATIBILITY_README.html | 395 + proto/CONNECTION_CACHE_README.html | 308 + proto/CONTENT_INSPECTION_README.html | 92 + proto/DATABASE_README.html | 497 + proto/DB_README.html | 242 + proto/DEBUG_README.html | 597 + proto/DSN_README.html | 156 + proto/ETRN_README.html | 374 + proto/FILTER_README.html | 980 ++ proto/FORWARD_SECRECY_README.html | 717 ++ proto/INSTALL.html | 1672 +++ proto/IPV6_README.html | 387 + proto/LDAP_README.html | 628 + proto/LINUX_README.html | 104 + proto/LMDB_README.html | 417 + proto/LOCAL_RECIPIENT_README.html | 180 + proto/MAILDROP_README.html | 195 + proto/MAILLOG_README.html | 183 + proto/MEMCACHE_README.html | 76 + proto/MILTER_README.html | 951 ++ proto/MULTI_INSTANCE_README.html | 1274 +++ proto/MYSQL_README.html | 183 + proto/Makefile.in | 527 + proto/NFS_README.html | 137 + proto/OVERVIEW.html | 854 ++ proto/PACKAGE_README.html | 154 + proto/PCRE_README.html | 106 + proto/PGSQL_README.html | 170 + proto/POSTSCREEN_README.html | 1192 ++ proto/QSHAPE_README.html | 938 ++ proto/README | 34 + proto/RESTRICTION_CLASS_README.html | 239 + proto/SASL_README.html | 2258 ++++ proto/SCHEDULER_README.html | 1837 +++ proto/SMTPD_ACCESS_README.html | 438 + proto/SMTPD_POLICY_README.html | 811 ++ proto/SMTPD_PROXY_README.html | 411 + proto/SMTPUTF8_README.html | 399 + proto/SQLITE_README.html | 116 + proto/STANDARD_CONFIGURATION_README.html | 851 ++ proto/STRESS_README.html | 566 + proto/TLS_LEGACY_README.html | 1606 +++ proto/TLS_README.html | 3259 ++++++ proto/TUNING_README.html | 704 ++ proto/UUCP_README.html | 200 + proto/VERP_README.html | 289 + proto/VIRTUAL_README.html | 648 ++ proto/XCLIENT_README.html | 267 + proto/XFORWARD_README.html | 241 + proto/access | 478 + proto/aliases | 206 + proto/aliases0 | 38 + proto/bounce | 214 + proto/canonical | 273 + proto/cidr_table | 145 + proto/generic | 236 + proto/header_checks | 520 + proto/html2text.rc | 13 + proto/ldap_table | 723 ++ proto/lmdb_table | 119 + proto/manual-format | 21 + proto/master | 255 + proto/memcache_table | 236 + proto/mysql_table | 400 + proto/nisplus_table | 89 + proto/pcre_table | 210 + proto/pgsql_table | 318 + proto/postconf.html.epilog | 5 + proto/postconf.html.prolog | 105 + proto/postconf.man.epilog | 23 + proto/postconf.man.prolog | 85 + proto/postconf.proto | 17683 +++++++++++++++++++++++++++++ proto/postfix-wrapper | 290 + proto/regexp_table | 178 + proto/relocated | 163 + proto/socketmap_table | 96 + proto/sqlite_table | 261 + proto/stop | 1539 +++ proto/tcp_table | 108 + proto/transport | 289 + proto/virtual | 302 + 89 files changed, 59529 insertions(+) create mode 100644 proto/ADDRESS_CLASS_README.html create mode 100644 proto/ADDRESS_REWRITING_README.html create mode 100644 proto/ADDRESS_VERIFICATION_README.html create mode 100644 proto/BACKSCATTER_README.html create mode 100644 proto/BASIC_CONFIGURATION_README.html create mode 100644 proto/BDAT_README.html create mode 100644 proto/BUILTIN_FILTER_README.html create mode 100644 proto/CDB_README.html create mode 100644 proto/COMPATIBILITY_README.html create mode 100644 proto/CONNECTION_CACHE_README.html create mode 100644 proto/CONTENT_INSPECTION_README.html create mode 100644 proto/DATABASE_README.html create mode 100644 proto/DB_README.html create mode 100644 proto/DEBUG_README.html create mode 100644 proto/DSN_README.html create mode 100644 proto/ETRN_README.html create mode 100644 proto/FILTER_README.html create mode 100644 proto/FORWARD_SECRECY_README.html create mode 100644 proto/INSTALL.html create mode 100644 proto/IPV6_README.html create mode 100644 proto/LDAP_README.html create mode 100644 proto/LINUX_README.html create mode 100644 proto/LMDB_README.html create mode 100644 proto/LOCAL_RECIPIENT_README.html create mode 100644 proto/MAILDROP_README.html create mode 100644 proto/MAILLOG_README.html create mode 100644 proto/MEMCACHE_README.html create mode 100644 proto/MILTER_README.html create mode 100644 proto/MULTI_INSTANCE_README.html create mode 100644 proto/MYSQL_README.html create mode 100644 proto/Makefile.in create mode 100644 proto/NFS_README.html create mode 100644 proto/OVERVIEW.html create mode 100644 proto/PACKAGE_README.html create mode 100644 proto/PCRE_README.html create mode 100644 proto/PGSQL_README.html create mode 100644 proto/POSTSCREEN_README.html create mode 100644 proto/QSHAPE_README.html create mode 100644 proto/README create mode 100644 proto/RESTRICTION_CLASS_README.html create mode 100644 proto/SASL_README.html create mode 100644 proto/SCHEDULER_README.html create mode 100644 proto/SMTPD_ACCESS_README.html create mode 100644 proto/SMTPD_POLICY_README.html create mode 100644 proto/SMTPD_PROXY_README.html create mode 100644 proto/SMTPUTF8_README.html create mode 100644 proto/SQLITE_README.html create mode 100644 proto/STANDARD_CONFIGURATION_README.html create mode 100644 proto/STRESS_README.html create mode 100644 proto/TLS_LEGACY_README.html create mode 100644 proto/TLS_README.html create mode 100644 proto/TUNING_README.html create mode 100644 proto/UUCP_README.html create mode 100644 proto/VERP_README.html create mode 100644 proto/VIRTUAL_README.html create mode 100644 proto/XCLIENT_README.html create mode 100644 proto/XFORWARD_README.html create mode 100644 proto/access create mode 100644 proto/aliases create mode 100644 proto/aliases0 create mode 100644 proto/bounce create mode 100644 proto/canonical create mode 100644 proto/cidr_table create mode 100644 proto/generic create mode 100644 proto/header_checks create mode 100644 proto/html2text.rc create mode 100644 proto/ldap_table create mode 100644 proto/lmdb_table create mode 100644 proto/manual-format create mode 100644 proto/master create mode 100644 proto/memcache_table create mode 100644 proto/mysql_table create mode 100644 proto/nisplus_table create mode 100644 proto/pcre_table create mode 100644 proto/pgsql_table create mode 100644 proto/postconf.html.epilog create mode 100644 proto/postconf.html.prolog create mode 100644 proto/postconf.man.epilog create mode 100644 proto/postconf.man.prolog create mode 100644 proto/postconf.proto create mode 100644 proto/postfix-wrapper create mode 100644 proto/regexp_table create mode 100644 proto/relocated create mode 100644 proto/socketmap_table create mode 100644 proto/sqlite_table create mode 100644 proto/stop create mode 100644 proto/tcp_table create mode 100644 proto/transport create mode 100644 proto/virtual (limited to 'proto') diff --git a/proto/ADDRESS_CLASS_README.html b/proto/ADDRESS_CLASS_README.html new file mode 100644 index 0000000..ac9ac07 --- /dev/null +++ b/proto/ADDRESS_CLASS_README.html @@ -0,0 +1,279 @@ + + + + + + +Postfix Address Classes + + + + + + + +

Postfix Address Classes

+ +
+ +

Introduction

+ +

Postfix version 2.0 introduces the concept of address classes. +This is a way of grouping recipient addresses by their delivery +method. The idea comes from discussions with Victor Duchovni. +Although address classes introduced a few incompatibilities they +also made it possible to improve the handling of hosted domains +and of unknown recipients.

+ +

This document provides information on the following topics:

+ + + +

What are address classes good for?

+ +

Why should you care about address classes? This is how Postfix +decides what mail to accept, and how to deliver it. In other words, +address classes are very important for the operation of Postfix.

+ +

An address class is defined by three items.

+ + + +

What address classes does Postfix implement?

+ +

Initially the list of address classes is hard coded, but this +is meant to become extensible. The summary below describes the main +purpose of each class, and what the relevant configuration parameters +are.

+ +

The local domain class.

+ + + +

The virtual alias domain +class.

+ + + +

The virtual mailbox domain +class.

+ + + +

The relay domain class.

+ + + +

The default domain class. +

+ + + +

Improvements compared to Postfix +1.1

+ +

Postfix 2.0 address classes made the following improvements +possible over earlier Postfix versions:

+ + + +

Incompatibilities with Postfix 1.1

+ +

Postfix 2.0 address classes introduce a few incompatible changes +in documented behavior. In order to ease the transitions, new +parameters have default values that are backwards compatible.

+ + + + + + diff --git a/proto/ADDRESS_REWRITING_README.html b/proto/ADDRESS_REWRITING_README.html new file mode 100644 index 0000000..82f870c --- /dev/null +++ b/proto/ADDRESS_REWRITING_README.html @@ -0,0 +1,1246 @@ + + + + + + +Postfix Address Rewriting + + + + + + + +

Postfix +Address Rewriting

+ +
+ +

Postfix address rewriting purpose

+ +

Address rewriting is at the heart of the Postfix mail system. +Postfix rewrites addresses for many different purposes. Some are +merely cosmetic, and some are necessary to deliver correctly +formatted mail to the correct destination. Examples of +address rewriting in Postfix are:

+ + + +

Although Postfix currently has no address rewriting language, +it can do surprisingly powerful address manipulation via table +lookup. Postfix typically uses lookup tables with fixed strings +to map one address to one or multiple addresses, and typically uses +regular expressions to map multiple addresses to one or multiple +addresses. Fixed-string lookup tables may be in the form of local +files, or in the form of NIS, LDAP or SQL databases. The +DATABASE_README document gives an introduction to Postfix lookup +tables.

+ +

Topics covered in this document:

+ + + +

To rewrite message headers or not, or to label +as invalid

+ +

Postfix versions 2.1 and earlier always rewrite message header +addresses, and append Postfix's own domain information to addresses +that Postfix considers incomplete. While rewriting message header +addresses is OK for mail with a local origin, it is undesirable +for remote mail:

+ + + +

Postfix versions 2.2 give you the option to either not rewrite +message headers from remote SMTP clients at all, or to label +incomplete addresses in such message headers as invalid. Here is +how it works:

+ + + +

Postfix address rewriting overview

+ +

The figure below zooms in on those parts of Postfix that are most +involved with address rewriting activity. See the OVERVIEW document +for an overview of the complete Postfix architecture. Names followed +by a number are Postfix daemon programs, while unnumbered names +represent Postfix queues or internal sources of mail messages.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
trivial-
rewrite(8)
(std +form) 		trivial-
rewrite(8)
(resolve) +
^
| + 		|
v
+ +
^
| + 		|
v
+ +
smtpd(8) + >- + cleanup(8) -> + incoming -> + active -> + qmgr(8) -< + +smtp(8)
+qmqpd(8) lmtp(8)
pickup(8) + local(8) +
^
|
^
| + 		|
v
+ +
bounces
forwarding
notices		 deferred + +
+ +
+ +

The table below summarizes all Postfix address manipulations. +If you're reading this document for the first time, skip forward +to "Address +rewriting when mail is received". Once you've finished reading +the remainder of this document, the table will help you to quickly +find what you need.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Address manipulation Scope Daemon Global turn-on control Selective +turn-off control
Rewrite addresses to standard form + all mail trivial-
rewrite(8) 		append_at_myorigin, append_dot_mydomain, swap_bangpath, +allow_percent_hack local_header_rewrite_clients, +remote_header_rewrite_domain
Canonical address mapping all mail cleanup(8) canonical_maps + receive_override_options, local_header_rewrite_clients, +remote_header_rewrite_domain
Address masquerading all mail cleanup(8) masquerade_domains + receive_override_options, local_header_rewrite_clients, +remote_header_rewrite_domain
Automatic BCC recipients new mail cleanup(8) always_bcc, +sender_bcc_maps, recipient_bcc_maps receive_override_options +
Virtual aliasing all mail cleanup(8) virtual_alias_maps + receive_override_options
Resolve address to destination + all mail trivial-
rewrite(8) 		none none
Mail transport switch all mail trivial-
rewrite(8) 		+transport_maps none
Relocated users table all mail trivial-
rewrite(8) 		+relocated_maps none
Generic mapping table +outgoing SMTP mail smtp(8) smtp_generic_maps + none
Local alias database +local mail only local(8) alias_maps none +
Local per-user .forward files + local mail only local(8) forward_path + none
Local catch-all address local mail only local(8) luser_relay +none
+ +
+ +

Address rewriting when mail is received +

+ +

The cleanup(8) server receives mail from outside of Postfix as +well as mail from internal sources such as forwarded mail, +undeliverable mail that is bounced to the sender, and postmaster +notifications about problems with the mail system.

+ +

The cleanup(8) server transforms the sender, recipients and +message content into a standard form before writing it to an incoming +queue file. The server cleans up sender and recipient addresses in +message headers and in the envelope, adds missing message headers +such as From: or Date: that are required by mail standards, and +removes message headers such as Bcc: that should not be present. +The cleanup(8) server delegates the more complex address manipulations +to the trivial-rewrite(8) server as described later in this document. +

+ +

Address manipulations at this stage are:

+ + + +

Rewrite addresses to standard form

+ +

Before the cleanup(8) daemon runs an address through any address +mapping lookup table, it first rewrites the address to the standard +"user@fully.qualified.domain" form, by sending the address to the +trivial-rewrite(8) daemon. The purpose of rewriting to standard +form is to reduce the number of entries needed in lookup tables. +

+ +

The Postfix trivial-rewrite(8) daemon implements the following +hard-coded address manipulations:

+ +
+ +
+ +
Rewrite "@hosta,@hostb:user@site" to "user@site"
+ +

In case you wonder what this is, the address form above +is called a route address, and specifies that mail for "user@site" +be delivered via "hosta" and "hostb". Usage of this form has been +deprecated for a long time. Postfix has no ability to handle route +addresses, other than to strip off the route part.

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter, or if the +remote_header_rewrite_domain configuration parameter specifies a +non-empty value. To get the behavior before Postfix 2.2, specify +"local_header_rewrite_clients = static:all".

+ +
Rewrite "site!user" to "user@site"
+ +

This feature is controlled by the boolean swap_bangpath +parameter (default: yes). The purpose is to rewrite UUCP-style +addresses to domain style. This is useful only when you receive +mail via UUCP, but it probably does not hurt otherwise.

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter, or if the +remote_header_rewrite_domain configuration parameter specifies a +non-empty value. To get the behavior before Postfix 2.2, specify +"local_header_rewrite_clients = static:all".

+ +
Rewrite "user%domain" to "user@domain"
+ +

This feature is controlled by the boolean allow_percent_hack +parameter (default: yes). Typically, this is used in order to deal +with monstrosities such as "user%domain@otherdomain".

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter, or if the +remote_header_rewrite_domain configuration parameter specifies a +non-empty value. To get the behavior before Postfix 2.2, specify +"local_header_rewrite_clients = static:all".

+ +
+ +Rewrite "user" to "user@$myorigin"
+ +

This feature is controlled by the boolean append_at_myorigin +parameter (default: yes). You should never turn off this feature, +because a lot of Postfix components expect that all addresses have +the form "user@domain".

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter; otherwise they append the +domain name specified with the remote_header_rewrite_domain +configuration parameter, if one is specified. To get the behavior +before Postfix 2.2, specify "local_header_rewrite_clients = +static:all".

+ +

If your machine is not the main machine for $myorigin and you +wish to have some users delivered locally without going via that +main machine, make an entry in the virtual +alias table that redirects "user@$myorigin" to +"user@$myhostname". See also the "delivering some +users locally" section in the STANDARD_CONFIGURATION_README +document.

+ +
+ +Rewrite "user@host" to "user@host.$mydomain"
+ +

This feature is controlled by the boolean append_dot_mydomain +parameter (default: yes). The purpose is to get consistent treatment +of different forms of the same hostname.

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter; otherwise they append the +domain name specified with the remote_header_rewrite_domain +configuration parameter, if one is specified. To get the behavior +before Postfix 2.2, specify "local_header_rewrite_clients = +static:all".

+ +

Some will argue that rewriting "host" to "host.domain" +is bad. That is why it can be turned off. Others like the convenience +of having Postfix's own domain appended automatically.

+ +
Rewrite "user@site." to "user@site" (without the trailing dot).
+ +

A single trailing dot is silently removed. However, an +address that ends in multiple dots will be rejected as an invalid +address.

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter, or if the +remote_header_rewrite_domain configuration parameter specifies a +non-empty value. To get the behavior before Postfix 2.2, specify +"local_header_rewrite_clients = static:all".

+ +
+ +
+ +

Canonical address mapping

+ +

The cleanup(8) daemon uses the canonical(5) tables to rewrite +addresses in message envelopes and in message headers. By default +all header and envelope addresses are rewritten; this is controlled +with the canonical_classes configuration parameter.

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter, or if the +remote_header_rewrite_domain configuration parameter specifies a +non-empty value. To get the behavior before Postfix 2.2, specify +"local_header_rewrite_clients = static:all".

+ +

Address rewriting is +done for local and remote addresses. The mapping is useful to +replace login names by "Firstname.Lastname" style addresses, or to +clean up invalid domains in mail addresses produced by legacy mail +systems.

+ +

Canonical mapping is disabled by default. To enable, edit the +canonical_maps parameter in the main.cf file and specify one or +more lookup tables, separated by whitespace or commas.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    canonical_maps = hash:/etc/postfix/canonical
+
+/etc/postfix/canonical:
+    wietse        Wietse.Venema
+
+
+ +

For static mappings as shown above, lookup tables such as hash:, +ldap:, mysql: or pgsql: are sufficient. For dynamic mappings you +can use regular expression tables. This requires that you become +intimately familiar with the ideas expressed in regexp_table(5), +pcre_table(5) and canonical(5).

+ +

In addition to the canonical maps which are applied to both sender +and recipient addresses, you can specify canonical maps that are +applied only to sender addresses or to recipient addresses.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    sender_canonical_maps = hash:/etc/postfix/sender_canonical
+    recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
+
+
+ +

The sender and recipient canonical maps are applied before the +common canonical maps. The sender_canonical_classes and +recipient_canonical_classes parameters control what addresses are +subject to sender_canonical_maps and recipient_canonical_maps +mappings, respectively.

+ +

Sender-specific rewriting is useful when you want to rewrite +ugly sender addresses to pretty ones, and still want to be able to +send mail to the those ugly address without creating a mailer loop. +

+ +

Canonical mapping can be turned off selectively for mail received +by smtpd(8), qmqpd(8), or pickup(8), by overriding main.cf settings +in the master.cf file. This feature is available in Postfix version +2.1 and later.

+ +

Example:

+ +
+
+/etc/postfix/master.cf:
+    127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+        -o receive_override_options=no_address_mappings
+
+
+ +

Note: do not specify whitespace around the "=" here.

+ +

Address masquerading

+ +

Address masquerading is a method to hide hosts inside a domain +behind their mail gateway, and to make it appear as if the mail +comes from the gateway itself, instead of from individual machines. +

+ +

NOTE: Postfix versions 2.2 and later rewrite message headers +from remote SMTP clients only if the client matches the +local_header_rewrite_clients parameter, or if the +remote_header_rewrite_domain configuration parameter specifies a +non-empty value. To get the behavior before Postfix 2.2, specify +"local_header_rewrite_clients = static:all".

+ +

Address masquerading is disabled by default, and is implemented +by the cleanup(8) server. To enable, edit the masquerade_domains +parameter in the main.cf file and specify one or more domain names +separated by whitespace or commas. When Postfix tries to masquerade +a domain, it processes the list from left to right, and processing +stops at the first match.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    masquerade_domains = foo.example.com example.com
+
+
+ +

strips "any.thing.foo.example.com" to "foo.example.com", but +strips "any.thing.else.example.com" to "example.com".

+ +

A domain name prefixed with "!" means do not masquerade +this domain or its subdomains:

+ +
+
+/etc/postfix/main.cf:
+    masquerade_domains = !foo.example.com example.com
+
+
+ +

does not change "any.thing.foo.example.com" and "foo.example.com", +but strips "any.thing.else.example.com" to "example.com".

+ +

The masquerade_exceptions configuration parameter specifies +what user names should not be subjected to address masquerading. +Specify one or more user names separated by whitespace or commas. +

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    masquerade_exceptions = root
+
+
+ +

By default, Postfix makes no exceptions.

+ +

Subtle point: by default, address masquerading is applied only to +message headers and to envelope sender addresses, but not to envelope +recipients. This allows you to use address masquerading on a mail +gateway machine, while still being able to forward mail from outside +to users on individual machines.

+ +

In order to subject envelope recipient addresses to masquerading, +too, specify (Postfix version 1.1 and later):

+ +
+
+/etc/postfix/main.cf:
+    masquerade_classes = envelope_sender, envelope_recipient,
+        header_sender, header_recipient
+
+
+ +

If you rewrite the envelope recipient like this, Postfix will +no longer be able to send mail to individual machines.

+ +

Address masquerading can be turned off selectively for mail +received by smtpd(8), qmqpd(8), or pickup(8), by overriding main.cf +settings in the master.cf file. This feature is available in +Postfix version 2.1 and later.

+ +

Example:

+ +
+
+/etc/postfix/master.cf:
+    127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+        -o receive_override_options=no_address_mappings
+
+
+ +

Note: do not specify whitespace around the "=" here.

+ +

Automatic BCC recipients

+ +

After applying the canonical and masquerade mappings, the +cleanup(8) daemon can generate optional BCC (blind carbon-copy) +recipients. Postfix provides three mechanisms:

+ +
+ +
+ +
always_bcc = address
Deliver a copy of all mail to +the specified address. In Postfix versions before 2.1, this feature +is implemented by smtpd(8), qmqpd(8), or pickup(8).
+ +
sender_bcc_maps = type:table
Search the specified +"type:table" lookup table with the envelope sender address for an +automatic BCC address. This feature is available in Postfix 2.1 +and later.
+ +
recipient_bcc_maps = type:table
Search the specified +"type:table" lookup table with the envelope recipient address for +an automatic BCC address. This feature is available in Postfix 2.1 +and later.
+ +
+ +
+ +

Note: automatic BCC recipients are produced only for new mail. +To avoid mailer loops, automatic BCC recipients are not generated +for mail that Postfix forwards internally, nor for mail that Postfix +generates itself.

+ +

Automatic BCC recipients (including always_bcc) can be turned +off selectively for mail received by smtpd(8), qmqpd(8), or pickup(8), +by overriding main.cf settings in the master.cf file. This feature +is available in Postfix version 2.1 and later.

+ +

Example:

+ +
+
+/etc/postfix/master.cf:
+    127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+        -o receive_override_options=no_address_mappings
+
+
+ +

Note: do not specify whitespace around the "=" here.

+ +

Virtual aliasing

+ +

Before writing the recipients to the queue file, the cleanup(8) +daemon uses the optional virtual(5) alias tables to redirect mail +for recipients. The mapping affects only envelope recipient +addresses; it has no effect on message headers or envelope sender +addresses. Virtual alias lookups are useful to redirect mail for +virtual alias domains to real user mailboxes, and to redirect mail +for domains that no longer exist. Virtual alias lookups can also +be used to transform " Firstname.Lastname " back into UNIX login +names, although it seems that local aliases +may be a more appropriate vehicle. See the VIRTUAL_README document +for an overview of methods to host virtual domains with Postfix. +

+ +

Virtual aliasing is disabled by default. To enable, edit the +virtual_alias_maps parameter in the main.cf file and +specify one or more lookup tables, separated by whitespace or +commas.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    virtual_alias_maps = hash:/etc/postfix/virtual
+
+/etc/postfix/virtual:
+    Wietse.Venema        wietse
+
+
+ +

Addresses found in virtual alias maps are subjected to another +iteration of virtual aliasing, but are not subjected to canonical +mapping, in order to avoid loops.

+ +

For static mappings as shown above, lookup tables such as hash:, +ldap:, mysql: or pgsql: are sufficient. For dynamic mappings you +can use regular expression tables. This requires that you become +intimately familiar with the ideas expressed in regexp_table(5), +pcre_table(5) and virtual(5).

+ +

Virtual aliasing can be turned off selectively for mail received +by smtpd(8), qmqpd(8), or pickup(8), by overriding main.cf settings +in the master.cf file. This feature is available in Postfix version +2.1 and later.

+ +

Example:

+ +
+
+/etc/postfix/master.cf:
+    127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+        -o receive_override_options=no_address_mappings
+
+
+ +

Note: do not specify whitespace around the "=" here.

+ +

At this point the message is ready to be stored into the +Postfix incoming queue.

+ +

Address rewriting when mail is delivered

+ +

The Postfix queue manager sorts mail according to its destination +and gives it to Postfix delivery agents such as local(8), smtp(8), +or lmtp(8). Just like the cleanup(8) server, the Postfix queue +manager delegates the more complex address manipulations to the +trivial-rewrite(8) server.

+ +

Address manipulations at this stage are:

+ + + +

Each Postfix delivery agent tries to deliver the mail to its +destination, while encapsulating the sender, recipients, and message +content according to the rules of the SMTP, LMTP, etc. protocol. +When mail cannot be delivered, it is either returned to the sender +or moved to the deferred queue and tried again later.

+ +

Address manipulations when mail is delivered +via the smtp(8) delivery agent:

+ + + +

Address manipulations when mail is delivered +via the local(8) delivery agent:

+ + + +

The remainder of this document presents each address manipulation +step in more detail, with specific examples or with pointers to +documentation with examples.

+ +

Resolve address to destination

+ +

The Postfix qmgr(8) queue manager selects new mail from the +incoming queue or old mail from the deferred queue, and asks the +trivial-rewrite(8) address rewriting and resolving daemon where it +should be delivered.

+ +

As of version 2.0, Postfix distinguishes four major address +classes. Each class has its own list of domain names, and each +class has its own default delivery method, as shown in the table +below. See the ADDRESS_CLASS_README document for the fine details. +Postfix versions before 2.0 only distinguish between local delivery +and everything else.

+ +
+ + + + + + + + + + + + + + + + +
Destination domain list Default delivery method Availability +
$mydestination, $inet_interfaces, $proxy_interfaces $local_transport Postfix 1.0
$virtual_mailbox_domains $virtual_transport Postfix 2.0
$relay_domains $relay_transport Postfix +2.0
none $default_transport Postfix 1.0
+ +
+ +

Mail transport switch

+ +

Once the trivial-rewrite(8) daemon has determined a default +delivery method it searches the optional transport(5) table for +information that overrides the message destination and/or delivery +method. Typical use of the transport(5) table is to send mail to +a system +that is not connected to the Internet, or to use a special SMTP +client configuration for destinations that have special requirements. +See, for example, the STANDARD_CONFIGURATION_README and UUCP_README +documents, and the examples in the transport(5) manual page.

+ +

Transport table lookups are disabled by default. To enable, +edit the transport_maps parameter in the main.cf file and specify +one or more lookup tables, separated by whitespace or commas.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    transport_maps = hash:/etc/postfix/transport
+
+
+ +

Relocated users table

+ +

Next, the trivial-rewrite(8) address rewriting and resolving +daemon runs each recipient through the relocated(5) database. This +table provides information on how to reach users that no longer +have an account, or what to do with mail for entire domains that +no longer exist. When mail is sent to an address that is listed +in this table, the message is returned to the sender with an +informative message.

+ +

The relocated(5) database is searched after transport(5) +table lookups, in anticipation of transport(5) tables that +can replace one recipient address by a different one.

+ +

Lookups of relocated users are disabled by default. To enable, +edit the relocated_maps parameter in the main.cf file and specify +one or more lookup tables, separated by whitespace or commas.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    relocated_maps = hash:/etc/postfix/relocated
+
+/etc/postfix/relocated:
+    username@example.com      otheruser@elsewhere.tld
+
+
+ +

As of Postfix version 2, mail for a relocated user will be +rejected by the SMTP server with the reason "user has moved to +otheruser@elsewhere.tld". Older Postfix versions will receive the +mail first, and then return it to the sender as undeliverable, with +the same reason.

+ +

Generic mapping for outgoing SMTP mail

+ +

Some hosts have no valid Internet domain name, and instead use +a name such as localdomain.local. This can be a problem when +you want to send mail over the Internet, because many mail servers +reject mail addresses with invalid domain names.

+ +

With the smtp_generic_maps parameter you can specify generic(5) +lookup tables that replace local mail addresses by valid Internet +addresses when mail leaves the machine via SMTP. The generic(5) +mapping replaces envelope and header addresses, and is non-recursive. +It does not happen when you send mail between addresses on the +local machine.

+ +

This feature is available in Postfix version 2.2 and later.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_generic_maps = hash:/etc/postfix/generic
+
+/etc/postfix/generic:
+    his@localdomain.local		hisaccount@hisisp.example
+    her@localdomain.local		heraccount@herisp.example
+    @localdomain.local			hisaccount+local@hisisp.example
+
+
+ +

When mail is sent to a remote host via SMTP, this replaces +his@localdomain.local by his ISP mail address, replaces +her@localdomain.local by her ISP mail address, and replaces +other local addresses by his ISP account, with an address extension +of +local (this example assumes that the ISP supports "+" +style address extensions).

+ +

Local alias database

+ +

When mail is to be delivered locally, the local(8) delivery +agent runs each local recipient name through the aliases(5) database. +The mapping does not affect addresses in message headers. Local +aliases are typically used to implement distribution lists, or to +direct mail for standard aliases such as postmaster to real people. +The table can also be used to map "Firstname.Lastname" addresses +to login names.

+ +

Alias lookups are enabled by default. The default configuration +depends on the operating system environment, but it is typically +one of the following:

+ +
+
+/etc/postfix/main.cf:
+    alias_maps = hash:/etc/aliases
+    alias_maps = dbm:/etc/aliases, nis:mail.aliases
+
+
+ +

The pathname of the alias database file is controlled with the +alias_database configuration parameter. The value is system dependent. +Usually it is one of the following:

+ +
+
+/etc/postfix/main.cf:
+    alias_database = hash:/etc/aliases (4.4BSD, LINUX)
+    alias_database = dbm:/etc/aliases (4.3BSD, SYSV<4)
+    alias_database = dbm:/etc/mail/aliases (SYSV4)
+
+
+ +

An aliases(5) file can specify that mail should be delivered +to a local file, or to a command that receives the message in the +standard input stream. For security reasons, deliveries to command +and file destinations are performed with the rights of the alias +database owner. A default userid, default_privs, is used for +deliveries to commands or files in "root"-owned aliases.

+ +

Local per-user .forward files

+ +

With delivery via the local(8) delivery agent, users can control +their own mail delivery by specifying destinations in a file called +.forward in their home directories. The syntax of these files is +the same as with the local aliases(5) file, except that the left-hand +side of the alias (lookup key and colon) are not present.

+ +

Local catch-all address

+ +

When the local(8) delivery agent finds that a message recipient +does not exist, the message is normally returned to the sender ("user +unknown"). Sometimes it is desirable to forward mail for non-existing +recipients to another machine. For this purpose you can specify +an alternative destination with the luser_relay configuration +parameter.

+ +

Alternatively, mail for non-existent recipients can be delegated +to an entirely different message transport, as specified with the +fallback_transport configuration parameter. For details, see the +local(8) delivery agent documentation.

+ +

Note: if you use the luser_relay feature in order to receive +mail for non-UNIX accounts, then you must specify:

+ +
+
+/etc/postfix/main.cf:
+    local_recipient_maps =
+
+
+ +

(i.e. empty) in the main.cf file, otherwise the Postfix SMTP +server will reject mail for non-UNIX accounts with "User unknown +in local recipient table". See the LOCAL_RECIPIENT_README file +for more information on this. +

+ +

luser_relay can specify one address. It is subjected to "$name" +expansions. Examples:

+ +
+ +
+ +
$user@other.host
+ +

The bare username, without address extension, is prepended +to "@other.host". For example, mail for "username+foo" is sent to +"username@other.host".

+ +
$local@other.host
+ +

The entire original recipient localpart, including address +extension, is prepended to "@other.host". For example, mail for +"username+foo" is sent to "username+foo@other.host".

+ +
sysadmin+$user
+ +

The bare username, without address extension, is appended +to "sysadmin". For example, mail for "username+foo" is sent to +"sysadmin+username".

+ +
sysadmin+$local
+ +

The entire original recipient localpart, including address +extension, is appended to "sysadmin". For example, mail for +"username+foo" is sent to "sysadmin+username+foo".

+ +
+ +
+ +

Debugging your address manipulations

+ +

Postfix version 2.1 and later can +produce mail delivery reports for debugging purposes. These reports +not only show sender/recipient addresses after address rewriting +and alias expansion or forwarding, they also show information about +delivery to mailbox, delivery to non-Postfix command, responses +from remote SMTP servers, and so on.

+ +

Postfix can produce two types of mail delivery reports for +debugging:

+ + + +

These reports contain information that is generated by Postfix +delivery agents. Since these run as daemon processes and do not +interact with users directly, the result is sent as mail to the +sender of the test message. The format of these reports is practically +identical to that of ordinary non-delivery notifications.

+ +

As an example, below is the delivery report that is produced +with the command "sendmail -bv postfix-users@postfix.org". The +first part of the report contains human-readable text. In this +case, mail would be delivered via mail.cloud9.net, and the SMTP +server replies with "250 Ok". Other reports may show delivery +to mailbox, or delivery to non-Postfix command.

+ +
+
+Content-Description: Notification
+Content-Type: text/plain
+
+This is the mail system at host spike.porcupine.org.
+
+Enclosed is the mail delivery report that you requested.
+
+                        The mail system
+
+<postfix-users@postfix.org>: delivery via mail.cloud9.net[168.100.1.4]: 250 2.1.5 Ok
+
+
+ +

The second part of the report is in machine-readable form, and +includes the following information:

+ + + +

Some details depend on Postfix version. The example below is +for Postfix version 2.3 and later.

+ +
+
+Content-Description: Delivery report
+Content-Type: message/delivery-status
+
+Reporting-MTA: dns; spike.porcupine.org
+X-Postfix-Queue-ID: 84863BC0E5
+X-Postfix-Sender: rfc822; wietse@porcupine.org
+Arrival-Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+
+Final-Recipient: rfc822; postfix-users@postfix.org
+Action: deliverable
+Status: 2.1.5
+Remote-MTA: dns; mail.cloud9.net
+Diagnostic-Code: smtp; 250 2.1.5 Ok
+
+
+ +

The third part of the report contains the message that Postfix +would have delivered, including From: and To: message headers, so +that you can see any effects of address rewriting on those. Mail +submitted with "sendmail -bv" has no body content so none is shown +in the example below.

+ +
+
+Content-Description: Message
+Content-Type: message/rfc822
+
+Received: by spike.porcupine.org (Postfix, from userid 1001)
+        id 84863BC0E5; Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+Subject: probe
+To: postfix-users@postfix.org
+Message-Id: <20061126220101.84863BC0E5@spike.porcupine.org>
+Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+From: wietse@porcupine.org (Wietse Venema)
+
+
+ + + + diff --git a/proto/ADDRESS_VERIFICATION_README.html b/proto/ADDRESS_VERIFICATION_README.html new file mode 100644 index 0000000..ef1f6a7 --- /dev/null +++ b/proto/ADDRESS_VERIFICATION_README.html @@ -0,0 +1,658 @@ + + + + + + +Postfix Address Verification + + + + + + + +

Postfix Address Verification Howto

+ +
+ +

WARNING

+ +

Recipient address verification may cause an increased load on +down-stream servers in the case of a dictionary attack or a flood +of backscatter bounces. Sender address verification may cause your +site to be blacklisted by some providers. See also the "Limitations" section below for more.

+ +

What Postfix address verification can do for you

+ +

Address verification is a feature that allows the Postfix SMTP +server to block a sender (MAIL FROM) or recipient (RCPT TO) address +until the address has been verified to be deliverable.

+ +

The technique has obvious uses to reject junk mail +with an unreplyable sender address.

+ +

The technique is also useful to block mail for undeliverable +recipients, for example on a mail relay host that does not have a +list of all the valid recipient addresses. This prevents undeliverable +junk mail from entering the queue, so that Postfix doesn't have to +waste resources trying to send MAILER-DAEMON messages back.

+ +

This feature is available in Postfix version 2.1 and later.

+ +

Topics covered in this document:

+ + + +

How address verification works

+ +

A Postfix MTA verifies a sender or recipient address by probing +the preferred MTAs +for that address, without actually delivering mail. The preferred +MTAs could include the Postfix MTA itself, or some remote MTAs +(SMTP +interruptus). Probe messages are like normal mail, except that +they are never delivered, deferred or bounced; probe messages are +always discarded.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+   -> + probe
+ message 		-> + + Postfix
mail
queue
Internet -> + + Postfix
SMTP
server 		<-> + + Postfix
verify
server +
|
+ v
<- + probe
+ status 		<- + + Postfix
delivery
agents 		-> + Local
-> Remote
+   + ^
|
v
 
  + Address
verification
database
+ +
+ +

With Postfix address verification turned on, normal mail will +suffer only a short delay of up to 6 seconds while an address is +being verified for the first time. Once an address status is known, +the status is cached and Postfix replies immediately.

+ +

When verification takes too long the Postfix SMTP server defers +the sender or recipient address with a 450 reply. Normal mail +clients will connect again after some delay. The address verification +delay is configurable with the main.cf address_verify_poll_count +and address_verify_poll_delay parameters. See postconf(5) for +details.

+ +

Limitations of address verification

+ + + +

Recipient address verification

+ +

As mentioned earlier, recipient address verification is +useful to block mail for undeliverable recipients on a mail relay +host that does not have a list of all valid recipient addresses. +This can help to prevent the mail queue from filling up with +MAILER-DAEMON messages.

+ +

Recipient address verification is relatively straightforward +and there are no surprises. If a recipient probe fails, then Postfix +rejects mail for the recipient address. If a recipient probe +succeeds, then Postfix accepts mail for the recipient address. +However, recipient address verification probes can increase the +load on down-stream MTAs when you're being flooded by backscatter +bounces, or when some spammer is mounting a dictionary attack.

+ +

By default, address verification results are saved in a persistent database (Postfix version 2.7 and +later; with earlier versions, specify the database in main.cf as +described later). The persistent database helps to avoid probing +the same address repeatedly.

+ +
+
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions = 
+        permit_mynetworks
+        # reject_unauth_destination is not needed here if the mail
+        # relay policy is specified under smtpd_relay_restrictions
+        # (available with Postfix 2.10 and later).
+        reject_unauth_destination
+        ...
+        reject_unknown_recipient_domain
+        reject_unverified_recipient
+        ...
+    # Postfix 2.6 and later privacy feature.
+    # unverified_recipient_reject_reason = Address lookup failed
+
+    # Postfix 3.2 and earlier workaround.
+    # Do not set enable_original_recipient=no. This prevents Postfix
+    # from saving the recipient address verification result under
+    # the original address, when the address verification probe
+    # message goes through address aliasing or canonical mapping.
+
+
+ +

The "reject_unknown_recipient_domain" restriction blocks mail +for non-existent domains. Putting this before "reject_unverified_recipient" +avoids the overhead of generating unnecessary probe messages.

+ +

The unverified_recipient_reject_code parameter (default 450) +specifies the numerical Postfix SMTP server reply code when a +recipient address is known to +bounce. Change this setting into 550 when you trust Postfix's +judgments.

+ +

The following features are available in Postfix 2.6 and later. +

+ +

The unverified_recipient_defer_code parameter (default 450) +specifies the numerical Postfix SMTP server reply code when a +recipient address probe fails with some temporary error. Some sites +insist on changing this into 250. NOTE: This change turns MX servers +into backscatter sources when the load is high.

+ +

The unverified_recipient_reject_reason parameter (default: +empty) specifies fixed text that Postfix will send to remote SMTP +clients, instead of sending actual address verification details. +Do not specify the SMTP status code or enhanced status code.

+ +

The unverified_recipient_tempfail_action parameter (default: +defer_if_permit) specifies the Postfix SMTP server action when a +recipient address verification probe fails with some temporary +error.

+ +

Sender address verification for mail from frequently forged domains

+ +

Only for very small sites, it is relatively safe to turn on +sender address verification for specific domains that often appear +in forged email.

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sender_restrictions = hash:/etc/postfix/sender_access
+    unverified_sender_reject_code = 550
+    # Postfix 2.6 and later.
+    # unverified_sender_defer_code = 250
+
+    # Default setting for Postfix 2.7 and later.
+    # Note 1: Be sure to read the "Caching" section below!
+    # Note 2: Avoid hash files here. Use btree or lmdb instead.
+    address_verify_map = btree:/var/lib/postfix/verify
+
+    # Postfix 3.2 and earlier workaround.
+    # Do not set enable_original_recipient=no. This prevents Postfix
+    # from saving the sender address verification result under the
+    # original address, when the address verification probe message
+    # goes through address aliasing or canonical mapping.
+ 
+/etc/postfix/sender_access:
+    # Don't do this when you handle lots of email.
+    aol.com     reject_unverified_sender
+    hotmail.com reject_unverified_sender
+    bigfoot.com reject_unverified_sender
+    ... etcetera ...
+
+
+ +

At some point in cyberspace/time, a list of frequently forged +MAIL FROM domains could be found at +http://www.monkeys.com/anti-spam/filtering/sender-domain-validate.in.

+ +

NOTE: One of the first things you might want to do is to turn +on sender address verification for all your own domains.

+ +

Sender address verification for all +email

+ +

Unfortunately, sender address verification cannot simply be +turned on for all email - you are likely to lose legitimate mail +from mis-configured systems. You almost certainly will have to set +up white lists for specific addresses, or even for entire domains. +

+ +

To find out how sender address verification would affect your +mail, specify "warn_if_reject reject_unverified_sender" so that +you can see what mail would be blocked:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sender_restrictions = 
+        permit_mynetworks
+        ... 
+        check_sender_access hash:/etc/postfix/sender_access
+        reject_unknown_sender_domain
+        warn_if_reject reject_unverified_sender 
+        ...
+    # Postfix 2.6 and later.
+    # unverified_sender_reject_reason = Address verification failed
+
+    # Default setting for Postfix 2.7 and later.
+    # Note 1: Be sure to read the "Caching" section below!
+    # Note 2: Avoid hash files here. Use btree or lmdb instead.
+    address_verify_map = btree:/var/lib/postfix/verify
+
+
+ +

This is also a good way to populate your cache with address +verification results before you start to actually reject mail.

+ +

The sender_access restriction is needed to whitelist domains +or addresses that are known to be OK. Although Postfix will not +mark a known-to-be-good address as bad after a probe fails, it is +better to be safe than sorry.

+ +

NOTE: You will have to whitelist sites such as securityfocus.com +and other sites that operate mailing lists that use a different +sender address for each posting (VERP). Such addresses pollute +the address verification cache quickly, and generate unnecessary +sender verification probes.

+ +
+
+/etc/postfix/sender_access
+    securityfocus.com OK
+    ...
+
+
+ +

The "reject_unknown_sender_domain" restriction blocks mail from +non-existent domains. Putting this before "reject_unverified_sender" +avoids the overhead of generating unnecessary probe messages.

+ +

The unverified_sender_reject_code parameter (default 450) +specifies the numerical Postfix server reply code when a sender +address is known to +bounce. Change this setting into 550 when you trust Postfix's +judgments.

+ +

The following features are available in Postfix 2.6 and later. +

+ +

The unverified_sender_defer_code parameter (default 450) specifies +the numerical Postfix SMTP server reply code when a sender address +verification probe fails with some temporary error. Specify a valid +2xx or 4xx code.

+ +

The unverified_sender_reject_reason parameter (default: +empty) specifies fixed text that Postfix will send to remote SMTP +clients, instead of sending actual address verification details. +Do not specify the SMTP status code or enhanced status code.

+ +

The unverified_sender_tempfail_action parameter (default: +defer_if_permit) specifies the Postfix SMTP server action when a +sender address verification probe fails with some temporary error. +

+ +

Address verification database

+ +

To improve performance, the Postfix verify(8) daemon can save +address verification results to a persistent database. This is +enabled by default with Postfix 2.7 and later. The +address_verify_map (NOTE: singular) configuration parameter specifies +persistent storage for sender or recipient address verification +results. If you specify an empty value, all address verification +results are lost after "postfix reload" or "postfix stop".

+ +
+
+# Example 1: Default setting for Postfix 2.7 and later.
+# Note: avoid hash files here. Use btree or lmdb instead.
+/etc/postfix/main.cf:
+    address_verify_map = btree:$data_directory/verify_cache
+
+# Example 2: Shared persistent lmdb: cache (Postfix 2.11 or later).  
+# Disable automatic cache cleanup in all Postfix instances except
+# for one instance that will be responsible for cache cleanup.
+/etc/postfix/main.cf:
+    address_verify_map = lmdb:$data_directory/verify_cache
+    # address_verify_cache_cleanup_interval = 0
+
+# Example 3: Shared persistent btree: cache (Postfix 2.9 or later).  
+# Disable automatic cache cleanup in all Postfix instances except
+# for one instance that will be responsible for cache cleanup.
+/etc/postfix/main.cf:
+    address_verify_map = proxy:btree:$data_directory/verify_cache
+    # address_verify_cache_cleanup_interval = 0
+
+# Example 4: Shared memory cache (requires Postfix 2.9 or later).
+# Disable automatic cache cleanup in all Postfix instances.
+# See memcache_table(5) for details.
+/etc/postfix/main.cf:
+    address_verify_map = memcache:/etc/postfix/verify-memcache.cf
+    address_verify_cache_cleanup_interval = 0
+
+# Example 5: Default setting for Postfix 2.6 and earlier.
+# This uses non-persistent storage only.
+/etc/postfix/main.cf:
+    address_verify_map =
+
+
+ +

NOTE 1: The database file should be stored under a Postfix-owned +directory, such as $data_directory.

+ +
As of version 2.5, Postfix no longer uses root privileges +when opening this file. To maintain backwards compatibility, an +attempt to open the file under a non-Postfix directory is redirected +to the Postfix-owned data_directory, and a warning is logged. If +you wish to continue using a pre-existing database file, change its +file ownership to the account specified with the mail_owner parameter, +and either move the file to the data_directory, or move it to some +other Postfix-owned directory.
+ +

NOTE 2: Do not put this file in a file system that may run out +of space. When the address verification table gets corrupted the +world comes to an end and YOU will have to MANUALLY fix things as +described in the next section. Meanwhile, you will not receive mail +via SMTP.

+ +

NOTE 3: The verify(8) daemon will create a new database when +none exists. It will open or create the file before entering the +chroot jail.

+ +

Managing the address verification +database

+ +

The verify(8) manual page describes parameters that control how +long address verification results are cached before they need to +be refreshed, and how long results can remain "unrefreshed" before +they expire. Postfix uses different controls for positive results +(address was accepted) and for negative results (address was rejected, +or address verification failed for some other reason).

+ +

The verify(8) daemon will periodically remove expired entries +from the address verification database, and log the number of entries +retained and dropped (Postfix versions 2.7 and later). A cleanup +run is logged as "partial" when the daemon terminates early because +of "postfix reload, "postfix stop", or because the daemon received +no requests for $max_idle seconds. Postfix versions 2.6 and earlier +do not implement automatic address verification database cleanup. +There, the database is managed manually as described next.

+ +

When the address verification database file becomes too big, +or when it becomes corrupted, the solution is to manually rename +or delete (NOT: truncate) the file and run "postfix reload". The +verify(8) daemon will then create a new database file.

+ +

Controlling the routing of address +verification probes

+ +

By default, Postfix sends address verification probe messages +via the same route as regular mail, because that normally produces +the most accurate result. It's no good to verify a local address +by connecting to your own SMTP port; that just triggers all kinds +of mailer loop alarms. The same is true for any destination that +your machine is best MX host for: hidden domains, virtual domains, +etc.

+ +

However, some sites have a complex infrastructure where mail +is not sent directly to the Internet, but is instead given to an +intermediate relayhost. This is a problem for address verification, +because remote Internet addresses can be verified only when Postfix +can access remote destinations directly.

+ +

For this reason, Postfix allows you to override the routing +parameters when it delivers an address verification probe message. +

+ +

First, the address_verify_relayhost parameter allows you to +override the relayhost setting, and the address_verify_transport_maps +parameter allows you to override the transport_maps setting. +The address_verify_sender_dependent_relayhost_maps parameter +does the same for sender-dependent relayhost selection.

+ +

Second, each address class is given its own address verification +version of the message delivery transport, as shown in the table +below. Address classes are defined in the ADDRESS_CLASS_README +file.

+ +
+ + + + + + + + + + + + + + + + +
Domain list Regular transport Verify +transport
mydestination local_transport +address_verify_local_transport
virtual_alias_domains (not applicable) (not applicable)
virtual_mailbox_domains virtual_transport + address_verify_virtual_transport
relay_domains relay_transport +address_verify_relay_transport
(not applicable) default_transport +address_verify_default_transport
+ +
+ +

By default, the parameters that control delivery of address +probes have the same value as the parameters that control normal +mail delivery.

+ +

Forced probe routing examples

+ +

In a typical scenario one would override the relayhost setting +for address verification probes and leave everything else alone: +

+ +
+
+/etc/postfix/main.cf:
+    relayhost = $mydomain
+    address_verify_relayhost =
+    ...
+
+
+ +

Sites behind a network address translation box might have to +use a different SMTP client that sends the correct hostname +information:

+ +
+
+/etc/postfix/main.cf:
+    relayhost = $mydomain
+    address_verify_relayhost =
+    address_verify_default_transport = direct_smtp
+
+/etc/postfix/master.cf:
+    direct_smtp .. .. .. ..  .. .. .. .. .. smtp
+        -o smtp_helo_name=nat.box.tld
+
+
+ +

Limitations of forced probe routing

+ +

Inconsistencies can happen when probe messages don't follow +the same path as regular mail. For example, a message can be +accepted when it follows the regular route while an otherwise +identical probe message is rejected when it follows the forced +route. The opposite can happen, too, but is less likely.

+ + + + diff --git a/proto/BACKSCATTER_README.html b/proto/BACKSCATTER_README.html new file mode 100644 index 0000000..855e4aa --- /dev/null +++ b/proto/BACKSCATTER_README.html @@ -0,0 +1,409 @@ + + + + + + +Postfix Backscatter Howto + + + + + + + +

Postfix +Backscatter Howto

+ +
+ +

Overview

+ +

This document describes features that require Postfix version +2.0 or later.

+ +

Topics covered in this document:

+ + + +

The examples use Perl Compatible Regular Expressions (Postfix +pcre: tables), but also provide a translation to POSIX regular +expressions (Postfix regexp: tables). PCRE is preferred primarily +because the implementation is often faster.

+ +

What is backscatter mail?

+ +

When a spammer or worm sends mail with forged sender addresses, +innocent sites are flooded with undeliverable mail notifications. +This is called backscatter mail. With Postfix, you know that you're +a backscatter victim when your logfile goes on and on like this: +

+ +
+
+Dec  4 04:30:09 hostname postfix/smtpd[58549]: NOQUEUE: reject:
+RCPT from xxxxxxx[x.x.x.x]: 550 5.1.1 <yyyyyy@your.domain.here>:
+Recipient address rejected: User unknown; from=<>
+to=<yyyyyy@your.domain.here> proto=ESMTP helo=<zzzzzz>
+
+
+ +

What you see are lots of "user unknown" errors with "from=<>". +These are error reports from MAILER-DAEMONs elsewhere on the Internet, +about email that was sent with a false sender address in your domain. +

+ +

How do I block backscatter mail to random +recipient addresses?

+ +

If your machine receives backscatter mail to random addresses, +configure Postfix to reject all mail for non-existent recipients +as described in the LOCAL_RECIPIENT_README and +STANDARD_CONFIGURATION_README documentation.

+ +

If your machine runs Postfix 2.0 and earlier, disable the "pause +before reject" feature in the SMTP server. If your system is under +stress then it should not waste time.

+ +
+
+/etc/postfix/main.cf:
+    # Not needed with Postfix 2.1 and later.
+    smtpd_error_sleep_time = 0
+
+    # Not needed with Postfix 2.4 and later.
+    unknown_local_recipient_reject_code = 550
+
+
+ +

How do I block backscatter mail to real +recipient addresses?

+ +

When backscatter mail passes the "unknown recipient" barrier, +there still is no need to despair. Many mail systems are kind +enough to attach the message headers of the undeliverable mail in +the non-delivery notification. These message headers contain +information that you can use to recognize and block forged mail. +

+ +

Blocking backscatter mail with forged +mail server information

+ +

Although my email address is "wietse@porcupine.org", all my +mail systems announce themselves with the SMTP HELO command as +"hostname.porcupine.org". Thus, if returned mail has a Received: +message header like this:

+ +
+
+Received: from porcupine.org ...
+
+
+ +

Then I know that this is almost certainly forged mail (almost; +see next section for the fly in the ointment). +Mail that is really +sent by my systems looks like this:

+ +
+
+Received: from hostname.porcupine.org ...
+
+
+ +

For the same reason the following message headers are very likely +to be the result of forgery:

+ +
+
+Received: from host.example.com ([1.2.3.4] helo=porcupine.org) ...
+Received: from [1.2.3.4] (port=12345 helo=porcupine.org) ...
+Received: from host.example.com (HELO porcupine.org) ...
+Received: from host.example.com (EHLO porcupine.org) ...
+
+
+ +

Some forgeries show up in the way that a mail server reports +itself in Received: message headers. Keeping in mind that all my +systems have a mail server name of hostname.porcupine.org, +the following is definitely a forgery:

+ +
+
+Received: by porcupine.org ...
+Received: from host.example.com ( ... ) by porcupine.org ...
+
+
+ +

Another frequent sign of forgery is the Message-ID: header. My +systems produce a Message-ID: of +<stuff@hostname.porcupine.org>. The following +are forgeries, especially the first one: + +

+
+Message-ID: <1cb479435d8eb9.2beb1.qmail@porcupine.org>
+Message-ID: <yulszqocfzsficvzzju@porcupine.org>
+
+
+ +

To block such backscatter I use header_checks and body_checks +patterns like this:

+ +
+
+/etc/postfix/main.cf:
+    header_checks = pcre:/etc/postfix/header_checks
+    body_checks = pcre:/etc/postfix/body_checks
+
+/etc/postfix/header_checks:
+    # Do not indent the patterns between "if" and "endif".
+    if /^Received:/
+    /^Received: +from +(porcupine\.org) +/
+        reject forged client name in Received: header: $1
+    /^Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)(porcupine\.org)\)/
+        reject forged client name in Received: header: $2
+    /^Received:.* +by +(porcupine\.org)\b/
+        reject forged mail server name in Received: header: $1
+    endif
+    /^Message-ID:.* <!&!/ DUNNO
+    /^Message-ID:.*@(porcupine\.org)/
+	reject forged domain name in Message-ID: header: $1
+
+/etc/postfix/body_checks:
+    # Do not indent the patterns between "if" and "endif".
+    if /^[> ]*Received:/
+    /^[> ]*Received: +from +(porcupine\.org) /
+        reject forged client name in Received: header: $1
+    /^[> ]*Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)(porcupine\.org)\)/
+        reject forged client name in Received: header: $2
+    /^[> ]*Received:.* +by +(porcupine\.org)\b/
+        reject forged mail server name in Received: header: $1
+    endif
+    /^[> ]*Message-ID:.* <!&!/ DUNNO
+    /^[> ]*Message-ID:.*@(porcupine\.org)/
+	reject forged domain name in Message-ID: header: $1
+
+
+ +

Notes:

+ + + +

Caveats

+ + + +

Blocking backscatter mail with forged +sender information

+ +Like many people I still have a few email addresses in domains that +I used in the past. Mail for those addresses is forwarded to my +current address. Most of the backscatter mail that I get claims +to be sent from these addresses. Such mail is obviously forged +and is very easy to stop. + +
+
+/etc/postfix/main.cf:
+    header_checks = pcre:/etc/postfix/header_checks
+    body_checks = pcre:/etc/postfix/body_checks
+
+/etc/postfix/header_checks:
+    /^(From|Return-Path):.*\b(user@domain\.tld)\b/ 
+        reject forged sender address in $1: header: $2
+
+/etc/postfix/body_checks:
+    /^[> ]*(From|Return-Path):.*\b(user@domain\.tld)\b/ 
+        reject forged sender address in $1: header: $2
+
+
+ +

Notes:

+ + + +

Blocking backscatter mail with other +forged information

+ +

Another sign of forgery can be found in the IP address that is +recorded in Received: headers next to your HELO host or domain name. +This information must be used with care, though. Some mail servers +are behind a network address translator and never see the true +client IP address.

+ +

Blocking backscatter mail from virus +scanners

+ +

With all the easily recognizable forgeries eliminated, there +is one category of backscatter mail that remains, and that is +notifications from virus scanner software. Unfortunately, some +virus scanning software doesn't know that viruses forge sender +addresses. To make matters worse, the software also doesn't know +how to report a mail delivery problem, so that we cannot use the +above techniques to recognize forgeries.

+ +

Recognizing virus scanner mail is an error prone process, +because there is a lot of variation in report formats. The following +is only a small example of message header patterns. For a large +collection of header and body patterns that recognize virus +notification email, see http://www.dkuug.dk/keld/virus/ +or http://www.t29.dk/antiantivirus.txt.

+ +
+
+/etc/postfix/header_checks:
+    /^Subject: *Your email contains VIRUSES/ DISCARD virus notification
+    /^Content-Disposition:.*VIRUS1_DETECTED_AND_REMOVED/
+        DISCARD virus notification
+    /^Content-Disposition:.*VirusWarning.txt/ DISCARD virus notification
+
+
+ +

Note: these documents haven't been updated since 2004, so they +are useful only as a starting point.

+ +

A plea to virus or spam scanner operators: please do not make +the problem worse by sending return mail to forged sender addresses. +You're only harassing innocent people. If you must return mail to +the purported sender, please return the full message headers, so +that the sender can filter out the obvious forgeries.

+ + + + diff --git a/proto/BASIC_CONFIGURATION_README.html b/proto/BASIC_CONFIGURATION_README.html new file mode 100644 index 0000000..80cf6d2 --- /dev/null +++ b/proto/BASIC_CONFIGURATION_README.html @@ -0,0 +1,681 @@ + + + + + + + Postfix Basic Configuration + + + + + + + +

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:

+ +
+
+/etc/postfix/main.cf:
+    parameter = value
+
+
+ +

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

+ +
+
+/etc/postfix/main.cf:
+    other_parameter = $parameter
+
+
+ +

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:

+ +
+
+/etc/postfix/main.cf:
+    virtual_alias_maps = hash:/etc/postfix/virtual
+
+
+ +

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:

+ +
+
+# postfix reload
+
+
+ +

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):

+ +
+
+/etc/postfix/main.cf:
+    myorigin = $myhostname (default: send mail as "user@$myhostname")
+    myorigin = $mydomain   (probably desirable: "user@$mydomain")
+
+
+ +

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.

+ +
+
+/etc/postfix/main.cf:
+    mydestination = $myhostname localhost.$mydomain localhost
+
+
+ +

Example 2: domain-wide mail server.

+ +
+
+/etc/postfix/main.cf:
+    mydestination = $myhostname localhost.$mydomain localhost $mydomain
+
+
+ +

Example 3: host with multiple DNS A records.

+ +
+
+/etc/postfix/main.cf:
+    mydestination = $myhostname localhost.$mydomain localhost 
+        www.$mydomain ftp.$mydomain
+
+
+ +

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 your default mynetworks setting may be too friendly.

+ +

Examples (specify only one of the following):

+ +
+
+/etc/postfix/main.cf:
+    mynetworks_style = subnet  (default: authorize subnetworks)
+    mynetworks_style = host    (safe: authorize local machine only)
+    mynetworks = 127.0.0.0/8   (safe: authorize local machine only)
+    mynetworks = 127.0.0.0/8 168.100.189.2/32 (authorize local machine) 
+
+
+ +

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. + +

+ +

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:

+ +
+
+/etc/postfix/main.cf:
+    mynetworks = 168.100.189.0/28, 127.0.0.0/8
+
+
+ +

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):

+ +
+
+/etc/postfix/main.cf:
+    relay_domains = $mydestination (default)
+    relay_domains =           (safe: never forward mail from strangers)
+    relay_domains = $mydomain (forward mail to my domain and subdomains)
+
+
+ +

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):

+ +
+
+/etc/postfix/main.cf:
+    relayhost =                   (default: direct delivery to Internet)
+    relayhost = $mydomain         (deliver via local mailhub)
+    relayhost = [mail.$mydomain]  (deliver via local mailhub)
+    relayhost = [mail.isp.tld]    (deliver via provider mailhub)
+
+
+ +

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.

+ +
+
+/etc/aliases:
+    postmaster: you
+    root: you
+
+
+ +

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:

+ +

Default setting:

+ +
+
+/etc/postfix/main.cf:
+    notify_classes = resource, software
+
+
+ +

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.

+ +
+
+/etc/postfix/main.cf:
+    proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
+
+
+ +

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:

+ +
+
+/etc/syslog.conf:
+    mail.err                                    /dev/console
+    mail.debug                                  /var/log/maillog
+
+
+ +

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:

+ +
+
+# postfix check
+# egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+
+ + + +

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):

+ +
+
+/etc/postfix/main.cf:
+    myhostname = host.local.domain (machine name is not FQDN)
+    myhostname = host.virtual.domain (virtual interface)
+    myhostname = virtual.domain (virtual interface)
+
+
+ +

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):

+ +
+
+/etc/postfix/main.cf:
+    mydomain = local.domain
+    mydomain = virtual.domain (virtual interface)
+
+
+ +

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.

+ +
+
+/etc/postfix/main.cf:
+    inet_interfaces = all
+
+
+ +

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

+ +
+
+/etc/postfix/main.cf:
+    inet_interfaces = virtual.host.tld         (virtual Postfix)
+    inet_interfaces = $myhostname localhost... (non-virtual Postfix)
+
+
+ +

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

+ + + + diff --git a/proto/BDAT_README.html b/proto/BDAT_README.html new file mode 100644 index 0000000..7839904 --- /dev/null +++ b/proto/BDAT_README.html @@ -0,0 +1,178 @@ + + + + + + +Postfix BDAT (CHUNKING) support + + + + + + + +

Postfix +BDAT (CHUNKING) support

+ +
+ +

Overview

+ +

Postfix SMTP server supports RFC 3030 CHUNKING (the BDAT command) +without BINARYMIME, in both smtpd(8) and postscreen(8). It is enabled +by default.

+ +

Topics covered in this document:

+ + + +

Disabling BDAT support

+ +

BDAT support is enabled by default. To disable BDAT support +globally:

+ +
+
+/etc/postfix/main.cf:
+    # The logging alternative:
+    smtpd_discard_ehlo_keywords = chunking
+    # The non-logging alternative:
+    smtpd_discard_ehlo_keywords = chunking, silent-discard
+
+
+ +

Specify '-o smtpd_discard_ehlo_keywords=' in master.cf +for the submission and smtps services, if you have clients +that benefit from CHUNKING support.

+ +

Impact on existing configurations

+ + + +

Example SMTP session

+ +

The main differences are that the Postfix SMTP server announces +"CHUNKING" support in the EHLO response, and that instead of sending +one DATA request, the remote SMTP client may send one or more BDAT +requests. In the example below, "S:" indicates server responses, +and "C:" indicates client requests (bold font).

+ +
+
+    S: 220 server.example.com
+    C: EHLO client.example.com
+    S: 250-server.example.com
+    S: 250-PIPELINING
+    S: 250-SIZE 153600000
+    S: 250-VRFY
+    S: 250-ETRN
+    S: 250-STARTTLS
+    S: 250-AUTH PLAIN LOGIN
+    S: 250-ENHANCEDSTATUSCODES
+    S: 250-8BITMIME
+    S: 250-DSN
+    S: 250-SMTPUTF8
+    S: 250 CHUNKING
+    C: MAIL FROM:<sender@example.com>
+    S: 250 2.1.0 Ok
+    C: RCPT TO:<recipient@example.com>
+    S: 250 2.1.5 Ok
+    C: BDAT 10000
+    C: ..followed by 10000 bytes...
+    S: 250 2.0.0 Ok: 10000 bytes
+    C: BDAT 123
+    C: ..followed by 123 bytes...
+    S: 250 2.0.0 Ok: 123 bytes
+    C: BDAT 0 LAST
+    S: 250 2.0.0 Ok: 10123 bytes queued as 41yYhh41qmznjbD
+    C: QUIT
+    S: 221 2.0.0 Bye
+
+
+ +

Internally in Postfix, there is no difference between mail that +was received with BDAT or with DATA. Postfix smtpd_mumble_restrictions, +policy delegation queries, smtpd_proxy_filter and Milters all behave +as if Postfix received (MAIL + RCPT + DATA + end-of-data). However, +Postfix will log BDAT-related failures as "xxx after BDAT" to avoid +complicating troubleshooting (xxx = 'lost connection' or 'timeout'), +and will log a warning when a client sends a malformed BDAT command. +

+ +

Benefits of CHUNKING (BDAT) support without +BINARYMIME

+ +

Support for CHUNKING (BDAT) was added to improve interoperability +with some clients, a benefit that would reportedly exist even without +Postfix support for BINARYMIME. Since June 2018, Wietse's mail +server has received BDAT commands from a variety of systems.

+ +

Postfix does not support BINARYMIME at this time because:

+ + + +

Downsides of CHUNKING (BDAT) support +

+ +

The RFC 3030 authors did not specify any limitations on how +clients may pipeline commands (i.e. send commands without waiting +for a server response). If a server announces PIPELINING support, +like Postfix does, then a remote SMTP client can pipeline all +commands following EHLO, for example, MAIL/RCPT/BDAT/BDAT/MAIL/RCPT/BDAT, +without ever having to wait for a server response. This means that +with BDAT, the Postfix SMTP server cannot distinguish between a +well-behaved client and a spambot, based on their command pipelining +behavior. If you require "reject_unauth_pipelining" to block spambots, +then turn off Postfix's CHUNKING announcement as described above. +

+ +

In RFC 4468, the authors write that a client may pipeline +commands, and that after sending BURL LAST or BDAT LAST, a client +must wait for the server's response. But as this text does not +appear in RFC 3030 which defines BDAT, is it a useless restriction +that Postfix will not enforce.

+ + + + diff --git a/proto/BUILTIN_FILTER_README.html b/proto/BUILTIN_FILTER_README.html new file mode 100644 index 0000000..503b0aa --- /dev/null +++ b/proto/BUILTIN_FILTER_README.html @@ -0,0 +1,488 @@ + + + + + + +Postfix Built-in Content Inspection + + + + + + + +

+Postfix Built-in Content Inspection

+ +
+ +

Built-in content inspection introduction

+ +

Postfix supports a built-in filter mechanism that examines +message header and message body content, one line at a time, before +it is stored in the Postfix queue. The filter is usually implemented +with POSIX or PCRE regular expressions, as described in the +header_checks(5) manual page.

+ +

The original purpose of the built-in filter is to stop an +outbreak of specific email worms or viruses, and it does this job +well. The filter has also helped to block bounced junk email, +bounced email from worms or viruses, and notifications from virus +detection systems. Information about this secondary application +is given in the BACKSCATTER_README document.

+ +

Because the built-in filter is optimized for stopping specific +worms and virus outbreaks, it has limitations +that make it NOT suitable for general junk email and virus detection. +For that, you should use one of the external content inspection +methods that are described in the FILTER_README, SMTPD_PROXY_README +and MILTER_README documents.

+ +

The following diagram gives an over-all picture of how Postfix +built-in content inspection works:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Postmaster
notifications
|
v
+ Network or
local users 		-> + + Built-in
filter 		-> + Postfix
queue 		-> + Delivery
agents 		-> + Network or
local mailbox
^
| 		|
v
Undeliverable mail
Forwarded mail
+ +
+ +

The picture makes clear that the filter works while Postfix is +receiving new mail. This means that Postfix can reject mail from +the network without having to return undeliverable mail to the +originator address (which is often spoofed anyway). However, this +ability comes at a price: if mail inspection takes too much time, +then the remote client will time out, and the client may send the +same message repeatedly.

+ +

Topics covered by this document:

+ + + +

What mail is subjected to header/body checks

+ +

Postfix header/body checks are implemented by the cleanup(8) +server before it injects mail into the incoming queue. The diagram +below zooms in on the cleanup(8) server, and shows that this server +handles mail from many different sources. In order to keep the +diagram readable, the sources of postmaster notifications are not +shown, because they can be produced by many Postfix daemon processes. +

+ +
+ + + + + + + + + + + + + + + +
bounce(8)
(undeliverable)
+smtpd(8)
(network) 		+ \ |
v +
+qmqpd(8)
(network) 		+ -\
-/ 		cleanup(8) + -> +incoming
queue
+pickup(8)
(local) 		+/ ^
| +
local(8)
(forwarded)
+ +
+ +

For efficiency reasons, only mail that enters from outside of +Postfix is inspected with header/body checks. It would be inefficient +to filter already filtered mail again, and it would be undesirable +to block postmaster notifications. The table below summarizes what +mail is and is not subject to header/body checks.

+ +
+ + + + + + + + + + + + + + + + + +
Message type Source Header/body checks?
Undeliverable mail bounce(8) No
Network mail smtpd(8) Configurable
Network mail qmqpd(8) Configurable
Local submission pickup(8) Configurable
Local forwarding local(8) No
Postmaster notice many No
+ +
+ +

How does Postfix decide what mail needs to be filtered? It +would be clumsy to make the decision in the cleanup(8) server, as +this program receives mail from so many different sources. Instead, +header/body checks are requested by the source. Examples of how +to turn off header/body checks for mail received with smtpd(8), +qmqpd(8) or pickup(8) are given below under "Configuring header/body checks for mail from +outside users only", "Configuring +different header/body checks for MX service and submission +service", and "Configuring +header/body checks for mail to some domains only".

+ +

Limitations of Postfix header/body checks

+ + + +

Preventing daily mail status reports from being blocked

+ +

The following is quoted from Jim Seymour's Pflogsumm FAQ at +http://jimsun.linxnet.com/downloads/pflogsumm-faq.txt. Pflogsumm +is a program that analyzes Postfix logs, including the logging from +rejected mail. If these logs contain text that was rejected by +Postfix body_checks patterns, then the logging is also likely to +be rejected by those same body_checks patterns. This problem does +not exist with header_checks patterns, because those are not applied +to the text that is part of the mail status report.

+ +
+ +

You configure Postfix to do body checks, Postfix does its thing, +Pflogsumm reports it and Postfix catches the same string in the +Pflogsumm report. There are several solutions to this.

+ +

Wolfgang Zeikat contributed this:

+ +
+
+#!/usr/bin/perl
+use MIME::Lite;
+
+### Create a new message:
+$msg = MIME::Lite->new(
+    From     => 'your@send.er',
+    To       => 'your@recipie.nt',
+    # Cc     => 'some@other.com, some@more.com',
+    Subject  => 'pflogsumm',
+    Date     => `date`,
+    Type     => 'text/plain',
+    Encoding => 'base64',
+    Path     => '/tmp/pflogg',
+);
+
+$msg->send;
+
+
+ +

Where "/tmp/pflogg" is the output of Pflogsumm. This puts Pflogsumm's +output in a base64 MIME attachment.

+ +
+ +

Note by Wietse: if you run this on a machine that is accessible +by untrusted users, it is safer to store the Pflogsumm report in +a directory that is not world writable.

+ +
+ +

In a follow-up to a thread in the postfix-users mailing list, Ralf +Hildebrandt noted:

+ +

"mpack does the same thing."

+ +
+ +

And it does. Which tool one should use is a matter of preference. +

+ +

Other solutions involve additional body_checks rules that make +exceptions for daily mail status reports, but this is not recommended. +Such rules slow down all mail and complicate Postfix maintenance. +

+ +

Configuring header/body checks for mail from outside users only

+ +

The following information applies to Postfix 2.1 and later. +Earlier +Postfix versions do not support the receive_override_options feature. +

+ +

The easiest approach is to configure ONE Postfix instance with +multiple SMTP server IP addresses in master.cf:

+ + + +

Configuring different header/body checks for MX service and submission service

+ +

If authorized user submissions require different header/body +checks than mail from remote MTAs, then this is possible as long +as you have separate mail streams for authorized users and for MX +service.

+ +

The example below assumes that authorized users connect to TCP +port 587 (submission) or 465 (smtps), and that remote MTAs connect +to TCP port 25 (smtp).

+ +

First, we define a few "user-defined" parameters that will +override settings for the submission and smtps services.

+ +
+
+/etc/postfix/main.cf:
+    msa_cleanup_service_name = msa_cleanup
+    msa_header_checks = pcre:/etc/postfix/msa_header_checks
+    msa_body_checks = pcre:/etc/postfix/msa_body_checks
+
+
+ +

Next, we define msa_cleanup as a dedicated cleanup service that +will be used only by the submission and smtps services. This service +uses the header_checks and body_checks overrides that were defined +above.

+ +
+
+/etc/postfix.master.cf:
+    # =================================================================
+    # service     type  private unpriv  chroot  wakeup  maxproc command
+    #                   (yes)   (yes)   (yes)   (never) (100)
+    # =================================================================
+    smtp          inet  n       -       n       -       -       smtpd
+    msa_cleanup   unix  n       -       n       -       0       cleanup
+        -o header_checks=$msa_header_checks
+        -o body_checks=$msa_body_checks
+    submission    inet  n       -       n       -       -       smtpd
+        -o cleanup_service_name=$msa_cleanup_service_name
+        -o syslog_name=postfix/submission
+        ...[see sample master.cf file for more]...
+    smtps         inet  n       -       n       -       -       smtpd
+        -o cleanup_service_name=$msa_cleanup_service_name
+        -o syslog_name=postfix/smtps
+        -o smtpd_tls_wrappermode=yes
+        ...[see sample master.cf file for more]...
+
+
+ +

By keeping the "msa_xxx" parameter settings in main.cf, you +keep your master.cf file simple, and you minimize the amount +of duplication.

+ +

Configuring header/body checks for mail to some domains only

+ +

The following information applies to Postfix 2.1. Earlier +Postfix versions do not support the receive_override_options feature. +

+ +

If you are MX service provider and want to apply disable +head/body checks for some domains, you can configure ONE Postfix +instance with multiple SMTP server IP addresses in master.cf. Each +address provides a different service.

+ +
+ +
+/etc/postfix.master.cf:
+    # =================================================================
+    # service     type  private unpriv  chroot  wakeup  maxproc command
+    #                   (yes)   (yes)   (yes)   (never) (100)
+    # =================================================================
+    # SMTP service for domains with header/body checks turned on.
+    1.2.3.4:smtp  inet  n       -       n       -       -       smtpd
+
+    # SMTP service for domains with header/body checks turned off.
+    1.2.3.5:smtp  inet  n       -       n       -       -       smtpd
+        -o receive_override_options=no_header_body_checks
+
+
+ +

Once this is set up you can configure MX records in the DNS +that route each domain to the proper SMTP server instance.

+ + + + diff --git a/proto/CDB_README.html b/proto/CDB_README.html new file mode 100644 index 0000000..352c6ad --- /dev/null +++ b/proto/CDB_README.html @@ -0,0 +1,109 @@ + + + + + + +Postfix CDB Howto + + + + + + + +

Postfix CDB Howto

+ +
+ +

Introduction

+ +

CDB (Constant DataBase) is an indexed file format designed by +Daniel Bernstein. CDB is optimized exclusively for read access +and guarantees that each record will be read in at most two disk +accesses. This is achieved by forgoing support for incremental +updates: no single-record inserts or deletes are supported. CDB +databases can be modified only by rebuilding them completely from +scratch, hence the "constant" qualifier in the name.

+ +

Postfix CDB databases are specified as "cdb:name", where +name specifies the CDB file name without the ".cdb" suffix +(another suffix, ".tmp", is used temporarily while a CDB file is +under construction). CDB databases are maintained with the postmap(1) +or postalias(1) command. The DATABASE_README document has general +information about Postfix databases.

+ +

CDB support is available with Postfix 2.2 and later releases. +This document describes how to build Postfix with CDB support.

+ +

Building Postfix with CDB support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

Postfix is compatible with two CDB implementations:

+ + + +

Tinycdb is preferred, since it is a bit faster, has additional +useful functionality and is much simpler to use.

+ +

To build Postfix after you have installed tinycdb, use something +like:

+ +
+
+% make tidy
+% CDB=../../../tinycdb-0.5
+% make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
+    "AUXLIBS_CDB=$CDB/libcdb.a"
+% make
+
+
+ +

Alternatively, for the D.J.B. version of CDB:

+ +

+
+% make tidy
+% CDB=../../../cdb-0.75
+% make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
+    "AUXLIBS_CDB=$CDB/cdb.a $CDB/alloc.a $CDB/buffer.a $CDB/unix.a $CDB/byte.a"
+% make
+
+
+ +

Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_CDB. +With Postfix 3.0 and later, the old AUXLIBS variable still supports +building a statically-loaded CDB database client, but only the new +AUXLIBS_CDB variable supports building a dynamically-loaded or +statically-loaded CDB database client.

+ +
+ +

Failure to use the AUXLIBS_CDB variable will defeat the purpose +of dynamic database client loading. Every Postfix executable file +will have CDB database library dependencies. And that was exactly +what dynamic database client loading was meant to avoid.

+ +
+ +

After Postfix has been built with cdb support, you can use +"cdb" tables wherever you can use read-only "hash", "btree" or +"dbm" tables. However, the "postmap -i" (incremental record +insertion) and "postmap -d" (incremental record deletion) +command-line options are not available. For the same reason the +"cdb" map type cannot be used to store the persistent address +verification cache for the verify(8) service, or to store +TLS session information for the tlsmgr(8) service.

diff --git a/proto/COMPATIBILITY_README.html b/proto/COMPATIBILITY_README.html new file mode 100644 index 0000000..291979d --- /dev/null +++ b/proto/COMPATIBILITY_README.html @@ -0,0 +1,395 @@ + + + + + + +Postfix Backwards-Compatibility Safety Net + + + + + + + +

Postfix +Backwards-Compatibility Safety Net

+ +
+ +

Purpose of this document

+ +

Postfix 3.0 introduces a safety net that runs Postfix programs +with backwards-compatible default settings after an upgrade. The +safety net will log a warning whenever a "new" default setting could +have an negative effect on your mail flow.

+ +

This document provides information on the following topics:

+ + + +

Overview

+ +

With backwards compatibility turned on, Postfix logs a message +whenever a backwards-compatible default setting may be required for +continuity of service. Based on this logging the system administrator +can decide if any backwards-compatible settings need to be made +permanent in main.cf or master.cf, before turning +off the backwards-compatibility safety net as described at the +end of this document.

+ +

The following messages may be logged:

+ + + +

If such a message is logged in the context of a legitimate +request, the system administrator should make the backwards-compatible +setting permanent in main.cf or master.cf, as detailed in the +sections that follow.

+ +

When no more backwards-compatible settings need to be made +permanent, the system administrator should turn +off the backwards-compatibility safety net as described at the +end of this document.

+ +

Using backwards-compatible default +setting append_dot_mydomain=yes

+ +

The append_dot_mydomain default value has changed from "yes" +to "no". This could result in unexpected non-delivery of email after +Postfix is updated from an older version. The backwards-compatibility +safety net is designed to prevent such surprises.

+ +

As long as the append_dot_mydomain parameter is left at +its implicit default value, and the compatibility_level setting is +less than 1, Postfix may log one of the following messages:

+ + + +

Using backwards-compatible default +setting chroot=y

+ +

The master.cf chroot default value has changed from "y" (yes) +to "n" (no). The new default avoids the need for copies of system +files under the Postfix queue directory. However, sites with strict +security requirements may want to keep the chroot feature enabled +after updating Postfix from an older version. The backwards-compatibility +safety net is designed allow the administrator to choose if they +want to keep the old behavior.

+ +

As long as a master.cf chroot field is left at its +implicit default value, and the compatibility_level setting +is less than 1, Postfix may log the following message while it +reads the master.cf file:

+ +
+
+postfix/master[27664]: /etc/postfix/master.cf: line 72: using
+    backwards-compatible default setting chroot=y
+
+
+ +

If this service should remain chrooted, then the system +administrator should make the backwards-compatible setting "chroot += y" permanent in master.cf. For example, to update the chroot +setting for the "smtp inet" service:

+ +
+
+# postconf -F smtp/inet/chroot=y
+# postfix reload
+
+
+ +

Using backwards-compatible default +setting smtpd_relay_restrictions = (empty)

+ +

The smtpd_relay_restrictions feature was introduced with Postfix +version 2.10, as a safety mechanism for configuration errors in +smtpd_recipient_restrictions that could make Postfix an open relay. +

+ +

The smtpd_relay_restrictions implicit default setting forbids +mail to remote destinations from clients that don't match +permit_mynetworks or permit_sasl_authenticated. This could result +in unexpected 'Relay access denied' errors after Postfix is updated +from an older Postfix version. The backwards-compatibility safety +net is designed to prevent such surprises.

+ +

When the compatibility_level less than 1, and the +smtpd_relay_restrictions parameter is left at its implicit default +setting, Postfix may log the following message:

+ +
+
+postfix/smtpd[38463]: using backwards-compatible default setting
+    "smtpd_relay_restrictions = (empty)" to avoid "Relay access
+    denied" error for recipient "user@example.com" from client
+    "host.example.net[10.0.0.2]"
+
+
+ +

If this request should not be blocked, then the system +administrator should make the backwards-compatible setting +"smtpd_relay_restrictions=" (i.e. empty) permanent in main.cf: + +

+
+# postconf smtpd_relay_restrictions=
+# postfix reload
+
+
+ +

Using backwards-compatible default +setting mynetworks_style=subnet

+ +

The mynetworks_style default value has changed from "subnet" +to "host". This parameter is used to implement the "permit_mynetworks" +feature. The change could in unexpected 'access denied' errors after +Postfix is updated from an older version. The backwards-compatibility +safety net is designed to prevent such surprises.

+ +

As long as the mynetworks and mynetworks_style parameters are +left at their implicit default values, and the compatibility_level +setting is less than 2, the Postfix SMTP server may log one of the +following messages:

+ +
+
+postfix/smtpd[17375]: using backwards-compatible default setting
+    mynetworks_style=subnet to permit request from client
+    "foo.example.com[10.1.1.1]"
+
+
+ +
+
+postfix/postscreen[24982]: using backwards-compatible default
+    setting mynetworks_style=subnet to permit request from client
+    "10.1.1.1"
+
+
+ +

If the client request should not be rejected, then the system +administrator should make the backwards-compatible setting +"mynetworks_style = subnet" permanent in main.cf:

+ +
+
+# postconf mynetworks_style=subnet
+# postfix reload
+
+
+ +

Using backwards-compatible default +setting relay_domains=$mydestination

+ +

The relay_domains default value has changed from "$mydestination" +to the empty value. This could result in unexpected 'Relay access +denied' errors or ETRN errors after Postfix is updated from an older +version. The backwards-compatibility safety net is designed to +prevent such surprises.

+ +

As long as the relay_domains parameter is left at its implicit +default value, and the compatibility_level setting is less than 2, +Postfix may log one of the following messages.

+ + + +

If Postfix should continue to accept mail for that domain or +continue to provide ETRN service for that domain, then the system +administrator should make the backwards-compatible setting +"relay_domains = $mydestination" permanent in main.cf:

+ +
+
+# postconf 'relay_domains=$mydestination'
+# postfix reload
+
+
+ +

Note: quotes are required as indicated above.

+ +

Instead of $mydestination, it may be better to specify an +explicit list of domain names.

+ +

Using backwards-compatible default +setting smtputf8_enable=no

+ +

The smtputf8_enable default value has changed from "no" to "yes. +With the new "yes" setting, the Postfix SMTP server rejects non-ASCII +addresses from clients that don't request SMTPUTF8 support, after +Postfix is updated from an older version. The backwards-compatibility +safety net is designed to prevent such surprises.

+ +

As long as the smtputf8_enable parameter is left at its implicit +default value, and the compatibility_level setting is +less than 1, Postfix logs a warning each time an SMTP command uses a +non-ASCII address localpart without requesting SMTPUTF8 support:

+ +
+
+postfix/smtpd[27560]: using backwards-compatible default setting
+    smtputf8_enable=no to accept non-ASCII sender address
+    "??@example.org" from localhost[127.0.0.1]
+
+
+ +
+
+postfix/smtpd[27560]: using backwards-compatible default setting
+    smtputf8_enable=no to accept non-ASCII recipient address
+    "??@example.com" from localhost[127.0.0.1]
+
+
+ +

If the address should not be rejected, and the client cannot +be updated to use SMTPUTF8, then the system administrator should +make the backwards-compatible setting "smtputf8_enable = no" permanent +in main.cf: + +

+
+# postconf smtputf8_enable=no
+# postfix reload
+
+
+ +

Turning off the backwards-compatibility safety net

+ +

Backwards compatibility is turned off by updating the +compatibility_level setting in main.cf.

+ +
+
+# postconf compatibility_level=N
+# postfix reload
+
+
+ +

For N specify the number that is logged in your postfix(1) +warning message:

+ +
+
+warning: To disable backwards compatibility use "postconf compatibility_level=N" and "postfix reload"
+
+
+ +

Sites that don't care about backwards compatibility may set +"compatibility_level = 9999" at their own risk.

+ + + + diff --git a/proto/CONNECTION_CACHE_README.html b/proto/CONNECTION_CACHE_README.html new file mode 100644 index 0000000..7ffd7bb --- /dev/null +++ b/proto/CONNECTION_CACHE_README.html @@ -0,0 +1,308 @@ + + + + + + +Postfix Connection Cache + + + + + + + +

Postfix Connection Cache

+ +
+ +

Introduction

+ +

This document describes the Postfix connection cache implementation, +which is available with Postfix version 2.2 and later.

+ +

See Client-side TLS +connection reuse for how this connection cache is used to +implement multiple deliveries per TLS-encrypted connection.

+ +

Topics covered in this document:

+ + + +

What SMTP connection caching can do for +you

+ +

With SMTP connection caching, Postfix can deliver multiple +messages over the same SMTP connection. By default, Postfix 2.2 +reuses an SMTP connection automatically when a destination has +high volume of mail in the active queue.

+ +

SMTP Connection caching is a performance feature. Whether or not +it actually improves performance depends on the conditions:

+ + + +

For other potential issues with SMTP connection caching, see +the discussion of limitations at the end +of this document.

+ +

Connection cache implementation

+ +

For an overview of how Postfix delivers mail, see the Postfix +architecture OVERVIEW document.

+ +

The Postfix connection cache is shared among Postfix mail +delivering processes. This maximizes the opportunity to reuse an +open connection. Other MTAs such as Sendmail or exim have a +non-shared connection cache. Here, a connection can be reused only +by the mail delivering process that creates the connection. To get +the same performance improvement as with a shared connection cache, +non-shared connections need to be kept open for a longer time.

+ +

The scache(8) server, introduced with Postfix version 2.2, +maintains the shared connection cache. With Postfix version 2.2, +only the smtp(8) client has support to access this cache.

+ +
+ + + + + + + + + + + + + + + + +
/-- smtp(8) +--> Internet
qmgr(8)   |
|
|
|
v		  
\-- smtp(8) +--> Internet
^
|		  
scache(8)
+ +
+ +

When SMTP connection caching is enabled (see next section), the +smtp(8) client does not disconnect after a mail transaction, but +gives the connection to the scache(8) server which keeps the +connection open for a limited amount of time.

+ +

After handing over the open connection to the scache(8) server, +the smtp(8) client continues with some other mail delivery request. +Meanwhile, any smtp(8) client process can ask the scache(8) server +for that cached connection and reuse it for mail delivery.

+ +

The connection cache can be searched by destination domain name +(the right-hand side of the recipient address) and by the IP address +of the host at the other end of the connection. This allows Postfix +to reuse a connection even when the remote host is mail server for +domains with different names.

+ +

Connection cache configuration

+ +

The Postfix smtp(8) client supports two connection caching +strategies:

+ + + +

Connection cache safety mechanisms

+ +

Connection caching must be used wisely. It is anti-social to +keep an unused SMTP connection open for a significant amount of +time, and it is unwise to send huge numbers of messages through +the same connection. In order to avoid problems with SMTP connection +caching, Postfix implements the following safety mechanisms:

+ + + +

Connection cache limitations

+ +

Postfix SMTP connection caching conflicts with certain applications: +

+ + + + +

Connection cache statistics

+ +

The scache(8) connection cache server logs statistics about the +peak cache size and the cache hit rates. This information is logged +every connection_cache_status_update_time seconds, when the process +terminates after the maximal idle time is exceeded, or when Postfix +is reloaded.

+ + + + + + + diff --git a/proto/CONTENT_INSPECTION_README.html b/proto/CONTENT_INSPECTION_README.html new file mode 100644 index 0000000..98a529d --- /dev/null +++ b/proto/CONTENT_INSPECTION_README.html @@ -0,0 +1,92 @@ + + + + + + +Postfix Content Inspection + + + + + + + +

Postfix +Content Inspection

+ +
+ +

Postfix supports three content inspection methods, ranging from +light-weight one-line-at-a-time scanning before mail is queued, to +heavy duty machinery that does sophisticated content analysis after +mail is queued. Each approach serves a different purpose.

+ +
+ +
before queue, built-in, light-weight
+ +

This method inspects mail BEFORE it is stored in the queue, +and uses Postfix's built-in message header and message body +inspection. Although the main purpose is to stop a specific flood +of mail from worms or viruses, it is also useful to block a flood +of bounced junk email and email notifications from virus detection +systems. The built-in regular expressions are not meant to implement +general SPAM and virus detection. For that, you should use one of +the content inspection methods described below. Details are described +in the BUILTIN_FILTER_README and BACKSCATTER_README documents. +

+ +
after queue, external, heavy-weight
+ +

This method inspects mail AFTER it is stored in the queue, +and uses standard protocols such as SMTP or "pipe to command and +wait for exit status". After-queue inspection allows you to use +content filters of arbitrary complexity without causing timeouts +while receiving mail, and without running out of memory resources +under a peak load. Details of this approach are in the FILTER_README +document.

+ +
before queue, external, medium-weight
+ +

The following two methods inspect mail BEFORE it is stored in the +queue.

+ +
    + +

  • The first method uses the SMTP protocol, and is described +in the SMTPD_PROXY_README document. This approach is available +with Postfix version 2.1 and later.

    + +

  • The second method uses the Sendmail 8 Milter protocol, and +is described in the MILTER_README document. This approach is +available with Postfix version 2.3 and later.

    + +
+ +

Although these approaches appear to be attractive, they have +some serious limitations that you need to be aware of. First, +content inspection software must finish in a limited amount of time; +if content inspection needs too much time then incoming mail +deliveries will time out. Second, content inspection software must +run in a limited amount of memory; if content inspection needs too +much memory then software will crash under a peak load. Before-queue +inspection limits the peak load that your system can handle, and +limits the sophistication of the content filter that you can use. +

+ +
+ +

The more sophisticated content filtering software is not built +into Postfix for good reasons: writing an MTA requires different +skills than writing a SPAM or virus killer. Postfix encourages the +use of external filters and standard protocols because this allows +you to choose the best MTA and the best content inspection software +for your purpose. Information about external content inspection +software can be found on the Postfix website at http://www.postfix.org/, +and on the postfix-users@postfix.org mailing list.

+ + + + diff --git a/proto/DATABASE_README.html b/proto/DATABASE_README.html new file mode 100644 index 0000000..19bb9ae --- /dev/null +++ b/proto/DATABASE_README.html @@ -0,0 +1,497 @@ + + + + + + +Postfix Lookup Table Overview + + + + + + + +

Postfix +Lookup Table Overview

+ +
+ +

Overview

+ +This document covers the following topics: + + + +

The Postfix lookup table model

+ +

Postfix uses lookup tables to store and look up information +for access control, address rewriting and even for content filtering. +All Postfix lookup tables are specified as "type:table", where +"type" is one of the database types described under "Postfix lookup table types" at the end of this +document, and where "table" is the lookup table name. The Postfix +documentation uses the terms "database" and "lookup table" for the +same thing.

+ +

Examples of lookup tables that appear often in the Postfix +documentation:

+ +
+
+/etc/postfix/main.cf:
+    alias_maps = hash:/etc/postfix/aliases            (local aliasing)
+    header_checks = regexp:/etc/postfix/header_checks (content filtering)
+    transport_maps = hash:/etc/postfix/transport      (routing table)
+    virtual_alias_maps = hash:/etc/postfix/virtual    (address rewriting)
+
+
+ +

All Postfix lookup tables store information as (key, value) +pairs. This interface may seem simplistic at first, but it turns +out to be very powerful. The (key, value) query interface completely +hides the complexities of LDAP or SQL from Postfix. This is a good +example of connecting complex systems with simple interfaces.

+ +

Benefits of the Postfix (key, value) query interface:

+ + + +

Postfix lists versus tables

+ +

Most Postfix lookup tables are used to look up information. +Examples are address rewriting (the lookup string is the old address, +and the result is the new address) or access control (the lookup +string is the client, sender or recipient, and the result is an +action such as "reject").

+ +

With some tables, however, Postfix needs to know only if the +lookup key exists. Any non-empty lookup result value may be used +here: the lookup result is not used. Examples +are the local_recipient_maps that determine what local recipients +Postfix accepts in mail from the network, the mydestination parameter +that specifies what domains Postfix delivers locally, or the +mynetworks parameter that specifies the IP addresses of trusted +clients or client networks. Technically, these are lists, not +tables. Despite the difference, Postfix lists are described here +because they use the same underlying infrastructure as Postfix +lookup tables.

+ +

Preparing Postfix for LDAP or SQL lookups +

+ +

LDAP and SQL are complex systems. Trying to set up both Postfix +and LDAP or SQL at the same time is definitely not a good idea. +You can save yourself a lot of time by implementing Postfix first +with local files such as Berkeley DB. Local files have few surprises, +and are easy to debug with the postmap(1) command:

+ +
+
+% postmap -q info@example.com hash:/etc/postfix/virtual 
+
+
+ +

Once you have local files working properly you can follow the +instructions in ldap_table(5), mysql_table(5), pgsql_table(5) +or sqlite_table(5) +and replace local file lookups with LDAP or SQL lookups. When you +do this, you should use the postmap(1) command again, to verify +that database lookups still produce the exact same results as local +file lookup:

+ +
+
+% postmap -q info@example.com ldap:/etc/postfix/virtual.cf 
+
+
+ +

Be sure to exercise all the partial address or parent domain +queries that are documented under "table search order" in the +relevant manual page: access(5), canonical(5), virtual(5), +transport(5), or under the relevant configuration parameter: +mynetworks, relay_domains, parent_domain_matches_subdomains.

+ +

Maintaining Postfix lookup table files

+ +

When you make changes to a database while the mail system is +running, it would be desirable if Postfix avoids reading information +while that information is being changed. It would also be nice if +you can change a database without having to execute "postfix reload", +in order to force Postfix to use the new information. Each time +you do "postfix reload" Postfix loses a lot of performance. +

+ + + +

Updating Berkeley DB files safely

+ +

Postfix uses file locking to avoid access conflicts while +updating Berkeley DB or other local database files. This used to +be safe, but as Berkeley DB has evolved to use more aggressive +caching, file locking may no longer be sufficient.

+ +

Furthermore, file locking would not prevent problems when the +update fails because the disk is full or something else causes a +database update to fail. In particular, commands such as postmap(1) +or postalias(1) overwrite existing files. If the overwrite +fails in the middle then you have no usable database, and Postfix +will stop working. This is not an issue with the CDB database type +available with Postfix 2.2 and later: CDB +creates a new file, and renames the file upon successful completion. +

+ +

With Berkeley DB and other "one file" databases, it is +possible to add some extra robustness by using "mv" to REPLACE an +existing database file instead of overwriting it:

+ +
+
+# postmap access.in && mv access.in.db access.db
+
+
+ +

This converts the input file "access.in" into the output file +"access.in.db", and replaces the file "access.db" only when the +postmap(1) command was successful. Of course typing such commands +becomes boring quickly, and this is why people use "make" instead, +as shown below. User input is shown in bold font.

+ +
+
+# cat Makefile
+all: aliases.db access.db virtual.db ...etcetera...
+
+# Note 1: commands are specified after a TAB character.
+# Note 2: use postalias(1) for local aliases, postmap(1) for the rest.
+aliases.db: aliases.in
+	postalias aliases.in
+	mv aliases.in.db aliases.db
+
+access.db: access.in
+	postmap access.in
+	mv access.in.db access.db
+
+virtual.db: virtual.in
+	postmap virtual.in
+	mv virtual.in.db virtual.db
+
+...etcetera...
+# vi access.in
+...editing session not shown...
+# make
+postmap access.in
+mv access.in.db access.db
+#
+
+
+ +

The "make" command updates only the files that have changed. +In case of error, the "make" command will stop and will not invoke +the "mv" command, so that Postfix will keep using the existing +database file as if nothing happened.

+ +

Postfix lookup table types

+ +

To find out what database types your Postfix system supports, +use the "postconf -m" command. Here is a list of database types +that are often supported:

+ +
+ +
+ +
btree
+ +
A sorted, balanced tree structure. This is available only on +systems with support for Berkeley DB databases. Database files are +created with the postmap(1) or postalias(1) command. The lookup +table name as used in "btree:table" is the database file name +without the ".db" suffix.
+ +
cdb
+ +
A read-optimized structure with no support for incremental updates. +Database files are created with the postmap(1) or postalias(1) command. +The lookup table name as used in "cdb:table" is the database file name +without the ".cdb" suffix. This feature is available with Postfix 2.2 +and later.
+ +
cidr
+ +
A table that associates values with Classless Inter-Domain +Routing (CIDR) patterns. The table format is described in cidr_table(5). +
+ +
dbm
+ +
An indexed file type based on hashing. This is available only +on systems with support for DBM databases. Public database files +are created with the postmap(1) or postalias(1) command, and private +databases are maintained by Postfix daemons. The lookup table name +as used in "dbm:table" is the database file name without the ".dir" +or ".pag" suffix.
+ +
environ
+ +
The UNIX process environment array. The lookup key is the +variable name. The lookup table name in "environ:table" is ignored. +
+ +
fail
+ +
A table that reliably fails all requests. The lookup table +name is used for logging only. This table exists to simplify Postfix +error tests.
+ +
hash
+ +
An indexed file type based on hashing. This is available only +on systems with support for Berkeley DB databases. Public database +files are created with the postmap(1) or postalias(1) command, and +private databases are maintained by Postfix daemons. The database +name as used in "hash:table" is the database file name without the +".db" suffix.
+ +
inline (read-only)
+ +
A non-shared, in-memory lookup table. Example: "inline:{ +key=value, { key = text with whitespace or comma }}". +Key-value pairs are separated by whitespace or comma; with a key-value +pair inside "{}", whitespace is ignored after the opening "{", +around the "=" between key and value, and before the closing "}". +Inline tables eliminate the +need to create a database file for just a few fixed elements. See +also the static: map type.
+ +
internal
+ +
A non-shared, in-memory hash table. Its content are lost when +a process terminates.
+ +
lmdb
+ +
OpenLDAP LMDB database. This is available only on systems +with support for LMDB databases. Public database files are created +with the postmap(1) or postalias(1) command, and private databases +are maintained by Postfix daemons. The database name as used in +"lmdb:table" is the database file name without the ".lmdb" suffix. +See lmdb_table(5) for details.
+ +
ldap (read-only)
+ +
LDAP database client. Configuration details are given in the +ldap_table(5).
+ +
memcache
+ +
Memcache database client. Configuration details are given in +memcache_table(5).
+ +
mysql (read-only)
+ +
MySQL database client. Configuration details are given in +mysql_table(5).
+ +
netinfo (read-only)
+ +
Netinfo database client.
+ +
nis (read-only)
+ +
NIS database client.
+ +
nisplus (read-only)
+ +
NIS+ database client. Configuration details are given in +nisplus_table(5).
+ +
pcre (read-only)
+ +
A lookup table based on Perl Compatible Regular Expressions. +The file format is described in pcre_table(5). The lookup table +name as used in "pcre:table" is the name of the regular expression +file.
+ +
pipemap (read-only)
+ +
A pipeline of lookup tables. Example: +"pipemap:{type1:name1, ..., +typen:namen}". Each "pipemap:" query is +given to the first table. Each lookup result becomes the query for +the next table in the pipeline, and the last table produces the +final result. When any table lookup produces no result, the pipeline +produces no result. The first and last characters of the "pipemap:" +table name must be "{" and "}". Within these, individual maps are +separated with comma or whitespace.
+ +
pgsql (read-only)
+ +
PostgreSQL database client. Configuration details are given +in pgsql_table(5).
+ +
proxy
+ +
Postfix proxymap(8) client for shared access to Postfix +databases. The lookup table name syntax is "proxy:type:table". +
+ +
randmap (read-only)
+ +
An in-memory table that performs random selection. Example: +"randmap:{result1. ..., resultn}". +Each table query returns a random choice from the specified results. +The first and last characters of the "randmap:" table name must be +"{" and "}". Within these, individual maps are separated with comma +or whitespace. To give a specific result more weight, specify it +multiple times.
+ +
regexp (read-only)
+ +
A lookup table based on regular expressions. The file format +is described in regexp_table(5). The lookup table name as used in +"regexp:table" is the name of the regular expression file.
+ +
sdbm
+ +
An indexed file type based on hashing. This is available only +on systems with support for SDBM databases. Public database files +are created with the postmap(1) or postalias(1) command, and private +databases are maintained by Postfix daemons. The lookup table name +as used in "sdbm:table" is the database file name without the ".dir" +or ".pag" suffix.
+ +
socketmap (read-only)
+ +
Sendmail-style socketmap client. The name of the table is +either inet:host:port:name for a TCP/IP +server, or unix:pathname:name for a UNIX-domain +server. See socketmap_table(5) for details.
+ +
sqlite (read-only)
+ +
SQLite database. Configuration details are given in sqlite_table(5). +
+ +
static (read-only)
+ +
A table that always returns its name as the lookup result. +For example, "static:foobar" always returns the string "foobar" as +lookup result. Specify "static:{ text with whitespace }" +when the result contains whitespace; this form ignores whitespace +after the opening "{" and before the closing "}". See also the +inline: map type.
+ +
tcp
+ +
TCP/IP client. The protocol is described in tcp_table(5). The +lookup table name is "tcp:host:port" where "host" specifies a +symbolic hostname or a numeric IP address, and "port" specifies a +symbolic service name or a numeric port number.
+ +
texthash (read-only)
+ +
A table that produces similar results as hash: files, except +that you don't have to run the postmap(1) command before you can +use the file, and that texthash: does not detect changes after the +file is read. The lookup table name is "texthash:filename", where +the file name is taken literally; no suffix is appended.
+ +
unionmap (read-only)
+ +
A table that sends each query to multiple lookup tables and +that concatenates all found results, separated by comma. The table +name syntax is the same as for pipemap tables.
+ +
unix (read-only)
+ +
A limited view of the UNIX authentication database. The following +tables are implemented: + +
+ +
unix:passwd.byname
+ +
The table is the UNIX password database. The key is a login +name. The result is a password file entry in passwd(5) format. +
+ +
unix:group.byname
+ +
The table is the UNIX group database. The key is a group name. +The result is a group file entry in group(5) format.
+ +
+ +
+ +
+ +

Other lookup table types may be available depending on how +Postfix was built. With some Postfix distributions the list is +dynamically extensible as support for lookup tables is dynamically +linked into Postfix.

+ + + + diff --git a/proto/DB_README.html b/proto/DB_README.html new file mode 100644 index 0000000..0d4fa39 --- /dev/null +++ b/proto/DB_README.html @@ -0,0 +1,242 @@ + + + + + + +Postfix Berkeley DB Howto + + + + + + + +

Postfix Berkeley DB Howto

+ +
+ +

Introduction

+ +

Postfix uses databases of various kinds to store and look up +information. Postfix databases are specified as "type:name". +Berkeley DB implements the Postfix database type "hash" and +"btree". The name of a Postfix Berkeley DB database is the name +of the database file without the ".db" suffix. Berkeley DB databases +are maintained with the postmap(1) command.

+ +

Note: Berkeley DB version 4 is not supported by Postfix versions +before 2.0.

+ +

This document describes:

+ +
    + +

  1. How to build Postfix without Berkeley +DB support even if the system comes with Berkeley DB.

    + +

  2. How to build Postfix on systems that +normally have no Berkeley DB library.

    + +

  3. How to build Postfix on BSD or Linux systems with multiple Berkeley DB +versions.

    + +

  4. How to tweak performance.

    + +

  5. Missing pthread library trouble.

    + +
+ +

Building Postfix without Berkeley +DB support even if the system comes with Berkeley DB

+ +

Note: The following instructions apply to Postfix 2.9 and later.

+ +

Postfix will normally enable Berkeley DB support if the system +is known to have it. To build Postfix without Berkeley DB support, +build the makefiles as follows:

+ +
+
+% make makefiles CCARGS="-DNO_DB"
+% make
+
+
+ +

This will disable support for "hash" and "btree" files.

+ +

Building Postfix on systems that normally have +no Berkeley DB library

+ +

Some UNIXes ship without Berkeley DB support; for historical +reasons these use DBM files instead. A problem with DBM files is +that they can store only limited amounts of data. To build Postfix +with +Berkeley DB support you need to download and install the source +code from http://www.oracle.com/database/berkeley-db/.

+ +

Warning: some Linux system libraries use Berkeley DB, as do +some third-party libraries such as SASL. If you compile Postfix +with a different Berkeley DB implementation, then every Postfix +program will dump core because either the system library, the SASL +library, or Postfix itself ends up using the wrong version.

+ +

The more recent Berkeley DB versions have a compile-time switch, +"--with-uniquename", which renames the symbols so that multiple +versions of Berkeley DB can co-exist in the same application. +Although wasteful, this may be the only way to keep things from +falling apart.

+ +

To build Postfix after you installed the Berkeley DB from +source code, use something like:

+ +
+
+% make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
+    AUXLIBS="-L/usr/local/BerkeleyDB/lib -ldb"
+% make
+
+
+ +

Solaris needs this:

+ +
+
+% make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
+    AUXLIBS="-R/usr/local/BerkeleyDB/lib -L/usr/local/BerkeleyDB/lib -ldb"
+% make
+
+
+ +

The exact pathnames depend on the Berkeley DB version, and on +how it was installed.

+ +

Warning: the file format produced by Berkeley DB version 1 is +not compatible with that of versions 2 and 3 (versions 2 and 3 have +the same format). If you switch between DB versions, then you may +have to rebuild all your Postfix DB files.

+ +

Warning: if you use Berkeley DB version 2 or later, do not +enable DB 1.85 compatibility mode. Doing so would break fcntl file +locking.

+ +

Warning: if you use Perl to manipulate Postfix's Berkeley DB +files, then you need to use the same Berkeley DB version in Perl +as in Postfix.

+ +

Building Postfix on BSD systems with multiple +Berkeley DB versions

+ +

Some BSD systems ship with multiple Berkeley DB implementations. +Normally, Postfix builds with the default DB version that ships +with the system.

+ +

To build Postfix on BSD systems with a non-default DB version, +use a variant of the following commands:

+ +
+
+% make makefiles CCARGS=-I/usr/include/db3 AUXLIBS=-ldb3
+% make
+
+
+ +

Warning: the file format produced by Berkeley DB version 1 is +not compatible with that of versions 2 and 3 (versions 2 and 3 have +the same format). If you switch between DB versions, then you may +have to rebuild all your Postfix DB files.

+ +

Warning: if you use Berkeley DB version 2 or later, do not +enable DB 1.85 compatibility mode. Doing so would break fcntl file +locking.

+ +

Warning: if you use Perl to manipulate Postfix's Berkeley DB +files, then you need to use the same Berkeley DB version in Perl +as in Postfix.

+ +

Building Postfix on Linux systems with multiple +Berkeley DB versions

+ +

Some Linux systems ship with multiple Berkeley DB implementations. +Normally, Postfix builds with the default DB version that ships +with the system.

+ +

Warning: some Linux system libraries use Berkeley DB. If you +compile Postfix with a non-default Berkeley DB implementation, then +every Postfix program will dump core because either the system +library or Postfix itself ends up using the wrong version.

+ +

On Linux, you need to edit the makedefs script in order to +specify a non-default DB library. The reason is that the location +of the default db.h include file changes randomly between vendors +and between versions, so that Postfix has to choose the file for +you.

+ +

Warning: the file format produced by Berkeley DB version 1 is +not compatible with that of versions 2 and 3 (versions 2 and 3 have +the same format). If you switch between DB versions, then you may +have to rebuild all your Postfix DB files.

+ +

Warning: if you use Berkeley DB version 2 or later, do not +enable DB 1.85 compatibility mode. Doing so would break fcntl file +locking.

+ +

Warning: if you use Perl to manipulate Postfix's Berkeley DB +files, then you need to use the same Berkeley DB version in Perl +as in Postfix.

+ +

Tweaking performance

+ +

Postfix provides two configuration parameters that control how +much buffering memory Berkeley DB will use.

+ + + +

Missing pthread library trouble

+ +

When building Postfix fails with:

+ +
+
+undefined reference to `pthread_condattr_setpshared'
+undefined reference to `pthread_mutexattr_destroy'
+undefined reference to `pthread_mutexattr_init'
+undefined reference to `pthread_mutex_trylock'
+
+
+ +

Add the "-lpthread" library to the "make makefiles" command.

+ +
+
+% make makefiles .... AUXLIBS="... -lpthread"
+
+
+ +

More information is available at +http://www.oracle.com/database/berkeley-db/.

+ + + + diff --git a/proto/DEBUG_README.html b/proto/DEBUG_README.html new file mode 100644 index 0000000..2a5b012 --- /dev/null +++ b/proto/DEBUG_README.html @@ -0,0 +1,597 @@ + + + + + + + Postfix Debugging Howto + + + + + + + +

Postfix Debugging Howto

+ +
+ +

Purpose of this document

+ +

This document describes how to debug parts of the Postfix mail +system when things do not work according to expectation. The methods +vary from making Postfix log a lot of detail, to running some daemon +processes under control of a call tracer or debugger.

+ +

The text assumes that the Postfix main.cf and master.cf +configuration files are stored in directory /etc/postfix. You can +use the command "postconf config_directory" to find out the +actual location of this directory on your machine.

+ +

Listed in order of increasing invasiveness, the debugging +techniques are as follows:

+ + + +

Look for obvious signs of trouble

+ +

Postfix logs all failed and successful deliveries to a logfile.

+ + + +

When Postfix does not receive or deliver mail, the first order +of business is to look for errors that prevent Postfix from working +properly:

+ +
+
+% egrep '(warning|error|fatal|panic):' /some/log/file | more
+
+
+ +

Note: the most important message is near the BEGINNING of the +output. Error messages that come later are less useful.

+ +

The nature of each problem is indicated as follows:

+ + + +

Debugging Postfix from inside

+ +

Postfix version 2.1 and later can +produce mail delivery reports for debugging purposes. These reports +not only show sender/recipient addresses after address rewriting +and alias expansion or forwarding, they also show information about +delivery to mailbox, delivery to non-Postfix command, responses +from remote SMTP servers, and so on. +

+ +

Postfix can produce two types of mail delivery reports for +debugging:

+ + + +

These reports contain information that is generated by Postfix +delivery agents. Since these run as daemon processes that cannot +interact with users directly, the result is sent as mail to the +sender of the test message. The format of these reports is practically +identical to that of ordinary non-delivery notifications.

+ +

For a detailed example of a mail delivery status report, see +the debugging +section at the end of the ADDRESS_REWRITING_README document.

+ +

Try turning off chroot operation in master.cf

+ +

A common mistake is to turn on chroot operation in the master.cf +file without going through all the necessary steps to set up a +chroot environment. This causes Postfix daemon processes to fail +due to all kinds of missing files.

+ +

The example below shows an SMTP server that is configured with +chroot turned off:

+ +
+
+/etc/postfix/master.cf:
+    # =============================================================
+    # service type  private unpriv  chroot  wakeup  maxproc command
+    #               (yes)   (yes)   (yes)   (never) (100)
+    # =============================================================
+    smtp      inet  n       -       n       -       -       smtpd
+
+
+ +

Inspect master.cf for any processes that have chroot operation +not turned off. If you find any, save a copy of the master.cf file, +and edit the entries in question. After executing the command +"postfix reload", see if the problem has gone away.

+ +

If turning off chrooted operation made the problem go away, +then congratulations. Leaving Postfix running in this way is +adequate for most sites. If you prefer chrooted operation, see +the Postfix +BASIC_CONFIGURATION_README file for information about how to +prepare Postfix for chrooted operation.

+ +

Verbose logging for specific SMTP +connections

+ +

In /etc/postfix/main.cf, list the remote site name or address +in the debug_peer_list parameter. For example, in order to make +the software log a lot of information to the syslog daemon for +connections from or to the loopback interface:

+ +
+
+/etc/postfix/main.cf:
+    debug_peer_list = 127.0.0.1
+
+
+ +

You can specify one or more hosts, domains, addresses or +net/masks. To make the change effective immediately, execute the +command "postfix reload".

+ +

Record the SMTP session with a network sniffer

+ +

This example uses tcpdump. In order to record a conversation +you need to specify a large enough buffer with the "-s" +option or else you will miss some or all of the packet payload. +

+ +
+
+# tcpdump -w /file/name -s 0 host example.com and port 25
+
+
+ +

Older tcpdump versions don't support "-s 0"; in that case, +use "-s 2000" instead.

+ +

Run this for a while, stop with Ctrl-C when done. To view the +data use a binary viewer, ethereal, or good old less. +

+ +

Making Postfix daemon programs more verbose

+ +

Append one or more "-v" options to selected daemon +definitions in /etc/postfix/master.cf and type "postfix reload". +This will cause a lot of activity to be logged to the syslog daemon. +For example, to make the Postfix SMTP server process more verbose:

+ +
+
+/etc/postfix/master.cf:
+    smtp      inet  n       -       n       -       -       smtpd -v
+
+
+ +

To diagnose problems with address rewriting specify a "-v" +option for the cleanup(8) and/or trivial-rewrite(8) daemon, and to +diagnose problems with mail delivery specify a "-v" +option for the qmgr(8) or oqmgr(8) queue manager, or for the lmtp(8), +local(8), pipe(8), smtp(8), or virtual(8) delivery agent.

+ +

Manually tracing a Postfix daemon process

+ +

Many systems allow you to inspect a running process with a +system call tracer. For example:

+ +
+
+# trace -p process-id (SunOS 4)
+# strace -p process-id (Linux and many others)
+# truss -p process-id (Solaris, FreeBSD)
+# ktrace -p process-id (generic 4.4BSD)
+
+
+ +

Even more informative are traces of system library calls. +Examples:

+ +
+
+# ltrace -p process-id (Linux, also ported to FreeBSD and BSD/OS)
+# sotruss -p process-id (Solaris)
+
+
+ +

See your system documentation for details.

+ +

Tracing a running process can give valuable information about +what a process is attempting to do. This is as much information as +you can get without running an interactive debugger program, as +described in a later section.

+ +

Automatically tracing a Postfix daemon +process

+ +

Postfix can attach a call tracer whenever a daemon process +starts. Call tracers come in several kinds.

+ +
    + +

  1. System call tracers such as trace, truss, +strace, or ktrace. These show the communication +between the process and the kernel.

    + +

  2. Library call tracers such as sotruss and ltrace. +These show calls of library routines, and give a better idea of +what is going on within the process.

    + +
+ +

Append a -D option to the suspect command in +/etc/postfix/master.cf, for example:

+ +
+
+/etc/postfix/master.cf:
+    smtp      inet  n       -       n       -       -       smtpd -D
+
+
+ +

Edit the debugger_command definition in /etc/postfix/main.cf +so that it invokes the call tracer of your choice, for example: +

+ +
+
+/etc/postfix/main.cf:
+    debugger_command =
+         PATH=/bin:/usr/bin:/usr/local/bin;
+         (truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5
+
+
+ +

Type "postfix reload" and watch the logfile.

+ +

Running daemon programs with the interactive +ddd debugger

+ +

If you have X Windows installed on the Postfix machine, then +an interactive debugger such as ddd can be convenient. +

+ +

Edit the debugger_command definition in /etc/postfix/main.cf +so that it invokes ddd:

+ +
+
+/etc/postfix/main.cf:
+    debugger_command =
+         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
+         ddd $daemon_directory/$process_name $process_id & sleep 5
+
+
+ +

Be sure that gdb is in the command search path, and +export XAUTHORITY so that X access control works, for example: +

+ +
+
+% setenv XAUTHORITY ~/.Xauthority (csh syntax)
+$ export XAUTHORITY=$HOME/.Xauthority (sh syntax)
+
+
+ +

Append a -D option to the suspect daemon definition in +/etc/postfix/master.cf, for example:

+ +
+
+/etc/postfix/master.cf:
+    smtp      inet  n       -       n       -       -       smtpd -D
+
+
+ +

Stop and start the Postfix system. This is necessary so that +Postfix runs with the proper XAUTHORITY and DISPLAY +settings.

+ +

Whenever the suspect daemon process is started, a debugger +window pops up and you can watch in detail what happens.

+ +

Running daemon programs with the interactive +gdb debugger

+ +

If you have the screen command installed on the Postfix machine, then +you can run an interactive debugger such as gdb as follows.

+ +

Edit the debugger_command definition in /etc/postfix/main.cf +so that it runs gdb inside a detached screen session: +

+ +
+
+/etc/postfix/main.cf:
+    debugger_command =
+        PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH; HOME=/root;
+        export HOME; screen -e^tt -dmS $process_name gdb
+        $daemon_directory/$process_name $process_id & sleep 2
+
+
+ +

Be sure that gdb is in the command search path.

+ +

Append a -D option to the suspect daemon definition in +/etc/postfix/master.cf, for example:

+ +
+
+/etc/postfix/master.cf:
+    smtp      inet  n       -       n       -       -       smtpd -D
+
+
+ +

Execute the command "postfix reload" and wait until a +daemon process is started (you can see this in the maillog file). +

+ +

Then attach to the screen, and debug away:

+ +
+
+# HOME=/root screen -r
+gdb) continue
+gdb) where
+
+
+ +

Running daemon programs under a non-interactive +debugger

+ +

If you do not have X Windows installed on the Postfix machine, +or if you are not familiar with interactive debuggers, then you +can try to run gdb in non-interactive mode, and have it +print a stack trace when the process crashes.

+ +

Edit the debugger_command definition in /etc/postfix/main.cf +so that it invokes the gdb debugger:

+ +
+
+/etc/postfix/main.cf:
+    debugger_command =
+        PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo
+        where; sleep 8640000) | gdb $daemon_directory/$process_name 
+        $process_id 2>&1
+        >$config_directory/$process_name.$process_id.log & sleep 5
+
+
+ +

Append a -D option to the suspect daemon in +/etc/postfix/master.cf, for example:

+ +
+
+/etc/postfix/master.cf:
+    smtp      inet  n       -       n       -       -       smtpd -D
+
+
+ +

Type "postfix reload" to make the configuration changes +effective.

+ +

Whenever a suspect daemon process is started, an output file +is created, named after the daemon and process ID (for example, +smtpd.12345.log). When the process crashes, a stack trace (with +output from the "where" command) is written to its logfile. +

+ +

Unreasonable behavior

+ +

Sometimes the behavior exhibited by Postfix just does not match the +source code. Why can a program deviate from the instructions given +by its author? There are two possibilities.

+ + + +

In both cases, the program being executed is not the program +that was supposed to be executed, so anything could happen.

+ +

There is a third possibility:

+ + + +

Hardware-related failures usually do not reproduce in exactly +the same way after power cycling and rebooting the system. There's +little Postfix can do about bad hardware. Be sure to use hardware +that at the very least can detect memory errors. Otherwise, Postfix +will just be waiting to be hit by a bit error. Critical systems +deserve real hardware.

+ +

When a compiler makes an error, the problem can be reproduced +whenever the resulting program is run. Compiler errors are most +likely to happen in the code optimizer. If a problem is reproducible +across power cycles and system reboots, it can be worthwhile to +rebuild Postfix with optimization disabled, and to see if optimization +makes a difference.

+ +

In order to compile Postfix with optimizations turned off:

+ +
+
+% make tidy
+% make makefiles OPT=
+
+
+ +

This produces a set of Makefiles that do not request compiler +optimization.

+ +

Once the makefiles are set up, build the software:

+ +
+
+% make
+% su
+Password:
+# make install
+
+
+ +

If the problem goes away, then it is time to ask your vendor +for help.

+ +

Reporting problems to postfix-users@postfix.org

+ +

The people who participate on postfix-users@postfix.org +are very helpful, especially if YOU provide them with sufficient +information. Remember, these volunteers are willing to help, but +their time is limited.

+ +

When reporting a problem, be sure to include the following +information.

+ + + + + + diff --git a/proto/DSN_README.html b/proto/DSN_README.html new file mode 100644 index 0000000..456862b --- /dev/null +++ b/proto/DSN_README.html @@ -0,0 +1,156 @@ + + + + + + +Postfix DSN Support + + + + + + + +

Postfix +DSN Support

+ +
+ +

Introduction

+ +

Postfix version 2.3 introduces support for Delivery Status +Notifications as described in RFC 3464. This gives senders control +over successful and failed delivery notifications.

+ +

Specifically, DSN support gives an email sender the ability to +specify:

+ + + +

The implementation of DSN support involves extra parameters to +the SMTP MAIL FROM and RCPT TO commands, as well as two Postfix +sendmail command line options that provide a sub-set of the functions +of the extra SMTP command parameters.

+ +

This document has information on the following topics:

+ + + +

Restricting the scope of "success" notifications

+ +

Just like reports of undeliverable mail, DSN reports of +successful delivery can give away more information about the +internal infrastructure than desirable. Unfortunately, disallowing +"success" notification requests requires disallowing other DSN +requests as well. The RFCs do not offer the option to negotiate +feature subsets.

+ +

This is not as bad as it sounds. When you turn off DSN for +remote inbound mail, remote senders with DSN support will still be +informed that their mail reached your Postfix gateway successfully; +they just will not get successful delivery notices from your internal +systems. Remote senders lose very little: they can no longer specify +how Postfix should report delayed or failed delivery.

+ +

Use the smtpd_discard_ehlo_keyword_address_maps feature if you +wish to allow DSN requests from trusted clients but not from random +strangers (see below for how to turn this off for all clients): +

+ +
+
+/etc/postfix/main.cf:
+    smtpd_discard_ehlo_keyword_address_maps = 
+        cidr:/etc/postfix/esmtp_access
+
+/etc/postfix/esmtp_access:
+    # Allow DSN requests from local subnet only
+    192.168.0.0/28      silent-discard
+    0.0.0.0/0           silent-discard, dsn
+    ::/0                silent-discard, dsn
+
+
+ +

If you want to disallow all use of DSN requests from the network, +use the smtpd_discard_ehlo_keywords feature:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_discard_ehlo_keywords = silent-discard, dsn
+
+
+ +

Postfix sendmail command-line interface

+ +

Postfix has two Sendmail-compatible command-line options for +DSN support.

+ + + +

Postfix VERP support compatibility

+ +

With Postfix versions before 2.3, the sendmail(1) command uses +the -V command-line option to request VERP-style delivery. In order +to request VERP style delivery with Postfix 2.3 and later, you must +specify -XV instead of -V.

+ +

The Postfix 2.3 sendmail(1) command will recognize if you try +to use -V for VERP-style delivery. It will do the right thing and +will remind you of the new syntax.

+ + + + diff --git a/proto/ETRN_README.html b/proto/ETRN_README.html new file mode 100644 index 0000000..5f9bf7f --- /dev/null +++ b/proto/ETRN_README.html @@ -0,0 +1,374 @@ + + + + + + +Postfix ETRN Howto + + + + + + + +

Postfix ETRN Howto

+ +
+ +

Purpose of the Postfix fast ETRN service

+ +

The SMTP ETRN command was designed for sites that have intermittent +Internet connectivity. With ETRN, a site can tell the mail server +of its provider to "Please deliver all my mail now". The SMTP server +searches the queue for mail to the customer, and delivers that mail +by connecting to the customer's SMTP server. The mail is +not delivered via the connection that was used for sending ETRN. +

+ +

As of version 1.0, Postfix has a fast ETRN implementation that +does not require Postfix to examine every queue file. Instead, +Postfix maintains a record of what queue files contain mail for +destinations that are configured for ETRN service. ETRN service +is no longer available for domains that aren't configured for the +service.

+ +

This document provides information on the following topics:

+ + + +

Other documents with information on this subject:

+ + + +

Using the Postfix fast ETRN service

+ +

The following is an example SMTP session that shows how an SMTP +client requests the ETRN service. Client commands are shown in bold +font.

+ +
+
+220 my.server.tld ESMTP Postfix
+HELO my.client.tld
+250 Ok
+ETRN some.customer.domain
+250 Queuing started
+QUIT
+221 Bye
+
+
+ +

As mentioned in the introduction, the mail is delivered by +connecting to the customer's SMTP server; it is not sent over +the connection that was used to send the ETRN command.

+ +

The Postfix operator can request delivery for a specific customer +by using the command "sendmail -qRdestination" and, with +Postfix version 1.1 and later, "postqueue -sdestination". +Access to this feature is controlled with the authorized_flush_users +configuration parameter (Postfix version 2.2 and later). +

+ +

How Postfix fast ETRN works

+ +

When a Postfix delivery agent decides that mail must be delivered +later, it sends the destination domain name and the queue file name +to the flush(8) daemon which maintains per-destination logfiles +with file names of queued mail. These logfiles are kept below +$queue_directory/flush. Per-destination logfiles are maintained +only for destinations that are listed with the $fast_flush_domains +parameter and that have syntactically valid domain names.

+ +
+ + + + + + + + + + + + + + + + + +
Postfix
+delivery
agent		 -(domain, queue ID)-> Postfix
+flush
daemon		 -(queue ID)-> One logfile
+per eligible
domain
+ +
+ +

When Postfix receives a request to "deliver mail for a domain +now", the flush(8) daemon moves all deferred queue files that are +listed for that domain to the incoming queue, and requests that +the queue manager deliver them. In order to force delivery, the +queue manager temporarily ignores the lists of undeliverable +destinations: the volatile in-memory list of dead domains, and +the list of message delivery transports specified with the +defer_transports configuration parameter.

+ +

Postfix fast ETRN service limitations

+ +

The design of the flush(8) server and of the flush queue +introduce a few limitations that should not be an issue unless you +want to turn on fast ETRN service for every possible destination. +

+ + + +

Configuring the Postfix fast ETRN service

+ +

The behavior of the flush(8) daemon is controlled by parameters +in the main.cf configuration file.

+ +

By default, Postfix "fast ETRN" service is available only for +destinations that Postfix is willing to relay mail to:

+ +
+
+/etc/postfix/main.cf:
+    fast_flush_domains = $relay_domains
+    smtpd_etrn_restrictions = permit_mynetworks, reject
+
+
+ +

Notes:

+ + + +

To enable "fast ETRN" for some other destination, specify:

+ +
+
+/etc/postfix/main.cf:
+    fast_flush_domains = $relay_domains, some.other.domain
+
+
+ +

To disable "fast ETRN", so that Postfix rejects all ETRN requests +and so that it maintains no per-destination logfiles, specify:

+ +
+
+/etc/postfix/main.cf:
+    fast_flush_domains =
+
+
+ +

Configuring a domain for ETRN service only

+ +

While an "ETRN" customer is off-line, Postfix will make +spontaneous attempts to deliver mail to it. These attempts are +separated in time by increasing time intervals, ranging from +$minimal_backoff_time to $maximal_backoff_time, and should not be +a problem unless a lot of mail is queued.

+ +

To prevent Postfix from making spontaneous delivery attempts +you can configure Postfix to always defer mail for the "ETRN" +customer. Mail is delivered only after the ETRN command or with +"sendmail -q", with "sendmail -qRdomain", or with "postqueue +-sdomain"(Postfix version 1.1 and later only),

+ +

In the example below we configure an "etrn-only" delivery +transport which is simply a duplicate of the "smtp" and "relay" +mail delivery transports. The only difference is that mail destined +for this delivery transport is deferred as soon as it arrives. +

+ +
+
+ 1 /etc/postfix/master.cf:
+ 2   # =============================================================
+ 3   # service type  private unpriv  chroot  wakeup  maxproc command
+ 4   #               (yes)   (yes)   (yes)   (never) (100)
+ 5   # =============================================================
+ 6   smtp      unix  -       -       n       -       -       smtp
+ 7   relay     unix  -       -       n       -       -       smtp
+ 8   etrn-only unix  -       -       n       -       -       smtp
+ 9 
+10 /etc/postfix/main.cf:
+11   relay_domains = customer.tld ...other domains...
+12   defer_transports = etrn-only
+13   transport_maps = hash:/etc/postfix/transport
+14
+15 /etc/postfix/transport:
+16   customer.tld     etrn-only:[mailhost.customer.tld]
+
+
+ +

Translation:

+ + + +

Testing the Postfix fast ETRN service

+ +

By default, "fast ETRN" service is enabled for all domains that +match $relay_domains. If you run Postfix with "fast ETRN" service +for the very first time, you need to run "sendmail -q" once +in order to populate the per-site deferred mail logfiles. If you +omit this step, no harm is done. The logfiles will eventually +become populated as Postfix routinely attempts to deliver delayed +mail, but that will take a couple hours. After the "sendmail +-q" command has completed all delivery attempts (this can take +a while), you're ready to test the "fast ETRN" service. + +

To test the "fast ETRN" service, telnet to the Postfix SMTP +server from a client that is allowed to execute ETRN commands (by +default, that's every client), and type the commands shown in +boldface:

+ +
+
+220 my.server.tld ESMTP Postfix
+HELO my.client.tld
+250 Ok
+ETRN some.customer.domain
+250 Queuing started
+
+
+ +

where "some.customer.domain" is the name of a domain that has +a non-empty logfile somewhere under $queue_directory/flush.

+ +

In the maillog file, you should immediately see a couple of +logfile records, as evidence that the queue manager has opened +queue files:

+ +
+
+Oct  2 10:51:19 myhostname postfix/qmgr[51999]: 682E8440A4:
+    from=<whatever>, size=12345, nrcpt=1 (queue active)
+Oct  2 10:51:19 myhostname postfix/qmgr[51999]: 02249440B7:
+    from=<whatever>, size=4711, nrcpt=1 (queue active)
+
+
+ +

What happens next depends on whether the destination is reachable. +If it's not reachable, the mail queue IDs will be added back to +the some.customer.domain logfile under $queue_directory/flush. +

+ +

Repeat the exercise with some other destination that your server +is willing to relay to (any domain listed in $relay_domains), but +that has no mail queued. The text in bold face stands for the +commands that you type:

+ +
+
+220 my.server.tld ESMTP Postfix
+HELO my.client.tld
+250 Ok
+ETRN some.other.customer.domain
+250 Queuing started
+
+
+ +

This time, the "ETRN"" command should trigger NO mail deliveries +at all. If this triggers delivery of all mail, then you used the +wrong domain name, or "fast ETRN" service is turned off.

+ +

Finally, repeat the exercise with a destination that your mail +server is not willing to relay to. It does not matter if your +server has mail queued for that destination.

+ +
+
+220 my.server.tld ESMTP Postfix
+HELO my.client.tld
+250 Ok
+ETRN not.a.customer.domain
+459 <not.a.customer.domain>: service unavailable
+
+
+ +

In this case, Postfix should reject the request +as shown above.

+ + + + diff --git a/proto/FILTER_README.html b/proto/FILTER_README.html new file mode 100644 index 0000000..522e728 --- /dev/null +++ b/proto/FILTER_README.html @@ -0,0 +1,980 @@ + + + + + + +Postfix After-Queue Content Filter + + + + + + + +

Postfix After-Queue Content Filter

+ +
+ +

Introduction

+ +

This document requires Postfix version 2.1 or later.

+ +

Normally, Postfix receives mail, stores it in the mail queue +and then delivers it. With the external content filter described +here, mail is filtered AFTER it is queued. This approach decouples +mail receiving processes from mail filtering processes, and gives +you maximal control over how many filtering processes you are +willing to run in parallel.

+ +

The after-queue content filter is meant to be used as follows:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Network or
local users 		-> + Postfix
queue 		-> + Content
filter 		-> + Postfix
queue 		-> + Network or
local mailbox
+ +
+ +

This document describes implementations that use a single +Postfix instance for everything: receiving, filtering and delivering +mail. Applications that use two separate Postfix instances will +be covered by a later version of this document.

+ +

The after-queue content filter is not to be confused with the +approaches described in the SMTPD_PROXY_README or MILTER_README +documents, +where incoming SMTP mail is filtered BEFORE it is stored into the +Postfix queue.

+ +

This document describes two approaches to content filter +all email, as well as several options to filter mail selectively:

+ + + + +

Principles of operation

+ +

An after-queue content filter receives unfiltered mail from Postfix +(as described further below) and can do one of the following:

+ +
    + +

  1. Re-inject the mail back into Postfix, perhaps after changing + content and/or destination.

    + +

  2. Discard or quarantine the mail.

    + +

  3. Reject the mail (by sending a suitable status code back to + Postfix). Postfix will send the mail back to the sender address.

    + +
+ +

NOTE: in this time of mail worms and forged spam, it is a VERY +BAD IDEA to send viruses back to the sender address, because the +sender address is almost certainly not the originator. It is better +to discard known viruses, and to quarantine material that is +suspect so that a human can decide what to do with it.

+ +

Simple content filter example

+ +

The first example is simple to set up, but has major limitations +that will be addressed in a second example. Postfix receives +unfiltered mail from the network with the smtpd(8) server, and +delivers unfiltered mail to a content filter with the Postfix +pipe(8) delivery agent. The content filter injects filtered mail +back into Postfix with the Postfix sendmail(1) command, so that +Postfix can deliver it to the final destination.

+ +

This means that mail submitted via the Postfix sendmail(1) +command cannot be content filtered.

+ +

In the figure below, names followed by a number represent +Postfix commands or daemon programs. See the OVERVIEW +document for an introduction to the Postfix architecture.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Unfiltered

 ->

 + smtpd(8)

pickup(8) 		>- + cleanup(8) -> + qmgr(8)
Postfix
queue 		-< + local(8)
smtp(8)
pipe(8) 		->
+ ->
 Filtered
Filtered
+
^
| 		|
v
+ maildrop
+ queue 		<- Postfix
+ postdrop(1) 		<- Postfix
+ sendmail(1) 		<- Content +
filter
+ +
+ +

The content filter can be a simple shell script like this:

+ +
+
+ 1 #!/bin/sh
+ 2 
+ 3 # Simple shell-based filter. It is meant to be invoked as follows:
+ 4 #       /path/to/script -f sender recipients...
+ 5 
+ 6 # Localize these. The -G option does nothing before Postfix 2.3.
+ 7 INSPECT_DIR=/var/spool/filter
+ 8 SENDMAIL="/usr/sbin/sendmail -G -i" # NEVER NEVER NEVER use "-t" here.
+ 9 
+10 # Exit codes from <sysexits.h>
+11 EX_TEMPFAIL=75
+12 EX_UNAVAILABLE=69
+13 
+14 # Clean up when done or when aborting.
+15 trap "rm -f in.$$" 0 1 2 3 15
+16 
+17 # Start processing.
+18 cd $INSPECT_DIR || {
+19     echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
+20 
+21 cat >in.$$ || { 
+22     echo Cannot save mail to file; exit $EX_TEMPFAIL; }
+23 
+24 # Specify your content filter here.
+25 # filter <in.$$ || {
+26 #   echo Message content rejected; exit $EX_UNAVAILABLE; }
+27 
+28 $SENDMAIL "$@" <in.$$
+29 
+30 exit $?
+
+
+ +

Notes:

+ + + +

I suggest that you first run this script by hand until you are +satisfied with the results. Run it with a real message (headers+body) +as input:

+ +
+
+% /path/to/script -f sender -- recipient... <message-file
+
+
+ +

Once you're satisfied with the content filtering script:

+ + + +

Simple content filter performance

+ +

With the shell script as shown above you will lose a factor of +four in Postfix performance for transit mail that arrives and leaves +via SMTP. You will lose another factor in transit performance for +each additional temporary file that is created and deleted in the +process of content filtering. The performance impact is less for +mail that is submitted or delivered locally, because such deliveries +are already slower than SMTP transit mail.

+ +

Simple content filter limitations

+ +

The problem with content filters like the one above is that +they are not very robust. The reason is that the software does not +talk a well-defined protocol with Postfix. If the filter shell +script aborts because the shell runs into some memory allocation +problem, the script will not produce a nice exit status as defined +in the file /usr/include/sysexits.h. Instead of going to the +deferred queue, mail will bounce. The same lack of robustness can +happen when the content filtering software itself runs into a +resource problem.

+ +

The simple content filter method is not suitable for content +filter actions that are invoked via header_checks or body_checks +patterns. These patterns will be applied again after mail is +re-injected with the Postfix sendmail command, resulting in a mail +filtering loop. The advanced content filtering method (see below) +makes it possible to turn off header_checks or body_checks patterns +for filtered mail.

+ +

Turning off the simple content filter

+ +

To turn off "simple" content filtering:

+ + + +

Advanced content filter example

+ +

The second example is more complex, but can give better +performance, and is less likely to bounce mail when the machine +runs into some resource problem. This content filter receives +unfiltered mail with SMTP on localhost port 10025, and sends filtered +mail back into Postfix with SMTP on localhost port 10026.

+ +

For non-SMTP capable content filtering software, Bennett Todd's +SMTP proxy implements a nice PERL/SMTP content filtering framework. +See: http://bent.latency.net/smtpprox/.

+ +

In the figure below, names followed by a number represent +Postfix commands or daemon programs. See the OVERVIEW +document for an introduction to the Postfix architecture.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Unfiltered

+ Unfiltered		 ->

+ -> 		+ smtpd(8)

pickup(8) 		>- + cleanup(8) -> + qmgr(8)
Postfix
queue 		-< + smtp(8)

local(8) 		->

+ -> 		Filtered

+ Filtered
^
| 		|
v
+ smtpd(8)
10026 		+ smtp(8)
^
| 		|
v
content filter 10025
+ +
+ +

The example given here filters all mail, including mail that +arrives via SMTP and mail that is locally submitted via the Postfix +sendmail command (local submissions enter Postfix via the pickup(8) +server; to keep the figure simple we omit local submission details). +See examples near the end of this document for +how to exclude local users from filtering, or how to configure a +destination dependent content filter.

+ +

You can expect to lose about a factor of two in Postfix +performance for mail that arrives and leaves via SMTP, provided +that the content filter creates no temporary files. Each temporary +file created by the content filter adds another factor to the +performance loss.

+ +

Advanced content filter: requesting that all mail is filtered

+ +

To enable the advanced content filter method for all mail, +specify in main.cf:

+ +
+
+/etc/postfix/main.cf:
+    content_filter = scan:localhost:10025
+    receive_override_options = no_address_mappings
+
+
+ + + +

Advanced content filter: sending unfiltered mail to the content +filter

+ +

In this example, "scan" is an instance of the Postfix SMTP +client with slightly different configuration parameters. This is +how one would set up the service in the Postfix master.cf file: +

+ +
+
+/etc/postfix/master.cf:
+    # =============================================================
+    # service type  private unpriv  chroot  wakeup  maxproc command
+    #               (yes)   (yes)   (yes)   (never) (100)
+    # =============================================================
+    scan      unix  -       -       n       -       10      smtp
+        -o smtp_send_xforward_command=yes
+        -o disable_mime_output_conversion=yes
+        -o smtp_generic_maps=
+
+
+ + + +

Advanced content filter: running the content filter

+ +

The content filter can be set up with the Postfix spawn service, +which is the Postfix equivalent of inetd. For example, to instantiate +up to 10 content filtering processes on localhost port 10025:

+ +
+
+/etc/postfix/master.cf:
+    # ===================================================================
+    # service       type  private unpriv  chroot  wakeup  maxproc command
+    #                     (yes)   (yes)   (yes)   (never) (100)
+    # ===================================================================
+    localhost:10025 inet  n       n       n       -       10      spawn
+        user=filter argv=/path/to/filter localhost 10026
+
+
+ + + +

If you want to have your filter listening on port localhost:10025 +instead of Postfix, then you must run your filter as a stand-alone +program, and must not use the Postfix spawn service.

+ +

Advanced filter: injecting mail back into Postfix

+ +

The job of the content filter is to either bounce mail with a +suitable diagnostic, or to feed the mail back into Postfix through +a dedicated listener on port localhost 10026.

+ +

The simplest content filter just copies SMTP commands and data +between its inputs and outputs. If it has a problem, all it has to +do is to reply to an input of `.' from Postfix with `550 content +rejected', and to disconnect without sending `.' on the connection +that injects mail back into Postfix.

+ +
+
+/etc/postfix/master.cf:
+    # ===================================================================
+    # service       type  private unpriv  chroot  wakeup  maxproc command
+    #                     (yes)   (yes)   (yes)   (never) (100)
+    # ===================================================================
+    localhost:10026 inet  n       -       n       -       10      smtpd
+        -o content_filter= 
+        -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
+        -o smtpd_helo_restrictions=
+        -o smtpd_client_restrictions=
+        -o smtpd_sender_restrictions=
+        # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+        -o smtpd_relay_restrictions=
+        -o smtpd_recipient_restrictions=permit_mynetworks,reject
+        -o mynetworks=127.0.0.0/8
+        -o smtpd_authorized_xforward_hosts=127.0.0.0/8
+
+
+ + + +

Advanced content filter performance

+ +

With the "sandwich" approach to content filtering described +here, it is important to match the filter concurrency to the +available CPU, memory and I/O resources. Too few content filter +processes and mail accumulates in the active queue even with low +traffic volume; too much concurrency and Postfix ends up deferring +mail destined for the content filter because processes fail due to +insufficient resources.

+ +

Currently, content filter performance tuning is a process of +trial and error; analysis is handicapped because filtered and +unfiltered messages share the same queue. As mentioned in the +introduction of this document, content filtering with multiple +Postfix instances will be covered in a future version.

+ +

Turning off the advanced content filter

+ +

To turn off "advanced" content filtering:

+ + + +

Filtering mail from outside users only

+ +

The easiest approach is to configure ONE Postfix instance with +multiple SMTP server IP addresses in master.cf:

+ + + +

After this, you can follow the same procedure as outlined in +the "advanced" or "simple" content filtering examples above, except +that you must not specify "content_filter" or "receive_override_options" +in the main.cf file.

+ +

Different filters for different +domains

+ +

If you are an MX service provider and want to apply different +content filters for different domains, you can configure ONE Postfix +instance with multiple SMTP server IP addresses in master.cf. Each +address provides a different content filter service.

+ +
+
+/etc/postfix.master.cf:
+    # =================================================================
+    # service     type  private unpriv  chroot  wakeup  maxproc command
+    #                   (yes)   (yes)   (yes)   (never) (100)
+    # =================================================================
+    # SMTP service for domains that are filtered with service1:dest1
+    1.2.3.4:smtp  inet  n       -       n       -       -       smtpd
+        -o content_filter=service1:dest1 
+        -o receive_override_options=no_address_mappings
+
+    # SMTP service for domains that are filtered with service2:dest2
+    1.2.3.5:smtp  inet  n       -       n       -       -       smtpd
+        -o content_filter=service2:dest2
+        -o receive_override_options=no_address_mappings
+
+
+ +

After this, you can follow the same procedure as outlined in +the "advanced" or "simple" content filtering examples above, except +that you must not specify "content_filter" or "receive_override_options" +in the main.cf file.

+ +

Set up MX records in the DNS that route each domain to the +proper SMTP server instance.

+ +

FILTER actions in access or header/body +tables

+ +

The above filtering configurations are static. Mail that follows +a given path is either always filtered or it is never filtered. As +of Postfix 2.0 you can also turn on content filtering on the fly. +

+ +

To turn on content filtering with an access(5) table rule:

+ +
+
+/etc/postfix/access:
+    whatever       FILTER foo:bar
+
+
+ +

To turn on content filtering with a header_checks(5) or +body_checks(5) table pattern:

+ +
+
+/etc/postfix/header_checks:
+    /whatever/     FILTER foo:bar
+
+
+ +

You can do this in smtpd access maps as well as the cleanup +server's header/body_checks. This feature must be used with great +care: you must disable all the UCE features in the after-filter +smtpd and cleanup daemons or else you will have a content filtering +loop.

+ +

Limitations:

+ + + + + + diff --git a/proto/FORWARD_SECRECY_README.html b/proto/FORWARD_SECRECY_README.html new file mode 100644 index 0000000..eee8b09 --- /dev/null +++ b/proto/FORWARD_SECRECY_README.html @@ -0,0 +1,717 @@ + + + + + + +TLS Forward Secrecy in Postfix + + + + + + + +

+TLS Forward Secrecy in Postfix +

+ +
+ +

Warning

+ +

Forward secrecy does not protect against active attacks such +as forged DNS replies or forged TLS server certificates. If such +attacks are a concern, then the SMTP client will need to authenticate +the remote SMTP server in a sufficiently-secure manner. For example, +by the fingerprint of a (CA or leaf) public key or certificate. +Conventional PKI relies on many trusted parties and is easily +subverted by a state-funded adversary.

+ +

Overview

+ +

Postfix supports forward secrecy of TLS network communication +since version 2.2. This support was adopted from Lutz Jänicke's +"Postfix TLS patch" for earlier Postfix versions. This document +will focus on TLS Forward Secrecy in the Postfix SMTP client and +server. See TLS_README for a general +description of Postfix TLS support.

+ +

Topics covered in this document:

+ + + +

What is Forward Secrecy

+ +

The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy") +is used to describe security protocols in which the confidentiality +of past traffic is not compromised when long-term keys used by either +or both sides are later disclosed.

+ +

Forward secrecy is accomplished by negotiating session keys +using per-session cryptographically-strong random numbers that are +not saved, and signing the exchange with long-term authentication +keys. Later disclosure of the long-term keys allows impersonation +of the key holder from that point on, but not recovery of prior +traffic, since with forward secrecy, the discarded random key +agreement inputs are not available to the attacker.

+ +

Forward secrecy is only "perfect" when brute-force attacks on +the key agreement algorithm are impractical even for the best-funded +adversary and the random-number generators used by both parties are +sufficiently strong. Otherwise, forward secrecy leaves the attacker +with the challenge of cracking the key-agreement protocol, which +is likely quite computationally intensive, but may be feasible for +sessions of sufficiently high value. Thus forward secrecy places +cost constraints on the efficacy of bulk surveillance, recovering +all past traffic is generally infeasible, and even recovery of +individual sessions may be infeasible given a sufficiently-strong +key agreement method.

+ +

Forward Secrecy in TLS

+ +

Early implementations of the SSL protocol do not provide forward +secrecy (some provide it only with artificially-weakened "export" +cipher suites, but we will ignore those here). The client +sends a random "pre-master secret" to the server encrypted with the +server's RSA public key. The server decrypts this with its private +key, and uses it together with other data exchanged in the clear +to generate the session key. An attacker with access to the server's +private key can perform the same computation at any later time. +The TLS library in Windows XP and Windows Server 2003 only supported +cipher suites of this type, and Exchange 2003 servers largely do +not support forward secrecy.

+ +

Later revisions to the TLS protocol introduced forward-secrecy +cipher suites in which the client and server implement a key exchange +protocol based on ephemeral secrets. Sessions encrypted with one +of these newer cipher suites are not compromised by future disclosure +of long-term authentication keys.

+ +

The key-exchange algorithms used for forward secrecy require +the TLS server to designate appropriate "parameters" consisting of a +mathematical "group" and an element of that group called a "generator". +Presently, there are two flavors of "groups" that work with PFS:

+ + + +

It is not essential to know what these are, but one does need +to know that OpenSSL supports EECDH with version 1.0.0 or later. +Thus the configuration parameters related to Elliptic-Curve forward +secrecy are available when Postfix is linked with OpenSSL ≥ 1.0.0 +(provided EC support has not been disabled by the vendor, as in +some versions of RedHat Linux).

+ +

Elliptic curves used in cryptography are typically identified +by a "name" that stands for a set of well-known parameter values, +and it is these "names" (or associated ASN.1 object identifiers) +that are used in the TLS protocol. On the other hand, with TLS there +are no specially designated prime field groups, so each server is +free to select its own suitably-strong prime and generator.

+ +

Forward Secrecy in the Postfix SMTP Server

+ +

The Postfix ≥ 2.2 SMTP server supports forward secrecy in +its default configuration. If the remote SMTP client prefers cipher +suites with forward secrecy, then the traffic between the server +and client will resist decryption even if the server's long-term +authentication keys are later compromised.

+ +

Some remote SMTP clients may support forward secrecy, but prefer +cipher suites without forward secrecy. In that case, Postfix +≥ 2.8 could be configured to ignore the client's preference with +the main.cf setting "tls_preempt_cipherlist = yes". However, this +will likely cause interoperability issues with older Exchange servers +and is not recommended for now.

+ +

EDH Server support

+ +

Postfix ≥ 2.2 support 1024-bit-prime EDH out of the box, +with no additional configuration, but you may want to override the +default prime to be 2048 bits long, and you may want to regenerate +your primes periodically. See the quick-start +section for details. With Postfix ≥ 3.1 the out of the box +(compiled-in) EDH prime size is 2048 bits.

+ +

With prime-field EDH, OpenSSL wants the server to provide +two explicitly-selected (prime, generator) combinations. One for +the now long-obsolete "export" cipher suites, and another for +non-export cipher suites. Postfix has two such default combinations +compiled in, but also supports explicitly-configured overrides. +

+ + + +

As of mid-2015, SMTP clients are starting to reject TLS +handshakes with primes smaller than 2048 bits. Each site needs to +determine which prime size works best for the majority of its +clients. See the quick-start section +for the recommended configuration to work around this issue.

+ +

EECDH Server support

+ +

Postfix ≥ 2.6 support NIST P-256 EECDH when built with OpenSSL +≥ 1.0.0. When the remote SMTP client also supports EECDH and +implements the P-256 curve, forward secrecy just works.

+ +

Note: With Postfix 2.6 and 2.7, enable EECDH by +setting the main.cf parameter smtpd_tls_eecdh_grade to "strong". +

+ +

The elliptic curve standards are evolving, with new curves +introduced in RFC 8031 to augment or replace the NIST curves tarnished +by the Snowden revelations. Fortunately, TLS clients advertise +their list of supported curves to the server so that servers can +choose newer stronger curves when mutually supported. OpenSSL 1.0.2 +released in January 2015 was the first release to implement negotiation +of supported curves in TLS servers. In older OpenSSL releases, the +server is limited to selecting a single widely supported curve.

+ +

With Postfix prior to 3.2 or OpenSSL prior to 1.0.2, only a +single server-side curve can be configured, by specifying a suitable +EECDH "grade":

+ +
+
+    smtpd_tls_eecdh_grade = strong | ultra
+    # Underlying curves, best not changed:
+    # tls_eecdh_strong_curve = prime256v1
+    # tls_eecdh_ultra_curve = secp384r1
+
+
+ +

Postfix ≥ 3.2 supports the curve negotiation API of OpenSSL +≥ 1.0.2. When using this software combination, the default setting +of "smtpd_tls_eecdh_grade" changes to "auto", which selects a curve +that is supported by both the server and client. The list of +candidate curves can be configured via "tls_eecdh_auto_curves", +which can be used to configure a prioritized list of supported +curves (most preferred first) on both the server and client. +The default list is suitable for most users.

+ +

Forward Secrecy in the Postfix SMTP Client

+ +

The Postfix ≥ 2.2 SMTP client supports forward secrecy in +its default configuration. All supported OpenSSL releases support +EDH key exchange. OpenSSL releases ≥ 1.0.0 also support EECDH +key exchange (provided elliptic-curve support has not been disabled +by the vendor as in some versions of RedHat Linux). If the +remote SMTP server supports cipher suites with forward secrecy (and +does not override the SMTP client's cipher preference), then the +traffic between the server and client will resist decryption even +if the server's long-term authentication keys are later +compromised.

+ +

Postfix ≥ 3.2 supports the curve negotiation API of OpenSSL +≥ 1.0.2. The list of candidate curves can be changed via the +"tls_eecdh_auto_curves" configuration parameter, which can be used +to select a prioritized list of supported curves (most preferred +first) on both the Postfix SMTP server and SMTP client. The default +list is suitable for most users.

+ +

The default Postfix SMTP client cipher lists are correctly +ordered to prefer EECDH and EDH cipher suites ahead of similar +cipher suites that don't implement forward secrecy. Administrators +are strongly discouraged from changing the cipher list definitions.

+ +

The default minimum cipher grade for opportunistic TLS is +"medium" for Postfix releases after the middle of 2015, "export" +for older releases. Changing the minimum cipher grade does not +change the cipher preference order. Note that cipher grades higher +than "medium" exclude Exchange 2003 and likely other MTAs, thus a +"high" cipher grade should be chosen only on a case-by-case basis +via the TLS policy +table.

+ +

Getting started, quick and dirty

+ +

EECDH Client support (Postfix ≥ 2.2 with OpenSSL ≥ 1.0.0)

+ +

This works "out of the box" with no need for additional +configuration.

+ +

Postfix ≥ 3.2 supports the curve negotiation API of OpenSSL +≥ 1.0.2. The list of candidate curves can be changed via the +"tls_eecdh_auto_curves" configuration parameter, which can be used +to select a prioritized list of supported curves (most preferred +first) on both the Postfix SMTP server and SMTP client. The default +list is suitable for most users.

+ +

EECDH Server support (Postfix ≥ 2.6 with OpenSSL ≥ 1.0.0)

+ +

With Postfix 2.6 and 2.7, enable elliptic-curve support in the +Postfix SMTP server. This is the default with Postfix +≥ 2.8. Note, however, that elliptic-curve support may be disabled +by the vendor, as in some versions of RedHat Linux.

+ +
+
+/etc/postfix/main.cf:
+    # Postfix 2.6 & 2.7 only. EECDH is on by default with Postfix ≥ 2.8.
+    # The default grade is "auto" with Postfix ≥ 3.2.
+    smtpd_tls_eecdh_grade = strong
+
+
+ +

EDH Client support (Postfix ≥ 2.2, all supported OpenSSL +versions)

+ +

This works "out of the box" without additional configuration.

+ +

EDH Server support (Postfix ≥ 2.2, all supported OpenSSL +versions)

+ +

Optionally generate non-default Postfix SMTP server EDH parameters +for improved security against pre-computation attacks and for +compatibility with Debian-patched Exim SMTP clients that require a +≥ 2048-bit length for the non-export prime.

+ +

Execute as root (prime group generation can take a +few seconds to a few minutes):

+ +
+
+# cd /etc/postfix
+# umask 022
+# openssl dhparam -out dh512.tmp 512 && mv dh512.tmp dh512.pem
+# openssl dhparam -out dh1024.tmp 1024 && mv dh1024.tmp dh1024.pem
+# openssl dhparam -out dh2048.tmp 2048 && mv dh2048.tmp dh2048.pem
+# chmod 644 dh512.pem dh1024.pem dh2048.pem
+
+
+ +

The Postfix SMTP server EDH parameter files are not secret, +after all these parameters are sent to all remote SMTP clients in +the clear. Mode 0644 is fine.

+ +

You can improve security against pre-computation attacks further +by regenerating the Postfix SMTP server EDH parameters periodically +(an hourly or daily cron job running the above commands as root can +automate this task).

+ +

Once the parameters are in place, update main.cf as follows:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
+    smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
+
+
+ +

If some of your MSA clients don't support 2048-bit EDH, you may +need to adjust the submission entry in master.cf accordingly:

+ +
+
+/etc/postfix/master.cf:
+    submission inet n       -       n       -       -       smtpd
+	# Some submission clients may not yet do 2048-bit EDH, if such
+	# clients use your MSA, configure 1024-bit EDH instead.  However,
+	# as of mid-2015, many submission clients no longer accept primes
+	# with less than 2048-bits.  Each site needs to determine which
+	# type of client is more important to support.
+	-o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem
+	-o smtpd_tls_security_level=encrypt
+	-o smtpd_sasl_auth_enable=yes
+	...
+
+
+ +

How can I see that a connection has forward +secrecy?

+ +

Postfix can be configured to report information about the +negotiated cipher, the corresponding key lengths, and the remote +peer certificate or public-key verification status.

+ + + +

The next sections will explain what cipher-name, +key-size, and peer verification status information to expect. +

+ +

What ciphers provide forward secrecy?

+ +

There are dozens of ciphers that support forward secrecy. What +follows is the beginning of a list of 51 ciphers available with +OpenSSL 1.0.1e. The list is sorted in the default Postfix preference +order. It excludes null ciphers that only authenticate and don't +encrypt, together with export and low-grade ciphers whose encryption +is too weak to offer meaningful secrecy. The first column shows the +cipher name, and the second shows the key exchange method.

+ +
+
+$ openssl ciphers -v \
+        'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' | 
+    awk '{printf "%-32s %s\n", $1, $3}'
+AECDH-AES256-SHA                 Kx=ECDH
+ECDHE-RSA-AES256-GCM-SHA384      Kx=ECDH
+ECDHE-ECDSA-AES256-GCM-SHA384    Kx=ECDH
+ECDHE-RSA-AES256-SHA384          Kx=ECDH
+ECDHE-ECDSA-AES256-SHA384        Kx=ECDH
+ECDHE-RSA-AES256-SHA             Kx=ECDH
+ECDHE-ECDSA-AES256-SHA           Kx=ECDH
+ADH-AES256-GCM-SHA384            Kx=DH
+ADH-AES256-SHA256                Kx=DH
+ADH-AES256-SHA                   Kx=DH
+ADH-CAMELLIA256-SHA              Kx=DH
+DHE-DSS-AES256-GCM-SHA384        Kx=DH
+DHE-RSA-AES256-GCM-SHA384        Kx=DH
+DHE-RSA-AES256-SHA256            Kx=DH
+...
+
+
+ +

To date, all ciphers that support forward secrecy have one of +five values for the first component of their OpenSSL name: "AECDH", +"ECDHE", "ADH", "EDH" or "DHE". Ciphers that don't implement forward +secrecy have names that don't start with one of these prefixes. +This pattern is likely to persist until some new key-exchange +mechanism is invented that also supports forward secrecy.

+ +

The actual key length and raw algorithm key length +are generally the same with non-export ciphers, but may they +differ for the legacy export ciphers where the actual key +is artificially shortened.

+ +

Starting with TLS 1.3 the cipher name no longer contains enough +information to determine which forward-secrecy scheme was employed, +but TLS 1.3 always uses forward-secrecy. On the client side, +up-to-date Postfix releases log additional information for TLS 1.3 +connections, reporting the signature and key exchange algorithms. +Two examples below (the long single line messages are folded across +multiple lines for readability):

+ +
+
+postfix/smtp[process-id]:
+  Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
+  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+  key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
+  client-signature ECDSA (P-256) client-digest SHA256
+
+postfix/smtp[process-id]:
+  Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
+  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+  key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256
+
+
+ +

In the above connections, the "key-exchange" value records the +"Diffie-Hellman" algorithm used for key agreement. The "server-signature" value +records the public key algorithm used by the server to sign the key exchange. +The "server-digest" value records any hash algorithm used to prepare the data +for signing. With "ED25519" and "ED448", no separate hash algorithm is used. +

+ +

Examples of Postfix SMTP server logging:

+ +
+
+postfix/smtpd[process-id]:
+  Untrusted TLS connection established from localhost[127.0.0.1]:25:
+  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+  key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
+  client-signature ECDSA (P-256) client-digest SHA256
+
+postfix/smtpd[process-id]:
+  Anonymous TLS connection established from localhost[127.0.0.1]:
+  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+  server-signature RSA-PSS (2048 bits) server-digest SHA256
+
+postfix/smtpd[process-id]:
+  Anonymous TLS connection established from localhost[127.0.0.1]:
+  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+  server-signature ED25519
+
+
+ +

Note that Postfix ≥ 3.4 server logging may also include a +"to sni-name" element to record the use of an alternate +server certificate chain for the connection in question. This happens +when the client uses the TLS SNI extension, and the server selects +a non-default certificate chain based on the client's SNI value: +

+ +
+
+postfix/smtpd[process-id]:
+  Untrusted TLS connection established from client.example[192.0.2.1]
+  to server.example: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+  key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
+  client-signature ECDSA (P-256) client-digest SHA256
+
+
+ +

What do "Anonymous", "Untrusted", etc. in +Postfix logging mean?

+ +

The verification levels below are subject to man-in-the-middle +attacks to different degrees. If such attacks are a concern, then +the SMTP client will need to authenticate the remote SMTP server +in a sufficiently-secure manner. For example, by the fingerprint +of a (CA or leaf) public key or certificate. Remember that +conventional PKI relies on many trusted parties and is easily +subverted by a state-funded adversary.

+ +
+ +
Anonymous (no peer certificate)
+ +

Postfix SMTP client: With opportunistic TLS (the "may" security level) the Postfix +SMTP client does not verify any information in the peer certificate. +In this case it enables and prefers anonymous cipher suites in which +the remote SMTP server does not present a certificate (these ciphers +offer forward secrecy of necessity). When the remote SMTP server +also supports anonymous TLS, and agrees to such a cipher suite, the +verification status will be logged as "Anonymous".

+ +

Postfix SMTP server: This is by far most common, +as client certificates are optional, and the Postfix SMTP server +does not request client certificates by default (see smtpd_tls_ask_ccert). +Even when client certificates are requested, the remote SMTP client +might not send a certificate. Unlike the Postfix SMTP client, the +Postfix SMTP server "anonymous" verification status does not imply +that the cipher suite is anonymous, which corresponds to the +server not sending a certificate.

+ +
Untrusted (peer certificate not signed by trusted CA)
+ +
+ +

Postfix SMTP client: The remote SMTP server presented +a certificate, but the Postfix SMTP client was unable to check the +issuing CA signature. With opportunistic TLS this is common with +remote SMTP servers that don't support anonymous cipher suites. +

+ +

Postfix SMTP server: The remote SMTP client presented +a certificate, but the Postfix SMTP server was unable to check the +issuing CA signature. This can happen when the server is configured +to request client certificates (see smtpd_tls_ask_ccert).

+ +
+ +
Trusted (peer certificate signed by trusted CA, unverified +peer name)
+ +
+ +

Postfix SMTP client: The remote SMTP server's certificate +was signed by a CA that the Postfix SMTP client trusts, but either +the client was not configured to verify the destination server name +against the certificate, or the server certificate did not contain +any matching names. This is common with opportunistic TLS +(smtp_tls_security_level is "may" or else "dane" with no usable +TLSA DNS records) when the Postfix SMTP client's trusted CAs can +verify the authenticity of the remote SMTP server's certificate, +but the client is not configured or unable to verify the server +name.

+ +

Postfix SMTP server: The remote SMTP client certificate +was signed by a CA that the Postfix SMTP server trusts. The Postfix +SMTP server never verifies the remote SMTP client name against the +names in the client certificate. Since the client chooses to connect +to the server, the Postfix SMTP server has no expectation of a +particular client hostname.

+ +
+ +
Verified (peer certificate signed by trusted CA and +verified peer name; or: peer certificate with expected public-key +or certificate fingerprint)
+ +
+ +

Postfix SMTP client: The remote SMTP server's certificate +was signed by a CA that the Postfix SMTP client trusts, and the +certificate name matches the destination or server name(s). The +Postfix SMTP client was configured to require a verified name, +otherwise the verification status would have been just "Trusted". +

+ +

Postfix SMTP client: The "Verified" status may also +mean that the Postfix SMTP client successfully matched the expected +fingerprint against the remote SMTP server public key or certificate. +The expected fingerprint may come from smtp_tls_policy_maps or from +TLSA (secure) DNS records. The Postfix SMTP client ignores the CA +signature.

+ +

Postfix SMTP server: The status is never "Verified", +because the Postfix SMTP server never verifies the remote SMTP +client name against the names in the client certificate, and because +the Postfix SMTP server does not expect a specific fingerprint in +the client public key or certificate.

+ +
+ +
+ +

Credits

+ + + + + + diff --git a/proto/INSTALL.html b/proto/INSTALL.html new file mode 100644 index 0000000..984528c --- /dev/null +++ b/proto/INSTALL.html @@ -0,0 +1,1672 @@ + + + + + + +Postfix Installation From Source Code + + + + + + + +

Postfix +Installation From Source Code

+ +
+ +

1 - Purpose of this document

+ +

If you are using a pre-compiled version of Postfix, you should +start with BASIC_CONFIGURATION_README and the general documentation +referenced by it. INSTALL is only a bootstrap document to get +Postfix up and running from scratch with the minimal number of +steps; it should not be considered part of the general documentation. +

+ +

This document describes how to build, install and configure a +Postfix system so that it can do one of the following:

+ + + +

Topics covered in this document:

+ +
    + +
  1. Purpose of this document + +
  2. Typographical conventions + +
  3. Documentation + +
  4. Building on a supported system + +
  5. Porting Postfix to an unsupported system + +
  6. Installing the software after successful +compilation + +
  7. Configuring Postfix to send mail +only + +
  8. Configuring Postfix to send and +receive mail via virtual interface + +
  9. Running Postfix instead of Sendmail + +
  10. Mandatory configuration file edits + +
  11. To chroot or not to chroot + +
  12. Care and feeding of the Postfix system + +
+ +

2 - Typographical conventions

+ +

In the instructions below, a command written as

+ +
+
+# command
+
+
+ +

should be executed as the superuser.

+ +

A command written as

+ +
+
+$ command
+
+
+ +

should be executed as an unprivileged user.

+ +

3 - Documentation

+ +

Documentation is available as README files (start with the file +README_FILES/AAAREADME), as HTML web pages (point your browser to +"html/index.html") and as UNIX-style manual pages.

+ +

You should view the README files with a pager such as more(1) +or less(1), because the files use backspace characters in order to +produce bold font. To print a README file without backspace +characters, use the col(1) command. For example:

+ +
+
+$ col -bx <file | lpr
+
+
+ +

In order to view the manual pages before installing Postfix, +point your MANPATH environment variable to the "man" subdirectory; +be sure to use an absolute path.

+ +
+
+$ export MANPATH; MANPATH="`pwd`/man:$MANPATH"
+$ setenv MANPATH "`pwd`/man:$MANPATH"
+
+
+ +

Of particular interest is the postconf(5) manual page that +lists all the 500+ configuration parameters. The HTML version of +this text makes it easy to navigate around.

+ +

All Postfix source files have their own built-in manual page. +Tools to extract those embedded manual pages are available in the +mantools directory.

+ +

4 - Building on a supported system

+ +

Postfix development happens on FreeBSD and MacOS X, with regular +tests on Linux (Fedora, Ubuntu) and Solaris. Support for other +systems relies on feedback from their users, and may not always be +up-to-date.

+ +

OpenBSD is partially supported. The libc resolver does not +implement the documented "internal resolver options which are [...] +set by changing fields in the _res structure" (documented in the +OpenBSD 5.6 resolver(3) manpage). This results in too many DNS +queries, and false positives for queries that should fail.

+ + + +

Overview of topics:

+ + + + +

4.1 - Getting started

+ +

On Solaris, the "make" command and other development utilities +are in /usr/ccs/bin, so you MUST have /usr/ccs/bin in your command +search path. If these files do not exist, you need to install the +development packages first.

+ +

If you need to build Postfix for multiple architectures from a +single source-code tree, use the "lndir" command to build a shadow +tree with symbolic links to the source files.

+ +

If at any time in the build process you get messages like: "make: +don't know how to ..." you should be able to recover by running +the following command from the Postfix top-level directory:

+ +
+
+$ make -f Makefile.init makefiles
+
+
+ +

If you copied the Postfix source code after building it on another +machine, it is a good idea to cd into the top-level directory and +first do this:

+ +
+
+$ make tidy
+
+
+ +

This will get rid of any system dependencies left over from +compiling the software elsewhere.

+ +

4.2 - What compiler to use

+ +

To build with GCC, or with the native compiler if people told me +that is better for your system, just cd into the top-level Postfix +directory of the source tree and type:

+ +
+
+$ make
+
+
+ +

To build with a non-default compiler, you need to specify the name +of the compiler. Here are a few examples:

+ +
+
+$ make makefiles CC=/opt/SUNWspro/bin/cc        (Solaris)
+$ make
+
+$ make makefiles CC="/opt/ansic/bin/cc -Ae"     (HP-UX)
+$ make
+
+$ make makefiles CC="purify cc"
+$ make
+
+
+ +

and so on. In some cases, optimization will be turned off +automatically.

+ +

4.3 - Building with Postfix position-independent +executables (Postfix ≥ 3.0)

+ +

On some systems Postfix can be built with Position-Independent +Executables. PIE is used by the ASLR exploit mitigation technique +(ASLR = Address-Space Layout Randomization):

+ +
+
+$ make makefiles pie=yes ...other arguments...
+
+
+ +

(Specify "make makefiles pie=no" to explicitly disable Postfix +position-independent executable support).

+ +

Postfix PIE support appears to work on Fedora Core 20, Ubuntu +14.04, FreeBSD 9 and 10, and NetBSD 6 (all with the default system +compilers).

+ +

Whether the "pie=yes" above has any effect depends on the +compiler. Some compilers always produce PIE executables, and some +may even complain that the Postfix build option is redundant.

+ +

4.4 - Building with Postfix dynamically-linked +libraries and database plugins (Postfix ≥ 3.0)

+ +

Postfix dynamically-linked library and database plugin support +exists for recent versions of Linux, FreeBSD and MacOS X. +Dynamically-linked library builds may become the default at some +point in the future.

+ +

Overview of topics:

+ + + +

Note: directories with Postfix dynamically-linked libraries +or database plugins should contain only postfix-related files. +Postfix dynamically-linked libraries and database plugins should +not be installed in a "public" system directory such as /usr/lib +or /usr/local/lib. Linking Postfix dynamically-linked library or +database-plugin files into non-Postfix programs is not supported. +Postfix dynamically-linked libraries and database plugins implement +a Postfix-internal API that changes without maintaining compatibility. +

+ +

4.4.1 Turning on Postfix dynamically-linked +library support

+ +

Postfix can be built with Postfix dynamically-linked libraries +(files typically named libpostfix-*.so). Postfix +dynamically-linked libraries add minor run-time overhead and result +in significantly-smaller Postfix executable files.

+ +

Specify "shared=yes" on the "make makefiles" command line to +build Postfix with dynamically-linked library support.

+ +
+
+$ make makefiles shared=yes ...other arguments...
+$ make
+
+
+ +

(Specify "make makefiles shared=no" to explicitly disable Postfix +dynamically-linked library support).

+ +

This installs dynamically-linked libraries in $shlib_directory, +typically /usr/lib/postfix or /usr/local/lib/postfix, with file +names libpostfix-name.so, where the name is a source-code +directory name such as "util" or "global".

+ +

See section 4.4.3 "Customizing Postfix +dynamically-linked libraries and database plugins" below for +how to customize the Postfix dynamically-linked library location, +including support to upgrade a running mail system safely.

+ +

4.4.2 Turning on Postfix +database-plugin support

+ +

Additionally, Postfix can be built to support dynamic loading +of Postfix database clients (database plugins) with the Debian-style +dynamicmaps feature. Postfix 3.0 supports dynamic loading of cdb:, +ldap:, lmdb:, mysql:, pcre:, pgsql:, sdbm:, and sqlite: database +clients. Dynamic loading is useful when you distribute or install +pre-compiled Postfix packages.

+ +

Specify "dynamicmaps=yes" on the "make makefiles" command line +to build Postfix with support to dynamically load Postfix database +clients with the Debian-style dynamicmaps feature. +

+ +
+
+$ make makefiles dynamicmaps=yes ...other arguments...
+$ make
+
+
+ +

(Specify "make makefiles dynamicmaps=no" to explicitly disable +Postfix database-plugin support).

+ +

This implicitly enables dynamically-linked library support, +installs the configuration file dynamicmaps.cf in $meta_directory +(usually, /etc/postfix or /usr/local/etc/postfix), and installs +database plugins in $shlib_directory (see above). Database plugins +are named postfix-type.so where the type is a database +type such as "cdb" or "ldap".

+ +
+ +

NOTE: The Postfix 3.0 build procedure expects that you specify +database library dependencies with variables named AUXLIBS_CDB, +AUXLIBS_LDAP, etc. With Postfix 3.0 and later, the old AUXLIBS +variable still supports building a statically-loaded database client, +but only the new AUXLIBS_CDB etc. variables support building a +dynamically-loaded or statically-loaded CDB etc. database client. +See CDB_README, LDAP_README, etc. for details.

+ +

Failure to follow this advice will defeat the purpose of dynamic +database client loading. Every Postfix executable file will have +database library dependencies. And that was exactly what dynamic +database client loading was meant to avoid.

+ +
+ +

See the next section for how to customize the location and +version of Postfix database plugins and the location of the file +dynamicmaps.cf.

+ +

4.4.3 Customizing Postfix dynamically-linked +libraries and database plugins

+ +
Customizing build-time and run-time options for Postfix +dynamically-linked libraries and database plugins
+ +

The build-time environment variables SHLIB_CFLAGS, SHLIB_RPATH, +and SHLIB_SUFFIX provide control over how Postfix libraries and +plugins are compiled, linked, and named. + +

+
+$ make makefiles SHLIB_CFLAGS=flags SHLIB_RPATH=rpath SHLIB_SUFFIX=suffix ...other arguments...
+$ make
+
+
+ +

See section 4.7 "Overriding other +compile-time features" below for details.

+ +
Customizing the location of Postfix dynamically-linked libraries +and database plugins
+ +

As a reminder, the directories with Postfix dynamically-linked +libraries or database plugins should contain only Postfix-related +files. Linking these files into other programs is not supported. +

+ +

To override the default location of Postfix dynamically-linked +libraries and database plugins specify, for example:

+ +
+
+$ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ...
+
+
+ +

If you intend to upgrade Postfix without stopping the mail +system, then you should append the Postfix release version to the +shlib_directory pathname, to eliminate the possibility that programs +will link with dynamically-linked libraries or database plugins +from the wrong Postfix version. For example:

+ +
+
+$ make makefiles shared=yes \
+    shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+
+
+ +

The command "make makefiles name=value..." will replace the +string MAIL_VERSION at the end of a configuration parameter value +with the Postfix release version. Do not try to specify something +like $mail_version on this command line. This produces inconsistent +results with different versions of the make(1) command.

+ +

You can change the shlib_directory setting after Postfix is +built, with "make install" or "make upgrade". However, you may have +to run ldconfig if you change shlib_directory after Postfix is built +(the symptom is that Postfix programs fail because the run-time +linker cannot find the files libpostfix-*.so). No ldconfig command +is needed if you keep the files libpostfix-*.so in the compiled-in +default $shlib_directory location.

+ +
+
+# make upgrade shlib_directory=/usr/local/lib/postfix ...
+# make install shlib_directory=/usr/local/lib/postfix ...
+
+
+ +

To append the Postfix release version to the pathname if you +intend to upgrade Postfix without stopping the mail system:

+ +
+
+# make upgrade shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+# make install shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+
+
+ +

See also the comments above for appending MAIL_VERSION with +the "make makefiles" command.

+ +
Customizing the location of dynamicmaps.cf and other files +
+ +

The meta_directory parameter has the same default setting as +the config_directory parameter, typically /etc/postfix or +/usr/local/etc/postfix.

+ +

You can override the default meta_directory location at compile +time or after Postfix is built. To override the default location +at compile time specify, for example:

+ +
+
+% make makefiles meta_directory=/usr/libexec/postfix ...
+
+
+ +

Here is a tip if you want to make a pathname dependent on the +Postfix release version: the command "make makefiles name=value..." +will replace the string MAIL_VERSION at the end of a configuration +parameter value with the Postfix release version. Do not try to +specify something like $mail_version on this command line. This +produces inconsistent results with different versions of the make(1) +command.

+ +

You can override the meta_directory setting after Postfix is +built, with "make install" or "make upgrade".

+ +
+
+# make upgrade meta_directory=/usr/libexec/postfix ...
+# make install meta_directory=/usr/libexec/postfix ...
+
+
+ +

As with the command "make makefiles, the command "make +install/upgrade name=value..." will replace the string MAIL_VERSION +at the end of a configuration parameter value with the Postfix +release version. Do not try to specify something like $mail_version +on this command line. This produces inconsistent results with +different versions of the make(1) command.

+ +

4.4.4 Tips for distribution maintainers +

+ + + +

4.5 - Building with optional features

+ +By default, Postfix builds as a mail system with relatively few +bells and whistles. Support for third-party databases etc. +must be configured when Postfix is compiled. The following documents +describe how to build Postfix with support for optional features: + +
+ + + + + + + + + + + + + + + + + + + + + + + + +
Optional feature Document Availability
Berkeley DB database DB_README Postfix +1.0
LMDB database LMDB_README Postfix +2.11
LDAP database LDAP_README Postfix +1.0
MySQL database MYSQL_README Postfix +1.0
Perl compatible regular expression PCRE_README Postfix 1.0
PostgreSQL database PGSQL_README +Postfix 2.0
SASL authentication SASL_README +Postfix 1.0
SQLite database SQLITE_README Postfix +2.8
STARTTLS session encryption TLS_README +Postfix 2.2
+ +
+ +

Note: IP version 6 support is compiled into Postfix on operating +systems that have IPv6 support. See the IPV6_README file for details. +

+ +

4.6 - Overriding built-in parameter default +settings

+ +

4.6.1 - Postfix 3.0 and later

+ +

All Postfix configuration parameters can be changed by editing +a Postfix configuration file, except for one: the parameter that +specifies the location of Postfix configuration files. In order to +build Postfix with a configuration directory other than /etc/postfix, +use:

+ +
+
+$ make makefiles config_directory=/some/where ...other arguments...
+$ make
+
+
+ +

The command "make makefiles name=value ..." will replace the +string MAIL_VERSION at the end of a configuration parameter value +with the Postfix release version. Do not try to specify something +like $mail_version on this command line. This produces inconsistent +results with different versions of the make(1) command.

+ +

Parameters whose defaults can be specified in this way are +listed below. See the postconf(5) manpage for a description +(command: "nroff -man man/man5/postconf.5 | less").

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
parameter name typical default
command_directory /usr/sbin
config_directory /etc/postfix
default_database_type hash
daemon_directory /usr/libexec/postfix
data_directory /var/lib/postfix
html_directory no
mail_spool_directory /var/mail
mailq_path /usr/bin/mailq
manpage_directory /usr/local/man
meta_directory /etc/postfix
newaliases_path /usr/bin/newaliases
openssl_path openssl
queue_directory /var/spool/postfix
readme_directory no
sendmail_path /usr/sbin/sendmail
shlib_directory /usr/lib/postfix
+ +
+ +

4.6.2 - All Postfix versions

+ +

All Postfix configuration parameters can be changed by editing +a Postfix configuration file, except for one: the parameter that +specifies the location of Postfix configuration files. In order to +build Postfix with a configuration directory other than /etc/postfix, +use:

+ +
+
+$ make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"'
+$ make
+
+
+ +

IMPORTANT: Be sure to get the quotes right. These details matter +a lot.

+ +

Parameters whose defaults can be specified in this way are +listed below. See the postconf(5) manpage for a description +(command: "nroff -man man/man5/postconf.5 | less").

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Macro name default value for typical +default
DEF_COMMAND_DIR command_directory/usr/sbin
DEF_CONFIG_DIR config_directory/etc/postfix
DEF_DB_TYPE default_database_typehash
DEF_DAEMON_DIR daemon_directory/usr/libexec/postfix
DEF_DATA_DIR data_directory/var/lib/postfix
DEF_MAILQ_PATH mailq_path /usr/bin/mailq
DEF_HTML_DIR html_directoryno
DEF_MANPAGE_DIR manpage_directory/usr/local/man
DEF_NEWALIAS_PATH newaliases_path/usr/bin/newaliases
DEF_QUEUE_DIR queue_directory/var/spool/postfix
DEF_README_DIR readme_directoryno
DEF_SENDMAIL_PATH sendmail_path/usr/sbin/sendmail
+ +
+ +

Note: the data_directory parameter (for caches and pseudo-random +numbers) was introduced with Postfix version 2.5.

+ +

4.7 - Overriding other compile-time +features

+ +

The general method to override Postfix compile-time features +is as follows:

+ +
+
+$ make makefiles name=value name=value...
+$ make
+
+
+ +

The following is an extensive list of names and values.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name/Value Description
AUXLIBS="object_library..." Specifies +one or more non-default object libraries. Postfix 3.0 and later +specify some of their database library dependencies with AUXLIBS_CDB, +AUXLIBS_LDAP, AUXLIBS_LMDB, AUXLIBS_MYSQL, AUXLIBS_PCRE, AUXLIBS_PGSQL, +AUXLIBS_SDBM, and AUXLIBS_SQLITE, respectively.
CC=compiler_command Specifies a +non-default compiler. On many systems, the default is gcc. +
CCARGS="compiler_arguments..." +Specifies non-default compiler arguments, for example, a non-default +include directory. The following directives turn +off Postfix features at compile time:
-DNO_DB Do not build with Berkeley +DB support. By default, Berkeley DB support is compiled in on +platforms that are known to support this feature. If you override +this, then you probably should also override DEF_DB_TYPE as described +in section 4.6.
-DNO_DNSSEC Do not build with DNSSEC +support, even if the resolver library appears to support it.
-DNO_DEVPOLL Do not build with +Solaris /dev/poll support. By default, /dev/poll +support is compiled in on Solaris versions that are known to support +this feature.
-DNO_EPOLL Do not build with Linux +EPOLL support. By default, EPOLL support is compiled in on platforms +that are known to support this feature.
-DNO_EAI Do not build with EAI +(SMTPUTF8) support. By default, EAI support is compiled in when +the "icuuc" library and header files are found.
-DNO_INLINE Do not require support +for C99 "inline" functions. Instead, implement argument typechecks +for non-printf/scanf-like functions with ternary operators and +unreachable code.
-DNO_IPV6 Do not build with IPv6 +support. By default, IPv6 support is compiled in on platforms that +are known to have IPv6 support. Note: this directive is for debugging +And testing only. It is not guaranteed to work on all platforms. +If you don't want IPv6 support, set "inet_protocols = ipv4" in +main.cf. +
-DNO_KQUEUE Do not build with FreeBSD +/ NetBSD / OpenBSD / MacOSX KQUEUE support. By default, KQUEUE +support is compiled in on platforms that are known to support it. +
-DNO_NIS Do not build with NIS or +NISPLUS support. NIS is not available on some recent Linux +distributions.
-DNO_NISPLUS Do not build with +NISPLUS support. NISPLUS is not available on some recent Solaris +distributions.
-DNO_PCRE Do not build with PCRE +support. By default, PCRE support is compiled in when the +pcre-config utility is installed.
-DNO_POSIX_GETPW_R Disable support +for POSIX getpwnam_r/getpwuid_r. By default Postfix uses +these where they are known to be available.
-DNO_SIGSETJMP Use +setjmp()/longjmp() instead of sigsetjmp()/siglongjmp(). +By default, Postfix uses sigsetjmp()/siglongjmp() when +they are known to be available.
-DNO_SNPRINTF Use sprintf() +instead of snprintf(). By default, Postfix uses +snprintf() except on ancient systems.
DEBUG=debug_level Specifies a +non-default compiler debugging level. The default is "-g". +Specify DEBUG= to turn off debugging.
OPT=optimization_level Specifies +a non-default optimization level. The default is "-O". +Specify OPT= to turn off optimization.
POSTFIX_INSTALL_OPTS=-option... +Specifies options for the postfix-install command, separated +by whitespace. Currently, the only supported option is +"-keep-build-mtime".
SHLIB_CFLAGS=flags Specifies +non-default compiler options for building Postfix dynamically-linked +libraries and database plugins. The typical default is "-fPIC". +
SHLIB_RPATH=rpath Specifies +a non-default runpath for Postfix dynamically-linked libraries. The +typical default is "'-Wl,-rpath,${SHLIB_DIR}'".
SHLIB_SUFFIX=suffix Specifies +a non-default suffix for Postfix dynamically-linked libraries and +database plugins. The typical default is ".so".
WARN="warning_flags..." Specifies +non-default compiler warning options for use when "make" +is invoked in a source subdirectory only.
+ +

4.8 - Support for thousands of processes

+ +

The number of connections that Postfix can manage simultaneously +is limited by the number of processes that it can run. This number +in turn is limited by the number of files and sockets that a single +process can open. For example, the Postfix queue manager has a +separate connection to each delivery process, and the anvil(8) +server has one connection per smtpd(8) process.

+ +

Postfix version 2.4 and later have no built-in limits on the +number of open files or sockets, when compiled on systems that +support one of the following:

+ + + + +

With other Postfix versions or operating systems, the number +of file descriptors per process is limited by the value of the +FD_SETSIZE macro. If you expect to run more than 1000 mail delivery +processes, you may need to override the definition of the FD_SETSIZE +macro to make select() work correctly:

+ +
+
+$ make makefiles CCARGS=-DFD_SETSIZE=2048
+
+
+ +

Warning: the above has no effect on some Linux versions. +Apparently, on these systems the FD_SETSIZE value can be changed +only by using undocumented interfaces. Currently, that means +including <bits/types.h> directly (which is not allowed) and +overriding the __FD_SETSIZE macro. Beware, undocumented interfaces +can change at any time and without warning.

+ +

But wait, there is more: none of this will work unless the +operating system is configured to handle thousands of connections. +See the TUNING_README guide for examples of how to increase the +number of open sockets or files.

+ +

4.9 - Compiling Postfix, at last

+ +

If the command

+ +
+
+$ make
+
+
+ +

is successful, then you can proceed to install +Postfix (section 6). + +

If the command produces compiler error messages, it may be time +to search the web or to ask the postfix-users@postfix.org mailing +list, but be sure to search the mailing list archives first. Some +mailing list archives are linked from http://www.postfix.org/.

+ +

5 - Porting Postfix to an unsupported system

+ +

Each system type that Postfix knows is identified by a unique +name. Examples: SUNOS5, FREEBSD4, and so on. When porting Postfix +to a new system, the first step is to choose a SYSTEMTYPE name for +the new system. You must use a name that includes at least the +major version of the operating system (such as SUNOS4 or LINUX2), +so that different releases of the same system can be supported +without confusion.

+ +

Add a case statement to the "makedefs" shell script in the +source code top-level directory that recognizes the new system +reliably, and that emits the right system-specific information. +Be sure to make the code robust against user PATH settings; if the +system offers multiple UNIX flavors (e.g. BSD and SYSV) be sure to +build for the native flavor, instead of the emulated one.

+ +

Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h +include file. You may have to invent new feature macro names. +Please choose sensible feature macro names such as HAS_DBM or +FIONREAD_IN_SYS_FILIO_H. + +

I strongly recommend against using "#ifdef SYSTEMTYPE" in +individual source files. While this may look like the quickest +solution, it will create a mess when newer versions of the same +SYSTEMTYPE need to be supported. You're likely to end up placing +"#ifdef" sections all over the source code again.

+ +

6 - Installing the software after successful +compilation

+ +

This text describes how to install Postfix from source code. +See the PACKAGE_README file if you are building a package for +distribution to other systems.

+ +

6.1 - Save existing Sendmail binaries

+ +

IMPORTANT: if you are REPLACING an existing +Sendmail installation with Postfix, you may need to keep the old +sendmail program running for some time in order to flush the mail +queue.

+ + + +

6.2 - Create account and groups

+ +

Before you install Postfix for the first time you need to +create an account and a group:

+ + + +

6.3 - Install Postfix

+ +

To install or upgrade Postfix from compiled source code, run +one of the following commands as the super-user:

+ +
+
+# make install       (interactive version, first time install)
+
+# make upgrade       (non-interactive version, for upgrades)
+
+
+ + + +

6.4 - Configure Postfix

+ +

Proceed to the section on how you wish to run Postfix on +your particular machine:

+ + + +

7 - Configuring Postfix to send mail +only

+ +

If you are going to use Postfix to send mail only, there is no +need to change your existing sendmail setup. Instead, set up your +mail user agent so that it calls the Postfix sendmail program +directly.

+ +

Follow the instructions in the "Mandatory +configuration file edits" in section 10, and review the "To chroot or not to chroot" text in section +11.

+ +

You MUST comment out the "smtp inet" entry in /etc/postfix/master.cf, +in order to avoid conflicts with the real sendmail. Put a "#" +character in front of the line that defines the smtpd service:

+ +
+
+/etc/postfix/master.cf:
+    #smtp      inet  n       -       n       -       -       smtpd
+
+
+ +

Start the Postfix system:

+ +
+
+# postfix start
+
+
+ +

or, if you feel nostalgic, use the Postfix sendmail command:

+ +
+
+# sendmail -bd -qwhatever
+
+
+ +

and watch your maillog file for any error messages. The pathname +is /var/log/maillog, /var/log/mail, /var/log/syslog, or something +else. Typically, the pathname is defined in the /etc/syslog.conf +file.

+ +
+
+$ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+
+ +

Note: the most important error message is logged first. Later +messages are not as useful.

+ +

In order to inspect the mail queue, use one of the following +commands:

+ +
+
+$ mailq
+
+$ sendmail -bp
+
+$ postqueue -p
+
+
+ +

See also the "Care and feeding" section 12 +below.

+ +

8 - Configuring Postfix to send and +receive mail via virtual interface

+ +

Alternatively, you can use the Postfix system to send AND +receive mail while leaving your Sendmail setup intact, by running +Postfix on a virtual interface address. Simply configure your mail +user agent to directly invoke the Postfix sendmail program.

+ +

To create a virtual network interface address, study your +system ifconfig manual page. The command syntax could be any +of:

+ +
+
+# ifconfig le0:1 <address> netmask <mask> up
+# ifconfig en0 alias <address> netmask 255.255.255.255
+
+
+ +

In the /etc/postfix/main.cf file, I would specify

+ +
+
+/etc/postfix/main.cf:
+    myhostname = virtual.host.tld
+    inet_interfaces = $myhostname
+    mydestination = $myhostname
+
+
+ +

Follow the instructions in the "Mandatory +configuration file edits" in section 10, and review the "To chroot or not to chroot" text in section +11.

+ +

Start the Postfix system:

+ +
+
+# postfix start
+
+
+ +

or, if you feel nostalgic, use the Postfix sendmail command:

+ +
+
+# sendmail -bd -qwhatever
+
+
+ +

and watch your maillog file for any error messages. The pathname +is /var/log/maillog, /var/log/mail, /var/log/syslog, or something +else. Typically, the pathname is defined in the /etc/syslog.conf +file.

+ +
+
+$ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+
+ +

Note: the most important error message is logged first. Later +messages are not as useful.

+ +

In order to inspect the mail queue, use one of the following +commands:

+ +
+
+$ mailq
+
+$ sendmail -bp
+
+$ postqueue -p
+
+
+ +

See also the "Care and feeding" section 12 +below.

+ +

9 - Running Postfix instead of Sendmail

+ +

Prior to installing Postfix you should save +any existing sendmail program files as described in section 6. Be +sure to keep the old sendmail running for at least a couple days +to flush any unsent mail. To do so, stop the sendmail daemon and +restart it as:

+ +
+
+# /usr/sbin/sendmail.OFF -q
+
+
+ +

Note: this is old sendmail syntax. Newer versions use separate +processes for mail submission and for running the queue.

+ +

After you have visited the "Mandatory +configuration file edits" section below, you can start the +Postfix system with:

+ +
+
+# postfix start
+
+
+ +

or, if you feel nostalgic, use the Postfix sendmail command:

+ +
+
+# sendmail -bd -qwhatever
+
+
+ +

and watch your maillog file for any error messages. The pathname +is /var/log/maillog, /var/log/mail, /var/log/syslog, or something +else. Typically, the pathname is defined in the /etc/syslog.conf +file.

+ +
+
+$ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+
+ +

Note: the most important error message is logged first. Later +messages are not as useful.

+ +

In order to inspect the mail queue, use one of the following +commands:

+ +
+
+$ mailq
+
+$ sendmail -bp
+
+$ postqueue -p
+
+
+ +

See also the "Care and feeding" section 12 +below.

+ +

10 - Mandatory configuration file edits

+ +

Note: the material covered in this section is covered in more +detail in the BASIC_CONFIGURATION_README document. The information +presented below is targeted at experienced system administrators. +

+ +

10.1 - 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:

+ +
+
+/etc/postfix/main.cf:
+    parameter = value
+
+
+ +

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

+ +
+
+/etc/postfix/main.cf:
+    other_parameter = $parameter
+
+
+ +

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.

+ +

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

+ +
+
+# postfix reload
+
+
+ +

10.2 - Default domain for unqualified addresses

+ +

First of all, you must specify what domain will be appended to an +unqualified address (i.e. an address without @domain.tld). The +"myorigin" parameter defaults to the local hostname, but that is +probably OK only for very small sites.

+ +

Some examples (use only one):

+ +
+
+/etc/postfix/main.cf:
+    myorigin = $myhostname    (send mail as "user@$myhostname")
+    myorigin = $mydomain      (send mail as "user@$mydomain")
+
+
+ +

10.3 - What domains to receive locally

+ +

Next you need to specify what mail addresses Postfix should deliver +locally.

+ +

Some examples (use only one):

+ +
+
+/etc/postfix/main.cf:
+    mydestination = $myhostname, localhost.$mydomain, localhost
+    mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
+    mydestination = $myhostname
+
+
+ +

The first example is appropriate for a workstation, the second +is appropriate for the mailserver for an entire domain. The third +example should be used when running on a virtual host interface.

+ +

10.4 - Proxy/NAT interface addresses

+ +

The proxy_interfaces parameter specifies all network addresses +that Postfix receives mail on by way of a proxy or network address +translation unit. 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.

+ +
+
+/etc/postfix/main.cf:
+    proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
+
+
+ +

10.5 - What local clients to relay mail from

+ +

If your machine is on an open network then you must specify +what client IP addresses are authorized to relay their mail through +your machine into the Internet. The default setting includes all +subnetworks that the machine is attached to. This may give relay +permission to too many clients. My own settings are:

+ +
+
+/etc/postfix/main.cf:
+    mynetworks = 168.100.189.0/28, 127.0.0.0/8
+
+
+ +

10.6 - What relay destinations to accept from strangers

+ +

If your machine is on an open network then you must also specify +whether Postfix will forward mail from strangers. The default +setting will forward mail to all domains (and subdomains of) what +is listed in $mydestination. This may give relay permission for +too many destinations. Recommended settings (use only one):

+ +
+
+/etc/postfix/main.cf:
+    relay_domains =            (do not forward mail from strangers)
+    relay_domains = $mydomain  (my domain and subdomains)
+    relay_domains = $mydomain, other.domain.tld, ...
+
+
+ +

10.7 - Optional: configure a smart host for remote delivery

+ +

If you're behind a firewall, you should set up a relayhost. If +you can, specify the organizational domain name so that Postfix +can use DNS lookups, and so that it can fall back to a secondary +MX host when the primary MX host is down. Otherwise just specify +a hard-coded hostname.

+ +

Some examples (use only one):

+ +
+
+/etc/postfix/main.cf:
+    relayhost = $mydomain
+    relayhost = [mail.$mydomain]
+
+
+ +

The form enclosed with [] eliminates DNS MX lookups.

+ +

By default, the SMTP client will do DNS lookups even when you +specify a relay host. If your machine has no access to a DNS server, +turn off SMTP client DNS lookups like this:

+ +
+
+/etc/postfix/main.cf:
+    disable_dns_lookups = yes
+
+
+ +

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

+ +

10.8 - Create the aliases database

+ +

Postfix uses a Sendmail-compatible aliases(5) table to redirect +mail for local(8) recipients. Typically, this information is kept +in two files: in a text file /etc/aliases and in an indexed file +/etc/aliases.db. The command "postconf alias_maps" will tell you +the exact location of the text file.

+ +

First, be sure to update the text file with aliases for root, +postmaster and "postfix" that forward mail to a real person. Postfix +has a sample aliases file /etc/postfix/aliases that you can adapt +to local conditions.

+ +
+
+/etc/aliases:
+    root: you
+    postmaster: root
+    postfix: root
+    bin: root
+    etcetera...
+
+
+ +

Note: there should be no whitespace before the ":".

+ +

Finally, build the indexed aliases file with one of the +following commands:

+ +
+
+# newaliases
+# sendmail -bi
+
+
+ +

11 - To chroot or not to chroot

+ +

Postfix daemon processes can be configured (via master.cf) to +run in a chroot jail. The processes run at a fixed low privilege +and with access only to the Postfix queue directories (/var/spool/postfix). +This provides a significant barrier against intrusion. The barrier +is not impenetrable, 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. Instructions are in the file. +

+ +

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 for specific systems:

+ +
+ +
FreeBSD:
+ +
+# mkdir -p /var/spool/postfix/var/run
+# syslogd -l /var/spool/postfix/var/run/log
+
+ +
Linux, OpenBSD:
+ +
+# mkdir -p /var/spool/postfix/dev
+# syslogd -a /var/spool/postfix/dev/log
+
+ +
+ +

12 - Care and feeding of the Postfix system

+ +

Postfix daemon processes run in the background, and log problems +and normal activity to the syslog daemon. The names of logfiles +are specified in /etc/syslog.conf. At the very least you need +something like:

+ +
+
+/etc/syslog.conf:
+    mail.err                                    /dev/console
+    mail.debug                                  /var/log/maillog
+
+
+ +

IMPORTANT: the syslogd will not create files. You must create +them before (re)starting syslogd.

+ +

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

+ +

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

+ +
+
+# postfix check
+# egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+
+ + + +

The DEBUG_README +document describes the meaning of the "warning" etc. labels in +Postfix logging.

+ + + + diff --git a/proto/IPV6_README.html b/proto/IPV6_README.html new file mode 100644 index 0000000..25f8353 --- /dev/null +++ b/proto/IPV6_README.html @@ -0,0 +1,387 @@ + + + + + + +Postfix IPv6 Support + + + + + + + +

Postfix +IPv6 Support

+ +
+ +

Introduction

+ +

Postfix 2.2 introduces support for the IPv6 (IP version 6) +protocol. IPv6 support for older Postfix versions was available as +an add-on patch. The section "Compatibility with +Postfix <2.2 IPv6 support" below discusses the differences +between these implementations.

+ +

The main feature of interest is that IPv6 uses 128-bit IP +addresses instead of the 32-bit addresses used by IPv4. It can +therefore accommodate a much larger number of hosts and networks +without ugly kluges such as NAT. A side benefit of the much larger +address space is that it makes random network scanning impractical. +

+ +

Postfix uses the same SMTP protocol over IPv6 as it already +uses over the older IPv4 network, and does AAAA record lookups in +the DNS in addition to the older A records. Information about IPv6 +can be found at http://www.ipv6.org/.

+ +

This document provides information on the following topics: +

+ + + +

Supported Platforms

+ +

Postfix version 2.2 supports IPv4 and IPv6 on the following +platforms:

+ + + +

On other platforms Postfix will simply use IPv4 as it has always +done.

+ +

See below for tips how to port Postfix +IPv6 support to other environments.

+ +

Configuration

+ +

Postfix IPv6 support introduces two new main.cf configuration +parameters, and introduces an important change in address syntax +notation in match lists such as mynetworks or +debug_peer_list.

+ +

Postfix IPv6 address syntax is a little tricky, because there +are a few places where you must enclose an IPv6 address inside +"[]" characters, and a few places where you must not. It is +a good idea to use "[]" only in the few places where you +have to. Check out the postconf(5) manual whenever you do IPv6 +related configuration work with Postfix.

+ + + +

NOTE: when configuring Postfix match lists such as +mynetworks or debug_peer_list, you must specify +IPv6 address information inside "[]" in the main.cf parameter +value and in files specified with a "/file/name" pattern. +IPv6 addresses contain the ":" character, and would otherwise be +confused with a "type:table" pattern.

+ +

Known Limitations

+ + + +

Compatibility with Postfix <2.2 IPv6 support +

+ +

Postfix version 2.2 IPv6 support is based on the Postfix/IPv6 patch +by Dean Strik and others, but differs in a few minor ways.

+ + + +

IPv6 Support for unsupported platforms

+ +

Getting Postfix IPv6 working on other platforms involves the +following steps:

+ + + +

If none of all this produces a usable result, send email to the +postfix-users@postfix.org mailing list and we'll try to help you +through this.

+ +

Credits

+ +

The following information is in part based on information that +was compiled by Dean Strik.

+ + + + + + diff --git a/proto/LDAP_README.html b/proto/LDAP_README.html new file mode 100644 index 0000000..7b46807 --- /dev/null +++ b/proto/LDAP_README.html @@ -0,0 +1,628 @@ + + + + + + +Postfix LDAP Howto + + + + + + + +

Postfix LDAP Howto

+ +
+ +

LDAP Support in Postfix

+ +

Postfix can use an LDAP directory as a source for any of its +lookups: aliases(5), virtual(5), canonical(5), etc. This allows +you to keep information for your mail service in a replicated +network database with fine-grained access controls. By not storing +it locally on the mail server, the administrators can maintain it +from anywhere, and the users can control whatever bits of it you +think appropriate. You can have multiple mail servers using the +same information, without the hassle and delay of having to copy +it to each.

+ +

Topics covered in this document:

+ + + +

Building Postfix with LDAP support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

Note 1: Postfix no longer supports the LDAP version 1 interface. +

+ +

Note 2: to use LDAP with Debian GNU/Linux's Postfix, all you +need is to install the postfix-ldap package and you're done. There +is no need to recompile Postfix.

+ +

You need to have LDAP libraries and include files installed +somewhere on your system, and you need to configure the Postfix +Makefiles accordingly.

+ +

For example, to build the OpenLDAP libraries for use with +Postfix (i.e. LDAP client code only), you could use the following +command:

+ +
+
+% ./configure  --without-kerberos --without-cyrus-sasl --without-tls \
+    --without-threads --disable-slapd --disable-slurpd \
+    --disable-debug --disable-shared
+
+
+ +

If you're using the libraries from the UM distribution +(http://www.umich.edu/~dirsvcs/ldap/ldap.html) or OpenLDAP +(http://www.openldap.org), something like this in the top level of +your Postfix source tree should work:

+ +
+
+% make tidy
+% make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
+    AUXLIBS_LDAP="-L/usr/local/lib -lldap -L/usr/local/lib -llber"
+
+
+ +

Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LDAP. +With Postfix 3.0 and later, the old AUXLIBS variable still supports +building a statically-loaded LDAP database client, but only the new +AUXLIBS_LDAP variable supports building a dynamically-loaded or +statically-loaded LDAP database client.

+ +
+ +

Failure to use the AUXLIBS_LDAP variable will defeat the purpose +of dynamic database client loading. Every Postfix executable file +will have LDAP database library dependencies. And that was exactly +what dynamic database client loading was meant to avoid.

+ +
+ +

On Solaris 2.x you may have to specify run-time link information, +otherwise ld.so will not find some of the shared libraries:

+ +
+
+% make tidy
+% make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
+    AUXLIBS_LDAP="-L/usr/local/lib -R/usr/local/lib -lldap \
+            -L/usr/local/lib -R/usr/local/lib -llber"
+
+
+ +

The 'make tidy' command is needed only if you have previously +built Postfix without LDAP support.

+ +

Instead of '/usr/local' specify the actual locations of your +LDAP include files and libraries. Be sure to not mix LDAP include +files and LDAP libraries of different versions!!

+ +

If your LDAP libraries were built with Kerberos support, you'll +also need to include your Kerberos libraries in this line. Note +that the KTH Kerberos IV libraries might conflict with Postfix's +lib/libdns.a, which defines dns_lookup. If that happens, you'll +probably want to link with LDAP libraries that lack Kerberos support +just to build Postfix, as it doesn't support Kerberos binds to the +LDAP server anyway. Sorry about the bother.

+ +

If you're using one of the Netscape LDAP SDKs, you'll need to +change the AUXLIBS line to point to libldap10.so or libldapssl30.so +or whatever you have, and you may need to use the appropriate linker +option (e.g. '-R') so the executables can find it at runtime.

+ +

If you are using OpenLDAP, and the libraries were built with SASL +support, you can add -DUSE_LDAP_SASL to the CCARGS to enable SASL support. +For example:

+ +
+
+     CCARGS="-I/usr/local/include -DHAS_LDAP -DUSE_LDAP_SASL"
+
+
+ +

Configuring LDAP lookups

+ +

In order to use LDAP lookups, define an LDAP source +as a table lookup in main.cf, for example:

+ +
+
+alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
+
+
+ +

The file /etc/postfix/ldap-aliases.cf can specify a great number +of parameters, including parameters that enable LDAP SSL or STARTTLS, +and LDAP SASL. For a complete description, see the ldap_table(5) +manual page.

+ +

Example: local(8) aliases

+ +

Here's a basic example for using LDAP to look up local(8) +aliases. Assume that in main.cf, you have:

+ +
+
+alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
+
+
+ +

and in ldap:/etc/postfix/ldap-aliases.cf you have:

+ +
+
+server_host = ldap.example.com
+search_base = dc=example, dc=com
+
+
+ +

Upon receiving mail for a local address "ldapuser" that isn't +found in the /etc/aliases database, Postfix will search the LDAP +server listening at port 389 on ldap.example.com. It will bind anonymously, +search for any directory entries whose mailacceptinggeneralid +attribute is "ldapuser", read the "maildrop" attributes of those +found, and build a list of their maildrops, which will be treated +as RFC822 addresses to which the message will be delivered.

+ +

Example: virtual domains/addresses

+ +

If you want to keep information for virtual lookups in your +directory, it's only a little more complicated. First, you need to +make sure Postfix knows about the virtual domain. An easy way to +do that is to add the domain to the mailacceptinggeneralid attribute +of some entry in the directory. Next, you'll want to make sure all +of your virtual recipient's mailacceptinggeneralid attributes are +fully qualified with their virtual domains. Finally, if you want +to designate a directory entry as the default user for a virtual +domain, just give it an additional mailacceptinggeneralid (or the +equivalent in your directory) of "@fake.dom". That's right, no +user part. If you don't want a catchall user, omit this step and +mail to unknown users in the domain will simply bounce.

+ +

In summary, you might have a catchall user for a virtual domain +that looks like this:

+ +
+
+     dn: cn=defaultrecipient, dc=fake, dc=dom
+     objectclass: top
+     objectclass: virtualaccount
+     cn: defaultrecipient
+     owner: uid=root, dc=someserver, dc=isp, dc=dom
+1 -> mailacceptinggeneralid: fake.dom
+2 -> mailacceptinggeneralid: @fake.dom
+3 -> maildrop: realuser@real.dom         
+
+
+ +
+ +

1: Postfix knows fake.dom is a valid virtual domain when +it looks for this and gets something (the maildrop) back.

+ +

2: This causes any mail for unknown users in fake.dom to +go to this entry ...

+ +

3: ... and then to its maildrop.

+ +
+ +

Normal users might simply have one mailacceptinggeneralid and +maildrop, e.g. "normaluser@fake.dom" and "normaluser@real.dom". +

+ +

Example: expanding LDAP groups

+ +

+LDAP is frequently used to store group member information. There are a +number of ways of handling LDAP groups. We will show a few examples in +order of increasing complexity, but owing to the number of independent +variables, we can only present a tiny portion of the solution space. +We show how to: +

+ +
    + +

  1. query groups as lists of addresses;

    + +

  2. query groups as lists of user objects containing addresses;

    + +

  3. forward special lists unexpanded to a separate list server, +for moderation or other processing;

    + +

  4. handle complex schemas by controlling expansion and by treating +leaf nodes specially, using features that are new in Postfix 2.4.

    + +
+ +

+The example LDAP entries and implied schema below show two group entries +("agroup" and "bgroup") and four user entries ("auser", "buser", "cuser" +and "duser"). The group "agroup" has the users "auser" (1) and "buser" (2) +as members via DN references in the multi-valued attribute "memberdn", and +direct email addresses of two external users "auser@example.org" (3) and +"buser@example.org" (4) stored in the multi-valued attribute "memberaddr". +The same is true of "bgroup" and "cuser"/"duser" (6)/(7)/(8)/(9), but +"bgroup" also has a "maildrop" attribute of "bgroup@mlm.example.com" +(5):

+ +
+
+     dn: cn=agroup, dc=example, dc=com
+     objectclass: top
+     objectclass: ldapgroup
+     cn: agroup
+     mail: agroup@example.com
+1 -> memberdn: uid=auser, dc=example, dc=com
+2 -> memberdn: uid=buser, dc=example, dc=com
+3 -> memberaddr: auser@example.org
+4 -> memberaddr: buser@example.org
+
+
+ +
+     dn: cn=bgroup, dc=example, dc=com
+     objectclass: top
+     objectclass: ldapgroup
+     cn: bgroup
+     mail: bgroup@example.com
+5 -> maildrop: bgroup@mlm.example.com
+6 -> memberdn: uid=cuser, dc=example, dc=com
+7 -> memberdn: uid=duser, dc=example, dc=com
+8 -> memberaddr: cuser@example.org
+9 -> memberaddr: duser@example.org
+
+
+ +
+     dn: uid=auser, dc=example, dc=com
+     objectclass: top
+     objectclass: ldapuser
+     uid: auser
+10 -> mail: auser@example.com
+11 -> maildrop: auser@mailhub.example.com
+
+
+ +
+     dn: uid=buser, dc=example, dc=com
+     objectclass: top
+     objectclass: ldapuser
+     uid: buser
+12 -> mail: buser@example.com
+13 -> maildrop: buser@mailhub.example.com
+
+
+ +
+     dn: uid=cuser, dc=example, dc=com
+     objectclass: top
+     objectclass: ldapuser
+     uid: cuser
+14 -> mail: cuser@example.com
+
+
+ +
+     dn: uid=duser, dc=example, dc=com
+     objectclass: top
+     objectclass: ldapuser
+     uid: duser
+15 -> mail: duser@example.com
+
+
+ +
+ +

Our first use case ignores the "memberdn" attributes, and assumes +that groups hold only direct "memberaddr" strings as in (3), (4), (8) and +(9). The goal is to map the group address to the list of constituent +"memberaddr" values. This is simple, ignoring the various connection +related settings (hosts, ports, bind settings, timeouts, ...) we have: +

+ +
+
+    simple.cf:
+        ...
+        search_base = dc=example, dc=com
+        query_filter = mail=%s
+        result_attribute = memberaddr
+    $ postmap -q agroup@example.com ldap:/etc/postfix/simple.cf \
+        auser@example.org,buser@example.org
+
+
+ +

We search "dc=example, dc=com". The "mail" attribute is used in the +query_filter to locate the right group, the "result_attribute" setting +described in ldap_table(5) is used to specify that "memberaddr" values +from the matching group are to be returned as a comma separated list. +Always check tables using postmap(1) with the "-q" option, before +deploying them into production use in main.cf.

+ +

Our second use case instead expands "memberdn" attributes (1), (2), +(6) and (7), follows the DN references and returns the "maildrop" of the +referenced user entries. Here we use the "special_result_attribute" +setting from ldap_table(5) to designate the "memberdn" attribute +as holding DNs of the desired member entries. The "result_attribute" +setting selects which attributes are returned from the selected DNs. It +is important to choose a result attribute that is not also present in +the group object, because result attributes are collected from both +the group and the member DNs. In this case we choose "maildrop" and +assume for the moment that groups never have a "maildrop" (the "bgroup" +"maildrop" attribute is for a different use case). The returned data for +"auser" and "buser" is from items (11) and (13) in the example data.

+ +
+
+    special.cf:
+        ...
+        search_base = dc=example, dc=com
+        query_filter = mail=%s
+        result_attribute = maildrop
+        special_result_attribute = memberdn
+    $ postmap -q agroup@example.com ldap:/etc/postfix/special.cf \
+        auser@mailhub.example.com,buser@mailhub.example.com
+
+
+ +

Note: if the desired member object result attribute is always also +present in the group, you get surprising results: the expansion also +returns the address of the group. This is a known limitation of Postfix +releases prior to 2.4, and is addressed in the new with Postfix 2.4 +"leaf_result_attribute" feature described in ldap_table(5).

+ +

Our third use case has some groups that are expanded immediately, +and other groups that are forwarded to a dedicated mailing list manager +host for delayed expansion. This uses two LDAP tables, one for users +and forwarded groups and a second for groups that can be expanded +immediately. It is assumed that groups that require forwarding are +never nested members of groups that are directly expanded.

+ +
+
+    no_expand.cf:
+        ...
+        search_base = dc=example, dc=com
+        query_filter = mail=%s
+        result_attribute = maildrop
+    expand.cf
+        ...
+        search_base = dc=example, dc=com
+        query_filter = mail=%s
+        result_attribute = maildrop
+        special_result_attribute = memberdn
+    $ postmap -q auser@example.com \
+        ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+        auser@mailhub.example.com
+    $ postmap -q agroup@example.com \
+        ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+        auser@mailhub.example.com,buser@mailhub.example.com
+    $ postmap -q bgroup@example.com \
+        ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+        bgroup@mlm.example.com
+
+
+ +

Non-group objects and groups with delayed expansion (those that have a +maildrop attribute) are rewritten to a single maildrop value. Groups that +don't have a maildrop are expanded as the second use case. This admits +a more elegant solution with Postfix 2.4 and later.

+ +

Our final use case is the same as the third, but this time uses new +features in Postfix 2.4. We now are able to use just one LDAP table and +no longer need to assume that forwarded groups are never nested inside +expanded groups.

+ +
+
+    fancy.cf:
+        ...
+        search_base = dc=example, dc=com
+        query_filter = mail=%s
+        result_attribute = memberaddr
+        special_result_attribute = memberdn
+        terminal_result_attribute = maildrop
+        leaf_result_attribute = mail
+    $ postmap -q auser@example.com ldap:/etc/postfix/fancy.cf \
+        auser@mailhub.example.com
+    $ postmap -q cuser@example.com ldap:/etc/postfix/fancy.cf \
+        cuser@example.com
+    $ postmap -q agroup@example.com ldap:/etc/postfix/fancy.cf \
+        auser@mailhub.example.com,buser@mailhub.example.com,auser@example.org,buser@example.org
+    $ postmap -q bgroup@example.com ldap:/etc/postfix/fancy.cf \
+        bgroup@mlm.example.com
+
+
+ +

Above, delayed expansion is enabled via "terminal_result_attribute", +which, if present, is used as the sole result and all other expansion is +suppressed. Otherwise, the "leaf_result_attribute" is only returned for +leaf objects that don't have a "special_result_attribute" (non-groups), +while the "result_attribute" (direct member address of groups) is returned +at every level of recursive expansion, not just the leaf nodes. This fancy +example illustrates all the features of Postfix 2.4 group expansion.

+ +

Other uses of LDAP lookups

+ +Other common uses for LDAP lookups include rewriting senders and +recipients with Postfix's canonical lookups, for example in order +to make mail leaving your site appear to be coming from +"First.Last@example.com" instead of "userid@example.com". + +

Notes and things to think about

+ + + +

Feedback

+ +

If you have questions, send them to postfix-users@postfix.org. Please +include relevant information about your Postfix setup: LDAP-related +output from postconf, which LDAP libraries you built with, and which +directory server you're using. If your question involves your directory +contents, please include the applicable bits of some directory entries.

+ +

Credits

+ + + +And of course Wietse. + + + + diff --git a/proto/LINUX_README.html b/proto/LINUX_README.html new file mode 100644 index 0000000..30f7a30 --- /dev/null +++ b/proto/LINUX_README.html @@ -0,0 +1,104 @@ + + + + + + +Postfix and Linux + + + + + + + +

Postfix and Linux

+ +
+ +

Host lookup issues

+ +

By default Linux /etc/hosts lookups do not support multiple IP +address per hostname. This causes warnings from the Postfix SMTP +server that "hostname XXX does not resolve to address YYY", and is +especially a problem with hosts that have both IPv4 and IPv6 +addresses. To fix, turn on support for multiple IP addresses:

+ +
+
+/etc/host.conf:
+    ...
+    # We have machines with multiple IP addresses.
+    multi on
+    ...
+
+
+ +

Alternatively, specify the RESOLV_MULTI environment variable +in main.cf:

+ +
+
+/etc/postfix/main.cf:
+    import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY DISPLAY LANG=C RESOLV_MULTI=on
+
+
+ +

Berkeley DB issues

+ +

If you can't compile Postfix because the file "db.h" +isn't found, then you MUST install the Berkeley DB development +package (name: db???-devel-???) that matches your system library. +You can find out what is installed with the rpm command. For example: +

+ +
+
+$ rpm -qf /usr/lib/libdb.so
+db4-4.3.29-2
+
+
+ +

This means that you need to install db4-devel-4.3.29-2 (on +some systems, specify "rpm -qf /lib/libdb.so" instead).

+ +

DO NOT download some Berkeley DB version from the network. +Every Postfix program will dump core when it is built with a different +Berkeley DB version than the version that is used by the system +library routines. See the DB_README file for further information. +

+ +

Procmail issues

+ +

On RedHat Linux 7.1 and later procmail no longer has +permission +to write the mail spool directory. Workaround:

+ +
+
+# chmod 1777 /var/spool/mail
+
+
+ +

Syslogd performance

+ +

LINUX syslogd uses synchronous writes by default. Because +of this, syslogd can actually use more system resources than +Postfix. To avoid such badness, disable synchronous mail logfile +writes by editing /etc/syslog.conf and by prepending a - to the +logfile name:

+ +
+
+/etc/syslog.conf:
+    mail.*                          -/var/log/mail.log
+
+
+ +

Send a "kill -HUP" to the syslogd to make the +change effective.

+ + + + diff --git a/proto/LMDB_README.html b/proto/LMDB_README.html new file mode 100644 index 0000000..f380c56 --- /dev/null +++ b/proto/LMDB_README.html @@ -0,0 +1,417 @@ + + + + + + +Postfix OpenLDAP LMDB Howto + + + + + + + +

Postfix OpenLDAP LMDB Howto

+ +
+ +

Introduction

+ +

Postfix uses databases of various kinds to store and look up +information. Postfix databases are specified as "type:name". OpenLDAP +LMDB (called "LMDB" from here on) implements the Postfix database +type "lmdb". The name of a Postfix LMDB database is the name of +the database file without the ".lmdb" suffix.

+ +

This document describes:

+ + + +

Building Postfix with LMDB support

+ +

Postfix normally does not enable LMDB support. To +build Postfix with LMDB support, use something like:

+ +
+
+% make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
+    AUXLIBS_LMDB="-L/usr/local/lib -llmdb"
+% make
+
+
+ +

Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LMDB. +With Postfix 3.0 and later, the old AUXLIBS variable still supports +building a statically-loaded LMDB database client, but only the new +AUXLIBS_LMDB variable supports building a dynamically-loaded or +statically-loaded LMDB database client.

+ +
+ +

Failure to use the AUXLIBS_LMDB variable will defeat the purpose +of dynamic database client loading. Every Postfix executable file +will have LMDB database library dependencies. And that was exactly +what dynamic database client loading was meant to avoid.

+ +
+ + +

Solaris may need this:

+ +
+
+% make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
+    AUXLIBS_LMDB="-R/usr/local/lib -L/usr/local/lib -llmdb"
+% make
+
+
+ +

The exact pathnames depend on how LMDB was installed.

+ +

When building Postfix fails with:

+ +
+
+undefined reference to `pthread_mutexattr_destroy'
+undefined reference to `pthread_mutexattr_init'
+undefined reference to `pthread_mutex_lock'
+
+
+ +

Add the "-lpthread" library to the "make makefiles" command.

+ +
+
+% make makefiles .... AUXLIBS_LMDB="... -lpthread"
+
+
+ +

Configuring LMDB settings

+ +

Postfix provides one configuration parameter that controls +LMDB database behavior.

+ + + +

Using LMDB maps with non-Postfix programs

+ +

Programs that use LMDB's built-in locking protocol will corrupt +a Postfix LMDB database or will read garbage.

+ +

Postfix does not use LMDB's built-in locking protocol, because +that would require world-writable lockfiles, and would violate +Postfix security policy. Instead, Postfix uses external locks based +on fcntl(2) to prevent writers from corrupting the database, and +to prevent readers from receiving garbage.

+ +

See lmdb_table(5) for a detailed description of the locking +protocol that all programs must use when they access a Postfix LMDB +database.

+ +

Required minimum LMDB patchlevel

+ +

Currently, Postfix requires LMDB 0.9.11 or later. The required +minimum LMDB patchlevel has evolved over time, as the result of +Postfix deployment experience:

+ + + +

Credits

+ + + + + + + + + + + + + + + + + + + + diff --git a/proto/LOCAL_RECIPIENT_README.html b/proto/LOCAL_RECIPIENT_README.html new file mode 100644 index 0000000..83e7d3b --- /dev/null +++ b/proto/LOCAL_RECIPIENT_README.html @@ -0,0 +1,180 @@ + + + + + + +Rejecting Unknown Local Recipients with Postfix + + + + + + + +

Rejecting Unknown Local Recipients with Postfix

+ +
+ +

Introduction

+ +

As of Postfix version 2.0, the Postfix SMTP server rejects mail +for unknown recipients in local domains (domains that match +$mydestination or the IP addresses in $inet_interfaces or +$proxy_interfaces) with "User unknown in local recipient table". +This feature was optional with earlier Postfix versions.

+ +

The good news is that this keeps undeliverable mail out of your +queue, so that your mail queue is not clogged up with undeliverable +MAILER-DAEMON messages.

+ +

The bad news is that it may cause mail to be rejected when you +upgrade from a Postfix system that was not configured to reject +mail for unknown local recipients.

+ +

This document describes what steps are needed in order to reject +unknown local recipients correctly.

+ + + +

Configuring local_recipient_maps +in main.cf

+ +

The local_recipient_maps parameter specifies lookup tables with +all names or addresses of local recipients. A recipient address is +local when its domain matches $mydestination, $inet_interfaces or +$proxy_interfaces. If a local username or address is not listed in +$local_recipient_maps, then the Postfix SMTP server will reject +the address with "User unknown in local recipient table".

+ +

The default setting, shown below, assumes that you use the +default Postfix local(8) delivery agent for local delivery, where +recipients are either UNIX accounts or local aliases:

+ +
+
+/etc/postfix/main.cf:
+    local_recipient_maps = proxy:unix:passwd.byname $alias_maps
+
+
+ +

To turn off unknown local recipient rejects by the SMTP server, +specify:

+ +
+
+/etc/postfix/main.cf:
+    local_recipient_maps =
+
+
+ +

That is, an empty value. With this setting, the Postfix SMTP +server will not reject mail with "User unknown in local recipient +table". Don't do this on systems that receive mail directly +from the Internet. With today's worms and viruses, Postfix will +become a backscatter source: it accepts mail for non-existent +recipients and then tries to return that mail as "undeliverable" +to the often forged sender address.

+ +

When you need to change the local_recipient_maps +setting in main.cf

+ + + +

Local recipient table format

+ +

If you use local files in postmap(1) format, then +local_recipient_maps expects the following table format:

+ + + +

If you use lookup tables based on NIS, LDAP, MYSQL, or PGSQL, +then local_recipient_maps does the same queries as for local files +in postmap(1) format, and expects the same results.

+ +

With regular expression tables, Postfix only queries with the +full recipient address, and not with the bare username or the +"@domain.tld" wild-card.

+ +

NOTE: a lookup table should always return a result when the address +exists, and should always return "not found" when the address does +not exist. In particular, a zero-length result does not count as +a "not found" result.

+ + + + diff --git a/proto/MAILDROP_README.html b/proto/MAILDROP_README.html new file mode 100644 index 0000000..4657df3 --- /dev/null +++ b/proto/MAILDROP_README.html @@ -0,0 +1,195 @@ + + + + + + +Postfix + Maildrop Howto + + + + + + + +

Postfix + Maildrop Howto

+ +
+ +

Introduction

+ +

This document discusses various options to plug the maildrop +delivery agent into Postfix:

+ + + +

Direct delivery without the local delivery agent

+ +

Postfix can be configured to deliver mail directly to maildrop, +without using the local(8) delivery agent as an intermediate. This +means that you do not get local aliases(5) expansion or $HOME/.forward +file processing. You would typically do this for hosted domains with +recipients that don't have UNIX home directories.

+ +

The following example shows how to use maildrop for some.domain +and for someother.domain. The example comes in two parts.

+ +

Part 1 describes changes to the main.cf file:

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     maildrop_destination_recipient_limit = 1
+ 3     virtual_mailbox_domains = some.domain someother.domain
+ 4     virtual_transport = maildrop
+ 5     virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
+ 6     virtual_alias_maps = hash:/etc/postfix/virtual_alias
+ 7 
+ 8 /etc/postfix/virtual_mailbox:
+ 9     user1@some.domain        ...text here does not matter...
+10     user2@some.domain        ...text here does not matter...
+11     user3@someother.domain   ...text here does not matter...
+12 
+13 /etc/postfix/virtual_alias:
+14     postmaster@some.domain           postmaster
+15     postmaster@someother.domain      postmaster
+
+
+ + + +

The vmail userid as used below is the user that maildrop should +run as. This would be the owner of the virtual mailboxes if they +all have the same owner. If maildrop is suid (see maildrop +documentation), then maildrop will change to the appropriate owner +to deliver the mail.

+ +

Note: Do not use the postfix user as the maildrop user.

+ +

Part 2 describes changes to the master.cf file:

+ +
+
+/etc/postfix/master.cf:
+    maildrop  unix  -       n       n       -       -       pipe
+      flags=ODRhu user=vmail argv=/path/to/maildrop -d ${recipient}
+
+
+ +

The pipe(8) manual page gives a detailed description of the +above command line arguments, and more.

+ +

If you want to support user+extension@domain style addresses, +use the following instead:

+ +
+
+/etc/postfix/master.cf:
+    maildrop  unix  -       n       n       -       -       pipe
+      flags=ODRhu user=vmail argv=/path/to/maildrop 
+      -d ${user}@${domain} ${extension} ${recipient} ${user} ${nexthop}
+
+
+ +

The mail is delivered to ${user}@${domain} (search key for +maildrop userdb lookup). The ${extension} and the other address +components are available to maildrop rules as $1, $2, $3, ... and +can be omitted from master.cf or ignored by maildrop when not +needed.

+ +

With Postfix 2.4 and earlier, use ${nexthop} instead of ${domain}. +

+ +

Indirect delivery via the local delivery agent

+ +

Postfix can be configured to deliver mail to maildrop via the +local delivery agent. This is slightly less efficient than the +"direct" approach discussed above, but gives you the convenience +of local aliases(5) expansion and $HOME/.forward file processing. +You would typically use this for domains that are listed in +mydestination and that have users with a UNIX system account.

+ +

To configure maildrop delivery for all UNIX system accounts:

+ +
+
+/etc/postfix/main.cf:
+    mailbox_command = /path/to/maildrop -d ${USER}
+
+
+ +

Note: ${USER} is spelled in upper case.

+ +

To enable maildrop delivery for specific users only, you can +use the Postfix local(8) delivery agent's mailbox_command_maps feature: +

+ +
+
+/etc/postfix/main.cf:
+    mailbox_command_maps = hash:/etc/postfix/mailbox_commands
+
+/etc/postfix/mailbox_commands:
+    you    /path/to/maildrop -d ${USER}
+
+
+ +

Maildrop delivery for specific users is also possible by +invoking it from the user's $HOME/.forward file:

+ +
+
+/home/you/.forward:
+    "|/path/to/maildrop -d ${USER}"
+
+
+ +

Credits

+ + + + + + diff --git a/proto/MAILLOG_README.html b/proto/MAILLOG_README.html new file mode 100644 index 0000000..9b56518 --- /dev/null +++ b/proto/MAILLOG_README.html @@ -0,0 +1,183 @@ + + + + + + +Postfix logging to file or stdout + + + + + + + +

Postfix +logging to file or stdout

+ +
+ +

Overview

+ +

Postfix supports it own logging system as an alternative to +syslog (which remains the default). This is available with Postfix +version 3.4 or later.

+ +

Topics covered in this document:

+ + + +

Configuring logging to file

+ +

Logging to file solves a usability problem for MacOS, and +eliminates multiple problems for systemd-based systems.

+ +
    + +

  1. Add the following line to master.cf if not already present +(note: there must be no whitespace at the start of the line):

    + +
    +
    +postlog   unix-dgram n  -       n       -       1       postlogd
+
    +
    + +

    Note: the service type "unix-dgram" was introduced with +Postfix 3.4. Remove the above line before backing out to an older +Postfix version.

    + +

  2. Configure Postfix to write logging, to, for example, +/var/log/postfix.log. See also the "Logfile +rotation" section below for logfile management.

    + +
    +
    +# postfix stop
+# postconf maillog_file=/var/log/postfix.log
+# postfix start
+
    +
    + +

    By default, the logfile name must start with "/var" or "/dev/stdout" +(the list of allowed prefixes is configured with the maillog_file_prefixes +parameter). This safety mechanism limits the damage from a single +configuration mistake.

    + +
+ +

Configuring logging to stdout

+ +

Logging to stdout is useful when Postfix runs in a container, +as it eliminates a syslogd dependency.

+ +
    + +

  1. Add the following line to master.cf if not already present (note: +there must be no whitespace at the start of the line):

    + +
    +
    +postlog   unix-dgram n  -       n       -       1       postlogd
+
    +
    + +

    Note: the service type "unix-dgram" was introduced with +Postfix 3.4. Remove the above line before backing out to an older +Postfix version.

    + +

  2. Configure main.cf with "maillog_file = /dev/stdout".

    + +

  3. Start Postfix with "postfix start-fg".

    + +
+ +

Rotating logs

+ +

The command "postfix logrotate" may be run by hand or +by a cronjob. It logs all errors, and reports errors to stderr if +run from a terminal. This command implements the following steps: +

+ + + +

Notes:

+ + + +

Limitations

+ +

Background:

+ + + +

Limitations:

+ + + + + + diff --git a/proto/MEMCACHE_README.html b/proto/MEMCACHE_README.html new file mode 100644 index 0000000..a48f9a8 --- /dev/null +++ b/proto/MEMCACHE_README.html @@ -0,0 +1,76 @@ + + + + + + +Postfix memcache client Howto + + + + + + + +

Postfix memcache client Howto

+ +
+ +

Introduction

+ +

The Postfix memcache client allows you to hook up Postfix to a +memcache server. The current implementation supports one memcache +server per Postfix table, with one optional Postfix database that +provides persistent backup. The Postfix memcache client supports +the lookup, update, delete and sequence operations. The sequence +(i.e. first/next) operation requires a backup database that supports +this operation.

+ +

Typically, the Postfix memcache client is used to reduce query +load on a persistent database, but it may also be used to query a +memory-only database for low-value, easy-to-recreate, information +such as a reputation cache for postscreen(8), verify(8) or greylisting. +

+ +

Limitations

+ + + +

Building Postfix with memcache support

+ +

The Postfix memcache client has no external dependencies, +and is therefore built into Postfix by default.

+ +

Configuring memcache lookup tables

+ +

Configuration is described in the memcache_table(5) manpage.

+ +

Credits

+ +

The first memcache client for Postfix was written by Omar Kilani, +and was based on the libmemcache library.

+ +

Wietse wrote the current memcache client from the ground up for +Postfix version 2.9. This implementation does not use libmemcache, +and bears no resemblance to earlier work.

+ + + + diff --git a/proto/MILTER_README.html b/proto/MILTER_README.html new file mode 100644 index 0000000..886299f --- /dev/null +++ b/proto/MILTER_README.html @@ -0,0 +1,951 @@ + + + + + + +Postfix before-queue Milter support + + + + + + + +

Postfix before-queue Milter support

+ +
+ +

Introduction

+ +

Postfix implements support for the Sendmail version 8 Milter +(mail filter) protocol. This protocol is used by applications that +run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT), +SMTP commands (HELO, MAIL FROM, etc.) as well as mail content +(headers and body). All this happens before mail is queued.

+ +

The reason for adding Milter support to Postfix is that there +exists a large collection of applications, not only to block unwanted +mail, but also to verify authenticity (examples: OpenDKIM and DMARC ) +or to digitally sign mail (example: OpenDKIM). +Having yet another Postfix-specific version of all that software +is a poor use of human and system resources.

+ +

The Milter protocol has evolved over time, and different Postfix +versions implement different feature sets. See the workarounds and limitations sections at the end of this +document for differences between Postfix and Sendmail implementations. +

+ +

This document provides information on the following topics:

+ + + +

How Milter applications plug into Postfix

+ +

The Postfix Milter implementation uses two different lists of +mail filters: one list of filters for SMTP mail only, +and one list of filters for non-SMTP mail. The two +lists have different capabilities, which is unfortunate. Avoiding +this would require major restructuring of Postfix.

+ + + +

For those who are familiar with the Postfix architecture, the +figure below shows how Milter applications plug into Postfix. Names +followed by a number are Postfix commands or server programs, while +unnumbered names inside shaded areas represent Postfix queues. To +avoid clutter, the path for local submission is simplified (the +OVERVIEW document has a more complete description of the Postfix +architecture).

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SMTP-only
filters 		non-SMTP
filters
+^
| 		|
v +
+^
|
|
| 		|
+|
|
v
Network -> smtpd(8) +
\
Network -> qmqpd(8) + -> cleanup(8) + -> incoming
/
pickup(8) +
:
Local -> sendmail(1) +
+ +
+ +

Building Milter applications

+ +

Milter applications have been written in C, JAVA and Perl, but +this document deals with C applications only. For these, you need +an object library that implements the Sendmail 8 Milter protocol. +Postfix currently does not provide such a library, but Sendmail +does.

+ +

Some +systems install the Sendmail libmilter library by default. With +other systems, libmilter may be provided by a package (called +"sendmail-devel" on some Linux systems).

+ +

Once libmilter is installed, applications such as OpenDKIM and +OpenDMARC +build out of the box without requiring any tinkering:

+ +
+
+$ gzcat opendkim-x.y.z.tar.gz | tar xf -
+$ cd opendkim-x.y.z
+$ ./configure ...options...
+$ make
+[...lots of output omitted...]
+$ make install
+
+
+ +

Running Milter applications

+ +

To run a Milter application, see the documentation of the filter +for options. A typical command looks like this:

+ +
+
+# /some/where/opendkim -l -u userid -p inet:portnumber@localhost ...other options...
+
+
+ +

Please specify a userid value that isn't used for other +applications (not "postfix", not "www", etc.).

+ +

Configuring Postfix

+ +

Like Sendmail, Postfix has a lot of configuration options that +control how it talks to Milter applications. Besides global options +that apply to all Milter applications, Postfix 3.0 and later +support per-Milter timeouts, per-Milter error handling, etc.

+ +

Information in this section:

+ + + +

SMTP-Only Milter applications

+ +

The SMTP-only Milter applications handle mail that arrives via +the Postfix smtpd(8) server. They are typically used to filter +unwanted mail, and to sign mail from authorized SMTP clients. Mail +that arrives via the Postfix smtpd(8) server is not filtered by the +non-SMTP filters that are described in the next section.

+ +
NOTE for Postfix versions that have a mail_release_date +before 20141018: do not use the header_checks(5) IGNORE action to remove +Postfix's own Received: message header. This causes problems with +mail signing filters. Instead, keep Postfix's own Received: message +header and use the header_checks(5) REPLACE action to sanitize +information.
+ +

You specify SMTP-only Milter applications (there can be more +than one) with the smtpd_milters parameter. Each Milter application +is identified by the name of its listening socket; other Milter +configuration options will be discussed in later sections. Milter +applications are applied in the order as specified, and the first +Milter application that rejects a command will override the responses +from other Milter applications.

+ +
+
+/etc/postfix/main.cf:
+    # Milters for mail that arrives via the smtpd(8) server.
+    # See below for socket address syntax.
+    smtpd_milters = inet:localhost:portnumber ...other filters...
+
+
+ +

The general syntax for listening sockets is as follows:

+ +
+ +
+ +
unix:pathname

Connect to the local +UNIX-domain server that is bound to the specified pathname. If the +smtpd(8) or cleanup(8) process runs chrooted, an absolute pathname +is interpreted relative to the Postfix queue directory.

+ +
inet:host:port

+Connect to the specified TCP port on the specified local or remote +host. The host and port can be specified in numeric or symbolic +form.

+ +

NOTE: Postfix syntax differs from Milter syntax which has the +form inet:port@host.

+ +
+ +
+ +

For advanced configuration see "Different +settings for different SMTP clients" and "Different settings for different Milter +applications".

+ +

Non-SMTP Milter applications

+ +

The non-SMTP Milter applications handle mail that arrives via +the Postfix sendmail(1) command-line or via the Postfix qmqpd(8) +server. They are typically used to digitally sign mail. Although +non-SMTP filters can be used to filter unwanted mail, there are +limitations as discussed later in this section. Mail that arrives +via the Postfix smtpd(8) server is not filtered by the non-SMTP +filters.

+ +

NOTE: Do not use the header_checks(5) IGNORE action to remove +Postfix's own Received: message header. This causes problems with +mail signing filters. Instead, keep Postfix's own Received: message +header and use the header_checks(5) REPLACE action to sanitize +information.

+ +

You specify non-SMTP Milter applications with the non_smtpd_milters +parameter. This parameter uses the same syntax as the smtpd_milters +parameter in the previous section. As with the SMTP-only filters, +you can specify more than one Milter application; they are applied +in the order as specified, and the first Milter application that +rejects a command will override the responses from the other +applications.

+ +
+
+/etc/postfix/main.cf:
+    # Milters for non-SMTP mail.
+    # See below for socket address syntax.
+    non_smtpd_milters = inet:localhost:portnumber ...other filters...
+
+
+ +

There's one small complication when using Milter applications +for non-SMTP mail: there is no SMTP session. To keep Milter +applications happy, the Postfix cleanup(8) server actually has to +simulate the SMTP client CONNECT and DISCONNECT events, and the +SMTP client EHLO, MAIL FROM, RCPT TO and DATA commands.

+ + + +

This generally works as expected, with only one exception: +non-SMTP filters must not REJECT or TEMPFAIL simulated RCPT TO +commands. When a non_smtpd_milters application REJECTs or TEMPFAILs +a recipient, Postfix will report a configuration error, and mail +will stay in the queue.

+ +

Signing internally-generated bounce messages

+ +

Postfix normally does not apply content filters to mail +that is generated internally such as bounces or Postmaster +notifications. Filtering internally-generated bounces would result +in loss of mail when a filter rejects a message, as the resulting +double-bounce message would almost certainly also be blocked.

+ +

To sign Postfix's own bounce messages, enable filtering of +internally-generated bounces (line 2 below), and don't reject any +internally-generated bounces with non_smtpd_milters, header_checks +or body_checks (lines 3-5 below).

+ +
+
+1 /etc/postfix/main.cf:
+2     internal_mail_filter_classes = bounce
+3     non_smtpd_milters = don't reject internally-generated bounces
+4     header_checks = don't reject internally-generated bounces
+5     body_checks = don't reject internally-generated bounces
+
+
+ +

Milter error handling

+ +

The milter_default_action parameter specifies how Postfix handles +Milter application errors. The default action is to respond with a +temporary error status, so that the client will try again later. +Specify "accept" if you want to receive mail as if the filter does +not exist, and "reject" to reject mail with a permanent status. +The "quarantine" action is like "accept" but freezes the message +in the "hold" queue, and is available with Postfix 2.6 or later. +

+ +
+
+/etc/postfix/main.cf:
+    # What to do in case of errors? Specify accept, reject, tempfail,
+    # or quarantine (Postfix 2.6 or later).
+    milter_default_action = tempfail
+
+
+ +

See "Different settings for different +Milter applications" for advanced configuration options.

+ +

Milter protocol version

+ +

As Postfix is not built with the Sendmail libmilter library, +you may need to configure the Milter protocol version that Postfix +should use. The default version is 6 (before Postfix 2.6 the default +version is 2).

+ +
+
+/etc/postfix/main.cf:
+    # Postfix ≥ 2.6
+    milter_protocol = 6
+    # 2.3 ≤ Postfix ≤ 2.5
+    milter_protocol = 2
+
+
+ +

If the Postfix milter_protocol setting specifies a too low +version, the libmilter library will log an error message like this: +

+ +
+
+application name: st_optionneg[xxxxx]: 0xyy does not fulfill action requirements 0xzz
+
+
+ +

The remedy is to increase the Postfix milter_protocol version +number. See, however, the limitations +section below for features that aren't supported by Postfix.

+ +

With Postfix 2.7 and earlier, if the Postfix milter_protocol +setting specifies a too high +version, the libmilter library simply hangs up without logging a +warning, and you see a Postfix warning message like one of the +following:

+ +
+
+warning: milter inet:host:port: can't read packet header: Unknown error : 0
+warning: milter inet:host:port: can't read packet header: Success
+warning: milter inet:host:port: can't read SMFIC_DATA reply packet header: No such file or directory
+
+
+ +

The remedy is to lower the Postfix milter_protocol version +number. Postfix 2.8 and later will automatically turn off protocol +features that the application's libmilter library does not expect. +

+ +

See "Different settings for different +Milter applications" for advanced configuration options.

+ +

Milter protocol timeouts

+ +

Postfix uses different time limits at different Milter protocol +stages. The table shows the timeout settings and the corresponding +protocol stages +(EOH = end of headers; EOM = end of message).

+ +
+ + + + + + + + + + + +
Postfix parameter Time limit Milter +protocol stage
milter_connect_timeout 30s CONNECT +
milter_command_timeout 30s HELO, +MAIL, RCPT, DATA, UNKNOWN
milter_content_timeout 300s HEADER, +EOH, BODY, EOM
+ +
+ +

Beware: 30s may be too short for Milter applications that do +lots of DNS lookups. However, if you increase the above timeouts +too much, remote SMTP clients may hang up and mail may be delivered +multiple times. This is an inherent problem with before-queue +filtering.

+ +

See "Different settings for different +Milter applications" for advanced configuration options.

+ +

Different settings for different Milter +applications

+ +

The previous sections list a number of Postfix main.cf parameters +that control time limits and other settings for all Postfix Milter +clients. This is sufficient for simple configurations. With more +complex configurations it becomes desirable to have different +settings for different Milter clients. This is supported with Postfix +3.0 and later.

+ +

The following example shows a "non-critical" Milter client with +a short connect timeout, and with "accept" as default action when +the service is unvailable.

+ +
+
+1 /etc/postfix/main.cf:
+2     smtpd_milters = { inet:host:port,
+3         connect_timeout=10s, default_action=accept }
+
+
+ +

Instead of a server endpoint, we now have a list enclosed in {}.

+ + + +

Inside the list, syntax is similar to what we already know from +main.cf: items separated by space or comma. There is one difference: +you must enclose a setting in parentheses, as in "{ name = value +}", if you want to have space or comma within a value or around +"=".

+ +

Different settings for different SMTP +clients

+ +

The smtpd_milter_maps feature supports different Milter settings +for different client IP addresses. Lookup results override the the +global smtpd_milters setting, and have the same syntax. For example, +to disable Milter settings for local address ranges:

+ +
+/etc/postfix/main.cf:
+    smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_map
+    smtpd_milters = inet:host:port, { inet:host:port, ... }, ...
+
+/etc/postfix/smtpd_milter_map:
+    # Disable Milters for local clients.
+    127.0.0.0/8    DISABLE
+    192.168.0.0/16 DISABLE
+    ::/64          DISABLE
+    2001:db8::/32  DISABLE
+
+ +

This feature is available with Postfix 3.2 and later.

+ +

Sendmail macro emulation

+ +

Postfix emulates a limited number of Sendmail macros, as shown +in the table. Some macro values depend on whether a recipient is +rejected (rejected recipients are available on request by the Milter +application). Different macros are available at different Milter +protocol stages (EOH = end-of-header, EOM = end-of-message); their +availability is not +always the same as in Sendmail. See the workarounds section below for solutions. +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Sendmail macro Milter protocol stage Description
i DATA, EOH, EOM Queue ID, also +Postfix queue file name
j Always Value of myhostname
_ Always The validated client name +and address
{auth_authen} MAIL, DATA, EOH, EOM SASL +login name
{auth_author} MAIL, DATA, EOH, EOM SASL +sender
{auth_type} MAIL, DATA, EOH, EOM SASL +login method
{client_addr} Always Remote client +IP address
{client_connections} CONNECT +Connection concurrency for this client (zero if the client is +excluded from all smtpd_client_* limits).
{client_name} Always Remote client +hostname
When address → name lookup or name → address +verification fails: "unknown"
{client_port} Always (Postfix ≥2.5) Remote client TCP port
{client_ptr} CONNECT, HELO, MAIL, DATA Client name from address → name lookup
When address +→ name lookup fails: "unknown"
{cert_issuer} HELO, MAIL, DATA, EOH, EOM +TLS client certificate issuer
{cert_subject} HELO, MAIL, DATA, EOH, EOM TLS client certificate subject
{cipher_bits} HELO, MAIL, DATA, EOH, EOM +TLS session key size
{cipher} HELO, MAIL, DATA, EOH, EOM TLS +cipher
{daemon_addr} Always (Postfix ≥3.2) Local server IP address
{daemon_name} Always value of +milter_macro_daemon_name
{daemon_port} Always (Postfix ≥3.2) Local server TCP port
{mail_addr} MAIL Sender address +
{mail_host} MAIL (Postfix ≥ 2.6, only with +smtpd_milters) Sender next-hop destination
{mail_mailer} MAIL (Postfix ≥ 2.6, only with +smtpd_milters) Sender mail delivery transport
{rcpt_addr} RCPT Recipient address +
With rejected recipient: descriptive text
{rcpt_host} RCPT (Postfix ≥ 2.6, only with +smtpd_milters) Recipient next-hop destination
With +rejected recipient: enhanced status code
{rcpt_mailer} RCPT (Postfix ≥ 2.6, only with +smtpd_milters) Recipient mail delivery transport
+With rejected recipient: "error"
{tls_version} HELO, MAIL, DATA, EOH, EOM TLS protocol version
v Always value of milter_macro_v +
+ +
+ +

What macros will Postfix send to Milters?

+ +

Postfix sends specific sets of macros at different Milter protocol +stages. The sets are configured with the parameters as shown in the +table below (EOH = end of headers; EOM = end of message). The +protocol version is a number that Postfix sends at the beginning +of the Milter protocol handshake.

+ +

As of Sendmail 8.14.0, Milter applications can specify what +macros they want to receive at different Milter protocol stages. +An application-specified list takes precedence over a Postfix-specified +list.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Postfix parameter Milter protocol version Milter protocol stage
milter_connect_macros 2 or higher +CONNECT
milter_helo_macros 2 or higher +HELO/EHLO
milter_mail_macros 2 or higher MAIL +FROM
milter_rcpt_macros 2 or higher RCPT +TO
milter_data_macros 4 or higher DATA +
milter_end_of_header_macros 6 or higher EOH
milter_end_of_data_macros 2 or higher EOM
milter_unknown_command_macros 3 or higher unknown command
+ +
+ +

By default, Postfix will send only macros whose values have been +updated with information from main.cf or master.cf, from an SMTP session +(for example; SASL login, or TLS certificates) or from a Mail delivery +transaction (for example; queue ID, sender, or recipient).

+ +

To force a macro to be sent even when its value has not been updated, +you may specify macro default values with the milter_macro_defaults +parameter. Specify zero or more name=value pairs separated by +comma or whitespace; you may even specify macro names that Postfix does +know about!

+ +

Workarounds

+ + + +

Limitations

+ +

This section lists limitations of the Postfix Milter implementation. +Some limitations will be removed as the implementation is extended +over time. Of course the usual limitations of before-queue filtering +will always apply. See the CONTENT_INSPECTION_README document for +a discussion.

+ + + + + + diff --git a/proto/MULTI_INSTANCE_README.html b/proto/MULTI_INSTANCE_README.html new file mode 100644 index 0000000..a2574df --- /dev/null +++ b/proto/MULTI_INSTANCE_README.html @@ -0,0 +1,1274 @@ + + + + + + +Managing multiple Postfix instances on a single host + + + + + + + +

Managing +multiple Postfix instances on a single host

+ +
+ +

Overview

+ +

This document is a guide to managing multiple Postfix instances +on a single host using the postmulti(1) instance manager. Multi-instance +support is available with Postfix version 2.6 and later. See the +postfix-wrapper(5) manual page for background on the instance +management framework, and on how to deploy a custom instance manager. +

+ +

Topics covered in this document:

+ + + +

Why multiple Postfix instances

+ +

Postfix is a general-purpose mail system that can be configured +to serve a variety of needs. Examples of Postfix applications are:

+ + + +

A single Postfix configuration can provide many or all of these +services, but a complex interplay of settings may be required, for +example with master.cf options overriding main.cf settings. In this +document we take the view that multiple Postfix instances may be a +simpler way to configure a multi-function Postfix system. With +multiple Postfix instances, each instance has its own directories +for configuration, queue and data files, but it shares all Postfix +program and documentation files with other instances.

+ +

Since there is no single right way to configure your system, +we recommend that you choose what makes you most comfortable. If +different Postfix services don't involve incompatible main.cf or +master.cf settings, and if they can be combined together without +complex tricks, then a single monolithic configuration may be the +simplest approach.

+ +

The purpose of multi-instance support in Postfix is not to force +you to create multiple Postfix instances, but rather to give you a +choice. Multiple instances give you the freedom to tune each Postfix +instance to a single task that it does well and to combine instances +into complete systems.

+ +

With the introduction of the postmulti(1) utility and the reduction +of the per-instance configuration footprint of a secondary Postfix +instance to just a main.cf and master.cf file (other files are now in +shared locations), we hope that multiple instances will be easier to +use than ever before.

+ +

Null-client instances versus service instances

+ +

In the multi-instance approach to configuring Postfix, the first +simplification is with the default local-submission Postfix instance. +

+ +

Most UNIX systems require support for email submission with the +sendmail(1) command so that system processes such as cron jobs can +send status reports, and so that system users can send email with +command-line utilities. Such email can be handled with a null-client +Postfix configuration that forwards all mail to a central mail hub. +The null client will typically either not run an SMTP listener at +all (master_service_disable = inet), or it will listen only on the +loopback interface (inet_interfaces = loopback-only).

+ +

When implementing specialized servers for inbound Internet +email, outbound MTAs, internal mail hubs, and so on, we recommend +using a null client for local submission and creating single-function +secondary Postfix instances to serve the specialized needs.

+ +
+ +

Note: usually, you need to use different "myhostname" settings +when you run multiple instances on the same host. Otherwise, there +will be false "mail loops back to myself" alarms when one instance +tries to send mail into another instance. Typically, the null-client +instance will use the system's hostname, and other instances will +use their own dedicated "myhostname" settings. Different names are +not needed when instances send mail to each other with a protocol +other than SMTP, or with SMTP over a TCP port other than 25 as is +usual with SMTP-based content filters.

+ +
+ +

Multi-instance walk-through

+ +

Before discussing the fine details of multi-instance operation +we first show the steps for creating a border mail server. This +server has with a null-client Postfix instance for local submission, +an input Postfix instance to receive mail from the Internet, plus +an advanced SMTP +content-filter and an output Postfix instance to deliver filtered +email to its internal destination.

+ +

Setting up the null-client Postfix instance

+ +

On a border mail hub, while mail from the Internet requires a +great deal of scrutiny, locally submitted messages are typically +limited to mail from cron jobs and other system services. In this +regard the border MTA is not different from other Unix hosts in +your environment. For this reason, it will submit locally-generated +email to the internal mail hub. We start the construction of the +border mail server with the default +instance, which will be a local-submission null client: +

+ +
+
+/etc/postfix/main.cf:
+    # We are mta1.example.com
+    #
+    myhostname = mta1.example.com
+    mydomain = example.com
+
+    # Flat user-account namespace in example.com:
+    #
+    #   user@example.com not user@host.example.com
+    #
+    myorigin = $mydomain
+
+    # Postfix 2.6+, disable inet services, specifically disable smtpd(8)
+    #
+    master_service_disable = inet
+
+    # No local delivery:
+    #
+    mydestination =
+    local_transport = error:5.1.1 Mailbox unavailable
+    alias_database =
+    alias_maps =
+    local_recipient_maps =
+
+    # Send everything to the internal mailhub
+    #
+    relayhost = [mailhub.example.com]
+
+    # Indexed table macro:
+    # (use "hash", ... when cdb is not available)
+    #
+    default_database_type = cdb
+    indexed = ${default_database_type}:${config_directory}/
+
+    # Expose origin host of mail from "root", ...
+    #
+    smtp_generic_maps = ${indexed}generic
+
+    # Send messages addressed to "root", ... to the MTA support team
+    #
+    virtual_alias_maps = ${indexed}virtual
+
+/etc/postfix/generic:
+    # The smarthost supports "+" addressing (recipient_delimiter = +).
+    # Mail from "root" exposes the origin host, without replies
+    # and bounces going back to the same host.
+    #
+    # On clustered MTAs this file is typically machine-built from
+    # a template file. The build process expands the template into
+    # "mtaadmin+root=mta1"
+    #
+    root    	mtaadmin+root=mta1
+
+/etc/postfix/virtual:
+    # Caretaker aliases:
+    #
+    root    	mtaadmin
+    postmaster	root
+
+
+ +

You would typically also add a Makefile, to automatically run +postmap(1) commands when source files change. This Makefile also +creates a "generic" database when none exists.

+ +
+
+/etc/postfix/Makefile:
+    MTAADMIN=mtaadmin
+
+    all: virtual.cdb generic.cdb
+
+    generic: Makefile
+	    @echo Creating $@
+	    @rm -f $@.tmp
+	    @printf '%s\t%s+root=%s\n' root ${MTAADMIN} `uname -n` > $@.tmp
+	    @mv $@.tmp generic
+
+    %.cdb: %
+	    postmap cdb:$<
+
+
+ +

Construct the "virtual" and "generic" databases (the latter is +created by running "make"), then start and test the null-client: +

+ +
+
+# cd /etc/postfix; make
+# postfix start
+# sendmail -i -f root -t <<EOF
+From: root
+To: root
+Subject: test
+
+testing
+EOF
+
+
+ +

The test message should be delivered the members of the "mtaadmin" +address group (or whatever address group you choose) with the +following headers:

+ +
+
+From: mtaadmin+root=mta1@example.com
+To: mtadmin+root=mta1@example.com
+Subject: test
+
+
+ +

Setting up the "output" Postfix instance

+ +

With the null-client instance out of the way, we can create the +MTA "output" instance that will deliver filtered mail to the inside +network. We add the "output" instance first, because the output +instance needs to be up and running before the input instance can +be fully tested, and when the system boots, the "output" instance +must start before the input instance. We will put the output and +input instances into a single instance group named "mta".

+ +

Just once, when adding the first secondary instance, enable +multi-instance support in the default (null-client) instance:

+ +
+
+# postmulti -e init
+
+
+ +

Then create the output instance:

+ +

+
+# postmulti -I postfix-out -G mta -e create
+
+
+ +

The instance configuration directory defaults to /etc/postfix-out, +more precisely, the "postfix-out" subdirectory of the parent directory +of the default-instance configuration directory. The new instance will +be created in a "disabled" state:

+ +
+
+/etc/postfix-out/main.cf
+    #
+    # ... "stock" main.cf settings ...
+    #
+    multi_instance_name = postfix-out
+    queue_directory = /var/spool/postfix-out
+    data_directory = /var/lib/postfix-out
+    #
+    multi_instance_enable = no
+    master_service_disable = inet
+    authorized_submit_users =
+
+
+ +

This instance has a "stock" master.cf file, and its queue and +data directories, also named "postfix-out", will be located in the +same parent directories as the corresponding directories of the +default instance (e.g., /var/spool/postfix-out and /var/lib/postfix-out). +

+ +

While this instance is immediately safe to start, it is not yet +usefully configured. It needs to be customized to fit the role of a +post-filter re-injection SMTP service. Typical additions include:

+ +
+
+/etc/postfix-out/master.cf:
+    # Replace default "smtp inet" entry with one listening on port 10026.
+    127.0.0.1:10026     inet  n       -       n       -       -       smtpd
+
+/etc/postfix-out/main.cf
+    # ...
+
+    # Comment out if you don't use IPv6 internally
+    # inet_protocols = ipv4
+    inet_interfaces = loopback-only
+    mynetworks_style = host
+    smtpd_authorized_xforward_hosts = $mynetworks
+
+    # Don't anvil(8) control the re-injection port.
+    #
+    smtpd_client_connection_count_limit = 0
+    smtpd_client_event_limit_exceptions = $mynetworks
+
+    # Best practice when inet_interfaces is set, as this is not a
+    # "secondary IP personality" configuration.
+    #
+    smtp_bind_address = 0.0.0.0
+
+    # All header rewriting happens upstream
+    #
+    local_header_rewrite_clients =
+
+    # No local delivery on border gateway
+    #
+    mydestination =
+    alias_maps =
+    alias_database =
+    local_recipient_maps =
+    local_transport = error:5.1.1 Mailbox unavailable
+
+    # May need a recipient_delimiter for per-user transport lookups:
+    #
+    recipient_delimiter = +
+
+    # Only one (unrestricted client)
+    # With multiple instances, rarely need "-o param=value" overrides
+    # in master.cf, each instance gets its own main.cf file.
+    #
+    # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+    smtpd_relay_restrictions =
+    smtpd_recipient_restrictions = permit_mynetworks, reject
+
+    # Tolerate occasional high latency in the  content filter.
+    #
+    smtpd_timeout = 1200s
+
+    # Best when empty, with all parent domain matches explicit.
+    #
+    parent_domain_matches_subdomains =
+
+    # Use the "relay" transport for inbound mail, and the default
+    # "smtp" transport for outbound mail (bounces, ...). The latter
+    # won't starve the former of delivery agent slots.
+    #
+    relay_domains = example.com, .example.com
+
+    # With xforward, match the input instance setting, if you
+    # want "yes", set both to "yes".
+    #
+    smtpd_client_port_logging = no
+
+    # Transport settings ...
+    # Message size limit
+    # Concurrency tuning for "relay" and "smtp" transport
+    # ...
+
+
+ +

With the "output" configuration in place, enable and start the +instance:

+ +
+
+1 # postmulti -i postfix-out -x postconf -e \
+2     "master_service_disable =" "authorized_submit_users = root"
+3 # postmulti -i postfix-out -e enable
+4 # postmulti -i postfix-out -p start
+
+
+ +

This uses the postmulti(1) command to invoke postconf(1) in the +context (MAIL_CONFIG=/etc/postfix-out) of the output instance.

+ + + +

Test the output instance by submitting probe messages via "sendmail +-bv" and "telnet". For production systems, in-depth configuration tests +should be done on a lab system. The simple tests just suggested will only +confirm successful deployment of a configuration that should already be +known good.

+ +

Setting up the content-filter proxy

+ +

With the output instance ready, deploy your content-filter +proxy. Most proxies will need their own /etc/rc* start/stop script. +Some proxies, however, are started on demand by the Postfix spawn(8) +service, in which case you need to add the relevant spawn(8) entry +to the output instance master.cf file.

+ +

Configure the proxy to listen on 127.0.0.1:10025 and to re-inject +filtered email to 127.0.0.1:10026. Start the proxy service if +necessary, then test the proxy via "telnet" or automated SMTP +injectors. The proxy should support the following ESMTP features: +DSN, 8BITMIME, and XFORWARD. In addition, the proxy should support +multiple mail deliveries within an SMTP session.

+ +

Setting up the input Postfix instance

+ +

The input Postfix instance receives mail from the network and +sends it through the content filter. Now we create the input instance, +also part of the "mta" instance group:

+ +
+
+# postmulti -I postfix-in -G mta -e create
+
+
+ +

The new instance configuration directory defaults to /etc/postfix-in, +more precisely, the "postfix-in" subdirectory of the parent directory +of the default-instance configuration directory. The new instance will +be created in a "disabled" state:

+ +
+
+/etc/postfix-in/main.cf
+    #
+    # ... "stock" main.cf settings ...
+    #
+    multi_instance_name = postfix-in
+    queue_directory = /var/spool/postfix-in
+    data_directory = /var/lib/postfix-in
+    #
+    multi_instance_enable = no
+    master_service_disable = inet
+    authorized_submit_users =
+
+
+ +

As before, make appropriate changes to main.cf and master.cf to +make the instance production ready. Consider setting "soft_bounce = yes" +during the first few hours of deployment, so you can iron-out any unexpected +"kinks".

+ +

Manual testing can start with: + +

+
+/etc/postfix-in/main.cf
+    # Accept only local traffic, but allow impersonation:
+    inet_interfaces = 127.0.0.1
+    smtpd_authorized_xclient_hosts = 127.0.0.1
+
+
+ +

This allows you to use the Postfix-specific XCLIENT SMTP command to safely +simulate connections from remote systems before any remote systems +are able to connect. If the test results look good, revert the above +settings to the required production values. Typical settings in the +pre-filter input instance include:

+ +
+
+/etc/postfix-in/main.cf
+    #
+    # ... 
+    #
+
+    # No local delivery on border gateway
+    #
+    mydestination =
+    alias_maps =
+    alias_database =
+    local_recipient_maps =
+    local_transport = error:5.1.1 Mailbox unavailable
+
+    # Don't rewrite remote headers
+    #
+    local_header_rewrite_clients =
+
+    # All recipients of not yet filtered email go to the same filter together.
+    #
+    # With multiple instances, the content-filter is specified
+    # via transport settings not the "content_filter" transport
+    # switch override! Here the filter listens on local port 10025.
+    #
+    # If you need to route some users or recipient domains directly to the
+    # output instance bypassing the filter, just define a transport table
+    # with suitable entries.
+    #
+    default_transport = smtp:[127.0.0.1]:10025
+    relay_transport = $default_transport
+    virtual_transport = $default_transport
+    transport_maps =
+
+    # Pass original client log information through the filter.
+    #
+    smtp_send_xforward_command = yes
+
+    # Avoid splitting the envelope and scanning messages multiple times.
+    # Match the re-injection server's recipient limit.
+    #
+    smtp_destination_recipient_limit = 1000
+
+    # Tolerate occasional high latency in the content filter.
+    #
+    smtp_data_done_timeout = 1200s
+
+    # With xforward, match the output instance setting, if you
+    # want "yes", set both to "yes".
+    #
+    smtpd_client_port_logging = no
+
+    # ... Lots of settings for inbound MX host ...
+
+
+ +

With the "input" instance configured, enable and start it:

+ +
+
+# postmulti -i postfix-in -x postconf -e \
+    "master_service_disable =" "authorized_submit_users = root"
+# postmulti -i postfix-in -e enable
+# postmulti -i postfix-in -p start
+
+
+ +

That's it. You now have a 3-instance configuration. A null-client +sending all locally submitted mail to the internal mail hub and a pair of +"mta" instances that receive mail from the Internet, pass it through a +content-filter, and then deliver it to the internal destination.

+ +

Running "postfix start" or "postfix stop" will now start/stop all +three Postfix instances. You can use "postfix -c /config/path start" +to start just one instance, or use the instance name (or instance +group name) via postmulti(1):

+ +
+
+# postmulti -i - -p stop
+# postmulti -g mta -p status
+# postmulti -i postfix-out -p flush
+# postmulti -i postfix-in -p reload
+# ...
+
+
+ +

This example ends the multi-instance "walk through". The remainder +of this document provides background information on Postfix +multi-instance support features and options.

+ +

Components of a Postfix system

+ +

A Postfix system consists of the following components:

+ +

Shared among all instances:

+ + + +

Private to each instance:

+ + + +

The Postfix configuration parameters mentioned above are +collectively referred to as "installation parameters". Their default +values are set when the Postfix software is built from source, and +all but one may be optionally set to a non-default value via the +main.cf file. The one parameter that (catch-22) cannot be set in +main.cf is $config_directory, as this defines the location of the +main.cf file itself.

+ +

Though config_directory cannot be set in main.cf, postfix(1) and +most of the other command-line Postfix utilities allow you to specify a +non-default configuration directory via a command line option (typically +-c) or via the MAIL_CONFIG environment variable. In this way, +it is possible to have multiple configuration directories on the same +machine, and to have multiple running master(8) daemons each with its +own configuration files, queue directory and data directory.

+ +

These multiple running copies of master(8) share the base Postfix +software. They do not (and cannot) share their configuration +directories, queue directories or data directories.

+ +

Each combination of configuration directory, together with the queue +directory and data directory (specified in the corresponding main.cf file) +make up a Postfix instance.

+ +

The default Postfix instance

+ +

One Postfix instance is special: this is the instance whose +configuration directory is the default one compiled into the Postfix +utilities. The location of the default configuration directory is +typically /etc/postfix, and can be queried via the "postconf -d +config_directory" command. We call the instance with this configuration +directory the "default instance".

+ +

The default instance is responsible for local mail submission. The +setgid postdrop(1) utility is used by the sendmail(1) local submission +program to spool messages into the maildrop sub-directory of the +queue directory of the default instance.

+ +

Even in the rare case when "sendmail -C" is used to submit local mail +into a non-default Postfix instance, for security reasons, postdrop(1) +will consult the default main.cf file to check the validity of the +requested non-default configuration directory.

+ +

So, while in most other respects, all instances are equal, the +default instance is "more equal than others". You may choose to create +additional instances, but you must have at least the default instance, +with its configuration directory in the default compiled-in location.

+ +

Instance groups

+ +

The postmulti(1) multi-instance manager supports the notion of an +instance "group". Typically, the member instances of an instance group +constitute a logical service, and are expected to all be running or all +be stopped.

+ +

In many cases a single Postfix instance will be a complete logical +"service". You should define such instances as stand-alone instances +that are not members of any instance "group". The null-client +instance is an example of a non-group instance.

+ +

When a logical service consists of multiple Postfix instances, +often a pair of pre-filter and post-filter instances with a content +filter proxy between them, the related instances should be members +of a single instance group (however, the content filter usually has +its own start/stop procedure that is separate from any Postfix +instance).

+ +

The default instance main.cf file's $multi_instance_directories +configuration parameter lists the configuration directories of all +secondary (non-default) instances. Together with the default instance, +these secondary instances are managed by the multi-instance manager. +Instances are started in the order listed, and stopped in the +opposite order. For instances that are members of a service "group", +you should arrange to start the service back-to-front, with the +output stages started and ready to receive mail before the input +stages are started.

+ +

Multi-instance configuration parameters

+ +
+ +
multi_instance_wrapper
+ +

This default-instance configuration parameter must be set +to a suitable multi-instance manager's "wrapper" program that +controls the starting, stopping, etc. of a multi-instance Postfix +system. To use the postmulti(1) manager described in this document, +this parameter should be set with the "postmulti +-e init" command.

+ +
multi_instance_directories
+ +

This default-instance configuration parameter specifies +an optional list of the secondary instances controlled via the +multi-instance manager. Instances are listed in their "start" order, +with the default instance always started first (if enabled). If +$multi_instance_directories is left empty, the postfix(1) command +runs with multi-instance support turned off, and none of the +multi_instance_ configuration parameters will have any effect.

+ +

Do not assign a non-empty list of secondary instance configuration +directories to multi_instance_directories until you have configured a +suitable multi_instance_wrapper setting! This is best accomplished via +the "postmulti -e init" command. +

+ +
multi_instance_name
+ +

Each Postfix instance may be assigned a distinct name (with +"postfix -e create/import/assign -I name..."). This name can +be used with the postmulti(1) command-line utility to perform tasks +on the instance by name (rather than the full pathname of its +configuration directory). Choose a name that concisely captures the +role of the instance (it must start with "postfix-"). It is an +error for two instances to have the same $multi_instance_name. You +can leave an instance "nameless" by leaving this parameter at the +default empty setting.

+ +

To avoid confusion in your logs, if you don't assign each +secondary instance a non-empty (distinct) $multi_instance_name, you +should make sure that the $syslog_name setting is different for +each instance. The $syslog_name parameter defaults to $multi_instance_name +when the latter is non-empty. If at all possible, the syslog_name +should start with "postfix-", this helps log parsers to identify +log entries from secondary Postfix instances.

+ +
multi_instance_group
+ +

Each Postfix instance may be assigned an "instance group" +name (with "postfix -e create/import/assign -G name..."). +The default (empty) value of multi_instance_group parameter indicates +a stand-alone instance that is not part of any group. The group +name can be used with the postmulti(1) command-line utility to +perform a task on the members of a group by name. Choose a single-word +group name that concisely captures the role of the group.

+
+ +
multi_instance_enable
+ +

This parameter controls whether a Postfix instance will +be started by a Postfix multi-instance manager. The default value +is "no". The instance can be started explicitly with "postfix -c +/path/to/config/directory"; this is useful for testing.

+ +

When an instance is disabled, the postfix(1) "start" command +is replaced by "check".

+ +

Some postfix(1) commands (such as "stop", "flush", ...) require +a running Postfix instance, and skip instances that are disabled. +

+ +

Other postfix(1) commands (such as "status", "set-permissions", +"upgrade-configuration", ...) do not require a running Postfix +system, and apply to all instances whether enabled or not.

+
+ +
+ +

The postmulti(1) utility can be used to create (or destroy) instances. +It can also be used to "import" or "deport" existing instances into or +from the list of managed instances. When using postmulti(1) to manage +instances, the above configuration parameters are managed for you +automatically. See below.

+ +

Using the postmulti(1) command

+ + + +

Initializing the multi-instance manager

+ +

Before postmulti(1) is used for the first time, you must install +it as the multi_instance_wrapper for your Postfix system and enable +multi-instance operation of the default Postfix instance. You can then +proceed to add new or existing +instances to the multi-instance configuration. This initial installation +is accomplished as follows:

+ +
+
+    # postmulti -e init
+
+
+ +

This updates the default instance main.cf file as follows:

+ +
+
+    # Use postmulti(1) as a postfix-wrapper(5)
+    #
+    multi_instance_wrapper = ${command_directory}/postmulti -p --
+
+    # Configure the default instance to start when in multi-instance mode
+    #
+    multi_instance_enable = yes
+
+
+ +

If you prefer, you can make these changes by editing the default +main.cf directly, or by using "postconf -e".

+ +

Listing managed instances

+ +

The list of managed instances consists of the default instance and +the additional instances whose configuration directories are listed +(in start order) under the multi_instance_directories parameter of the +default main.cf configuration file.

+ +

You can list selected instances, groups of instances or all +instances by specifying only the instance matching options with the +"-l" option. The "-a" option is assumed if no other instance +selection options are specified (this behavior changes with the +"-e" option). As a special case, even if it has an explicit name, +the default instance can always be selected via "-i -".

+ +
+
+# postmulti -l -a
+# postmulti -l -g a_group
+# postmulti -l -i an_instance
+
+
+ +

The output is one line per instance (in "postfix start" order): +

+ +
+ + + + + + +
name group enabled config_directory
- - yes /etc/postfix + +
mta-out mta yes /etc/postfix/mta-out + +
mta-in mta yes /etc/postfix-mta-in + +
msa-out msa yes /etc/postfix-msa-out + +
msa-in msa yes /etc/postfix-msa-in + +
test - no /etc/postfix-test + +
+ +
+ +

The first line showing the column headings is not part of the +output. When either the instance name or the instance group is not +set, it is shown as a "-".

+ +

When selecting an existing instance via the "-i" option, you +can always use the full pathname of its configuration directory +instead of the instance (short) name. This is the only way to select +a non-default nameless instance. The default instance can be selected +via "-i -", whether it has a name or not.

+ +

To list instances in reverse start order, include the "-R" +option together with the instance selection options.

+ +

Starting or stopping a multi-instance system +

+ +

To start, stop, reload, etc. the complete (already configured as +above) multi-instance system just use postfix(1) as you would with a +single-instance system. The Postfix multi-instance wrapper framework +insulates Postfix init.d start and package upgrade scripts from the +details of multi-instance management!

+ +

The -p option of postmulti(1) turns on postfix(1) compatibility +mode. With this option the remaining arguments are exactly those supported +by postfix(1), but commands are applied to all instances or all enabled +instances as appropriate. As described above, this switch is required +when using postmulti(1) as the multi_instance_wrapper.

+ +

If you want to specify a subset of instances by name, or group name, +or run arbitrary commands (not just "postfix stop/start/etc. in the +context (MAIL_CONFIG environment variable setting) of a particular +instance or group of instances, then you can use the instance-aware +postmulti(1) utility directly.

+ +

Ad-hoc multi-instance operations

+ +

The postmulti(1) command can be used by the administrator to run arbitrary +commands in the context of one or more Postfix instances. The most common +use-case is stopping or starting a group of Postfix instances:

+ +
+
+# postmulti -g mygroup -p start
+# postmulti -g mygroup -p flush
+# postmulti -g mygroup -p reload
+# postmulti -g mygroup -p status
+# postmulti -g mygroup -p stop
+# postmulti -g mygroup -p upgrade-configuration
+
+
+ +

The -p option is essentially a short-hand for a leading +postfix command argument, but with appropriate additional options +turned on depending on the first argument. In the case of "start", +disabled instances are "checked" (postfix check) rather than simply +skipped.

+ +

The resulting command is executed for each candidate instance with +the MAIL_CONFIG environment variable set to the configuration +directory of the corresponding Postfix instance.

+ +

The postmulti(1) utility is able to launch commands other than +postfix(1), Use the -x option to ask postmulti to execute an +ad-hoc command for all instances, a group of instances, or just one +instance. With ad-hoc commands the multi_instance_enable parameter +is ignored: the command is unconditionally executed for the instances +selected via -a, -g or -i. In addition to MAIL_CONFIG, the following +instance parameters are exported into the command environment:

+ +
+
+command_directory=$command_directory
+daemon_directory=$daemon_directory
+config_directory=$config_directory
+queue_directory=$queue_directory
+data_directory=$data_directory
+multi_instance_name=$multi_instance_name
+multi_instance_group=$multi_instance_group
+multi_instance_enable=$multi_instance_enable
+
+
+ +

The config_directory setting is of course the same as MAIL_CONFIG, +and is arguably redundant, but leaving it in is less surprising. If +you want to skip disabled instances, just check multi_instance_enable +environment variable and exit if it is set to "no".

+ +

The ability to run ad-hoc commands opens up a wealth of additional +possibilities:

+ + + +

Creating a new Postfix instance

+ +

The postmulti(1) command can be used to create additional Postfix +instances. New instances are created with local submission and all "inet" +services disabled via the following non-default parameter settings in +the main.cf file:

+ +
+
+authorized_submit_users =
+master_service_disable = inet
+
+
+ +

The above settings ensure that new instances are safe to start +immediately: they will not conflict with inet listeners in existing +Postfix instances. They will also not accept any mail until they are +fully configured, at which point you can do away with one or both of +the above safety measures.

+ +

The postmulti(1) command encourages a preferred way of organizing +the configuration directories, queue directories and data directories +of non-default instances. If the default instance settings are:

+ +
+
+config_directory = /conf-path/postfix
+queue_directory = /queue-path/postfix
+data_directory = /data-path/postfix
+
+
+ +

A newly-created instance named postfix-myinst will by default +have:

+ +
+
+multi_instance_enable = no
+multi_instance_name = postfix-myinst
+config_directory = /conf-path/postfix-myinst
+queue_directory = /queue-path/postfix-myinst
+data_directory = /data-path/postfix-myinst
+
+
+ +

You can override any of these defaults when creating the instance, +but unless you want to spread instance queue directories over multiple +file-systems, use the default naming strategy. It keeps the multiple +instances organized in a uniform, predictable fashion.

+ +

When specifying the instance name later, you can refer to it +either as "postfix-myinst", or via the full path of the configuration +directory.

+ +

To create a new instance just use the -e create option:

+ +
+
+# postmulti -I postfix-myinst -e create
+
+
+ +

If the new instance is to belong to a group of related instances that +implement a single logical service, assign it to a group:

+ +
+
+# postmulti -I postfix-myinst -G mygroup -e create
+
+
+ +

If you want to override the conventional values of the instance +installation parameters, specify their values on the command-line:

+ +
+
+# postmulti [-I postfix-myinst] [-G mygroup] -e create \
+	"config_directory = /path/to/config_directory" \
+	"queue_directory = /path/to/queue_directory" \
+	"data_directory = /path/to/data_directory"
+
+
+ +

A note on the -I and -G options above. These are always +used to assign a name or group name to an instance, while the -i +and -g options always select existing instances. By default, +the configuration directories of newly managed instances are appended +to the instance list. You can use the "-i" or "-g" or "-a" options to +insert the new instance before the specified instance or group, or at +the beginning of the instance list (multi_instance_directories parameter +of the default instance).

+ +

If you do specify a name (use "-I" with a name that is not "-") +for the new instance, you may omit any of the 3 instance installation +parameters whose instance-name based value is acceptable. Otherwise, all +three instance installation parameters are required. You should set the +"syslog_name" explicitly in the main.cf file of a "nameless" instance, +in order to avoid confusion in the mail logs when multiple instances +are in use.

+ +

Destroying a Postfix instance

+ +

If you no longer need an instance, you can destroy it via:

+ +
+
+# postmulti -i postfix-myinst -p stop
+# postmulti -i postfix-myinst -e disable
+# postmulti -i postfix-myinst -e destroy
+
+
+ +

The instance must be stopped, disabled and have no queued messages. +This is expected to fully delete a just created instance that has never +been used. If the instance is not freshly created, files added after +the instance was created will remain in the configuration, queue or +data directories, in which case the corresponding directory may not +be fully removed and a warning to that effect will be displayed. You +can complete the destruction of the instance manually by removing any +unwanted remnants of the instance-specific "private" directories.

+ +

Importing an existing Postfix instance

+ +

If you already have an existing secondary Postfix instance that is +not yet managed via postmulti(1), you can "import" it into the list +of managed instances. If your instance is already using the default +configuration directory naming scheme, just specify the corresponding +instance name (the multi_instance_name parameter in its configuration +file will be adjusted to match this name if necessary):

+ +
+
+# postmulti -I postfix-myinst [-G mygroup] -e import
+
+
+ +

Otherwise, you must specify the location of its configuration +directory:

+ +
+
+# postmulti [-I postfix-myinst] [-G mygroup] -e import \
+	"config_directory = /path/of/config_directory"
+
+
+ +

When the instance is imported, you can assign a name or a group. As +with "create", you can control the placement of the +new instance in the start order by using "-i", "-g" or "-a" to prepend +before the selected instance or instances.

+ +

An imported instance is usually not multi-instance "enabled", +unless it was part of a multi-instance configuration at an earlier +time. If it is fully configured and ready to run, don't forget +to enable it and if necessary start it. When +other enabled instances are already running, new instances need to +be started individually when they are first created or imported. +

+ +

To find out what instances are running, use:

+ +
+
+# postfix status
+
+
+ +

Deporting a managed Postfix instance

+ +

You can "deport" an existing instance from the list of managed +instances. This does not destroy the instance, rather the instance +just becomes a stand-alone Postfix instance not registered with the +multi-instance manager. postmulti(1) will refuse to "deport" an +instance that is not stopped and disabled.

+ +
+
+# postmulti -i postfix-myinst -p stop
+# postmulti -i postfix-myinst -e disable
+# postmulti -i postfix-myinst -e deport
+
+
+ +

Assigning a new name or group name

+ +

You can assign a new name or new group to a managed instance. +Use "-" as the new value to assign the instance to no group or make it +nameless. To specify a nameless secondary instance use the configuration +directory path instead of the old name:

+ +
+
+# postmulti -i postfix-old [-I postfix-new] [-G newgroup] -e assign
+
+
+ +

Enabling/disabling managed instances

+ +

You can enable or disable a managed instance. As documented in +postfix-wrapper(5), disabled instances are skipped with actions +that start, +stop or control running +Postfix instances.

+ +
+
+# postmulti -i postfix-myinst -e enable
+# postmulti -i postfix-myinst -e disable
+
+
+ +

Credits

+ +

Wietse Venema created Postfix, designed and implemented the +multi-instance wrapper framework and provided design feedback that made +the postmulti(1) utility much more general and useful than originally +envisioned.

+ +

The postmulti(1) utility was developed by Victor Duchovni of Morgan +Stanley, who also wrote the initial version of this document.

+ + diff --git a/proto/MYSQL_README.html b/proto/MYSQL_README.html new file mode 100644 index 0000000..3b37a00 --- /dev/null +++ b/proto/MYSQL_README.html @@ -0,0 +1,183 @@ + + + + + + +Postfix MySQL Howto + + + + + + + +

Postfix MySQL Howto

+ +
+ +

Introduction

+ +

The Postfix mysql map type allows you to hook up Postfix to a +MySQL database. This implementation allows for multiple mysql +databases: you can use one for a virtual(5) table, one for an +access(5) table, and one for an aliases(5) table if you want. You +can specify multiple servers for the same database, so that Postfix +can switch to a good database server if one goes bad.

+ +

Busy mail servers using mysql maps will generate lots of +concurrent mysql clients, so the mysql server(s) should be run with +this fact in mind. You can reduce the number of concurrent mysql +clients by using the Postfix proxymap(8) service.

+ +

Building Postfix with MySQL support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

Note: to use mysql with Debian GNU/Linux's Postfix, all you +need is to install the postfix-mysql package and you're done. +There is no need to recompile Postfix.

+ +

The Postfix MySQL client utilizes the mysql client library, +which can be obtained from:

+ +
+

http://www.mysql.com/downloads/
+ http://sourceforge.net/projects/mysql/

+
+ +

In order to build Postfix with mysql map support, you will need to add +-DHAS_MYSQL and -I for the directory containing the mysql headers, and +the mysqlclient library (and libm) to AUXLIBS_MYSQL, for example:

+ +
+
+make -f Makefile.init makefiles \
+    'CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include' \
+    'AUXLIBS_MYSQL=-L/usr/local/mysql/lib -lmysqlclient -lz -lm'
+
+
+ +

Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_MYSQL. +With Postfix 3.0 and later, the old AUXLIBS variable still supports +building a statically-loaded MySQL database client, but only the new +AUXLIBS_MYSQL variable supports building a dynamically-loaded or +statically-loaded MySQL database client.

+ +
+ +

Failure to use the AUXLIBS_MYSQL variable will defeat the purpose +of dynamic database client loading. Every Postfix executable file +will have MYSQL database library dependencies. And that was exactly +what dynamic database client loading was meant to avoid.

+ +
+ +

On Solaris, use this instead:

+ +
+
+make -f Makefile.init makefiles \
+    'CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include' \
+    'AUXLIBS_MYSQL=-L/usr/local/mysql/lib -R/usr/local/mysql/lib \
+        -lmysqlclient -lz -lm'
+
+
+ +

Then, just run 'make'. This requires libz, the compression +library. Older mysql implementations build without libz.

+ +

Using MySQL tables

+ +

Once Postfix is built with mysql support, you can specify a +map type in main.cf like this:

+ +
+
+alias_maps = mysql:/etc/postfix/mysql-aliases.cf
+
+
+ +

The file /etc/postfix/mysql-aliases.cf specifies lots of +information telling Postfix how to reference the mysql database. +For a complete description, see the mysql_table(5) manual page.

+ +

Example: local aliases

+ +
+#
+# mysql config file for local(8) aliases(5) lookups
+#
+
+# The user name and password to log into the mysql server.
+user = someone
+password = some_password
+
+# The database name on the servers.
+dbname = customer_database
+
+# For Postfix 2.2 and later The SQL query template.
+# See mysql_table(5) for details.
+query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
+
+# For Postfix releases prior to 2.2. See mysql_table(5) for details.
+select_field = forw_addr
+table = mxaliases
+where_field = alias
+# Don't forget the leading "AND"!
+additional_conditions = AND status = 'paid'
+
+# This is necessary to make UTF8 queries work for Postfix 2.11 .. 3.1,
+# and is the default setting as of Postfix 3.2.
+option_group = client
+
+ +

Additional notes

+ +

Postfix 3.2 and later read [client] option group settings +by default. To disable this, specify no option_file and +specify "option_group =" (i.e. an empty value).

+ +

Postfix 3.1 and earlier don't read [client] option group +settings unless a non-empty option_file or option_group +value are specified. To enable this, specify, for example +"option_group = client".

+ +

The MySQL configuration interface setup allows for multiple +mysql databases: you can use one for a virtual table, one for an +access table, and one for an aliases table if you want.

+ +

Since sites that have a need for multiple mail exchangers may +enjoy the convenience of using a networked mailer database, but do +not want to introduce a single point of failure to their system, +we've included the ability to have Postfix reference multiple hosts +for access to a single mysql map. This will work if sites set up +mirrored mysql databases on two or more hosts. Whenever queries +fail with an error at one host, the rest of the hosts will be tried +in random order. If no mysql server hosts are reachable, then mail +will be deferred until at least one of those hosts is reachable. +

+ +

Credits

+ + + + + + diff --git a/proto/Makefile.in b/proto/Makefile.in new file mode 100644 index 0000000..6f435ee --- /dev/null +++ b/proto/Makefile.in @@ -0,0 +1,527 @@ +SHELL = /bin/sh + +# For now, just hard-coded rules. + +CONFIG = ../conf/access ../conf/aliases ../conf/canonical ../conf/relocated \ + ../conf/transport ../conf/virtual ../conf/header_checks \ + ../conf/generic + +HTML = ../html/ADDRESS_CLASS_README.html \ + ../html/ADDRESS_REWRITING_README.html \ + ../html/ADDRESS_VERIFICATION_README.html \ + ../html/BACKSCATTER_README.html \ + ../html/BASIC_CONFIGURATION_README.html \ + ../html/BDAT_README.html \ + ../html/BUILTIN_FILTER_README.html \ + ../html/CDB_README.html \ + ../html/COMPATIBILITY_README.html \ + ../html/CONNECTION_CACHE_README.html \ + ../html/CONTENT_INSPECTION_README.html \ + ../html/DATABASE_README.html ../html/DB_README.html \ + ../html/DEBUG_README.html \ + ../html/DSN_README.html \ + ../html/ETRN_README.html ../html/FILTER_README.html \ + ../html/FORWARD_SECRECY_README.html \ + ../html/INSTALL.html ../html/IPV6_README.html \ + ../html/LDAP_README.html \ + ../html/LINUX_README.html \ + ../html/LOCAL_RECIPIENT_README.html ../html/MAILDROP_README.html \ + ../html/MAILLOG_README.html \ + ../html/LMDB_README.html \ + ../html/MEMCACHE_README.html \ + ../html/MILTER_README.html \ + ../html/MULTI_INSTANCE_README.html \ + ../html/MYSQL_README.html ../html/NFS_README.html \ + ../html/OVERVIEW.html \ + ../html/PACKAGE_README.html ../html/PCRE_README.html \ + ../html/PGSQL_README.html \ + ../html/POSTSCREEN_README.html \ + ../html/QSHAPE_README.html \ + ../html/RESTRICTION_CLASS_README.html ../html/SASL_README.html \ + ../html/SCHEDULER_README.html ../html/SMTPD_ACCESS_README.html \ + ../html/SMTPD_POLICY_README.html \ + ../html/SMTPD_PROXY_README.html \ + ../html/SMTPUTF8_README.html \ + ../html/SOHO_README.html \ + ../html/SQLITE_README.html \ + ../html/STANDARD_CONFIGURATION_README.html \ + ../html/STRESS_README.html \ + ../html/TLS_README.html ../html/TLS_LEGACY_README.html \ + ../html/TUNING_README.html \ + ../html/UUCP_README.html \ + ../html/VERP_README.html ../html/VIRTUAL_README.html \ + ../html/XCLIENT_README.html ../html/XFORWARD_README.html \ + ../html/postconf.5.html + +README = ../README_FILES/ADDRESS_CLASS_README \ + ../README_FILES/ADDRESS_REWRITING_README \ + ../README_FILES/ADDRESS_VERIFICATION_README \ + ../README_FILES/BACKSCATTER_README \ + ../README_FILES/BASIC_CONFIGURATION_README \ + ../README_FILES/BDAT_README \ + ../README_FILES/BUILTIN_FILTER_README \ + ../README_FILES/CDB_README \ + ../README_FILES/COMPATIBILITY_README \ + ../README_FILES/CONNECTION_CACHE_README \ + ../README_FILES/CONTENT_INSPECTION_README \ + ../README_FILES/DATABASE_README ../README_FILES/DB_README \ + ../README_FILES/DEBUG_README \ + ../README_FILES/DSN_README \ + ../README_FILES/ETRN_README ../README_FILES/FILTER_README \ + ../README_FILES/FORWARD_SECRECY_README \ + ../README_FILES/INSTALL ../README_FILES/IPV6_README \ + ../README_FILES/LDAP_README \ + ../README_FILES/LINUX_README \ + ../README_FILES/LOCAL_RECIPIENT_README ../README_FILES/MAILDROP_README \ + ../README_FILES/MAILLOG_README \ + ../README_FILES/LMDB_README \ + ../README_FILES/MEMCACHE_README \ + ../README_FILES/MILTER_README \ + ../README_FILES/MULTI_INSTANCE_README \ + ../README_FILES/MYSQL_README ../README_FILES/NFS_README \ + ../README_FILES/OVERVIEW \ + ../README_FILES/PACKAGE_README ../README_FILES/PCRE_README \ + ../README_FILES/PGSQL_README \ + ../README_FILES/POSTSCREEN_README \ + ../README_FILES/QSHAPE_README \ + ../README_FILES/RESTRICTION_CLASS_README \ + ../README_FILES/SASL_README ../README_FILES/SCHEDULER_README \ + ../README_FILES/SMTPD_ACCESS_README \ + ../README_FILES/SMTPD_POLICY_README ../README_FILES/SMTPD_PROXY_README \ + ../README_FILES/SMTPUTF8_README \ + ../README_FILES/SOHO_README \ + ../README_FILES/SQLITE_README \ + ../README_FILES/STANDARD_CONFIGURATION_README \ + ../README_FILES/STRESS_README \ + ../README_FILES/TLS_README ../README_FILES/TLS_LEGACY_README \ + ../README_FILES/TUNING_README \ + ../README_FILES/UUCP_README \ + ../README_FILES/VERP_README ../README_FILES/VIRTUAL_README \ + ../README_FILES/XCLIENT_README ../README_FILES/XFORWARD_README \ + ../README_FILES/AAAREADME + +MAN = ../man/man5/postconf.5 + +TOP = ../INSTALL + +AWK = awk '{ print; if (NR == 1) print ".pl 9999\n.ll 65" }' +SRCTOMAN= ../mantools/srctoman +POSTLINK= ../mantools/postlink +DETAB = pr -tre +NROFF = LANG=C GROFF_NO_SGR=1 nroff +HT2READ = ../mantools/html2readme +MAKEAAA = ../mantools/makereadme +MAKESOHO= ../mantools/make_soho_readme +DEPSOHO = SASL_README.html STANDARD_CONFIGURATION_README.html + +update: $(CONFIG) $(HTML) $(README) $(MAN) $(TOP) + +clean: + : + +tidy: clean + +clobber: + rm -f $(CONFIG) $(README) $(HTML) + +#$(README): $(HT2READ) +#$(HTML): $(POSTLINK) + +../conf/access: access + $(SRCTOMAN) - $? | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /' >$@ + +../conf/aliases: aliases0 aliases + (cat aliases0; $(SRCTOMAN) - aliases | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /') >$@ + +../conf/canonical: canonical + $(SRCTOMAN) - $? | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /' >$@ + +../conf/generic: generic + $(SRCTOMAN) - $? | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /' >$@ + +../conf/header_checks: header_checks + $(SRCTOMAN) - $? | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /' >$@ + +../conf/relocated: relocated + $(SRCTOMAN) - $? | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /' >$@ + +../conf/transport: transport + $(SRCTOMAN) - $? | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /' >$@ + +../conf/virtual: virtual + $(SRCTOMAN) - $? | $(AWK) | $(NROFF) -man | col -bx | uniq | sed 's/^/# /' >$@ + +../html/ADDRESS_CLASS_README.html: ADDRESS_CLASS_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/ADDRESS_REWRITING_README.html: ADDRESS_REWRITING_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/ADDRESS_VERIFICATION_README.html: ADDRESS_VERIFICATION_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/BACKSCATTER_README.html: BACKSCATTER_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/CDB_README.html: CDB_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/COMPATIBILITY_README.html: COMPATIBILITY_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/CONNECTION_CACHE_README.html: CONNECTION_CACHE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/CONTENT_INSPECTION_README.html: CONTENT_INSPECTION_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/CYRUS_README.html: CYRUS_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/BASIC_CONFIGURATION_README.html: BASIC_CONFIGURATION_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/BDAT_README.html: BDAT_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/BUILTIN_FILTER_README.html: BUILTIN_FILTER_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/DATABASE_README.html: DATABASE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/DB_README.html: DB_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/DEBUG_README.html: DEBUG_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/DSN_README.html: DSN_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/ETRN_README.html: ETRN_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/FILTER_README.html: FILTER_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/FORWARD_SECRECY_README.html: FORWARD_SECRECY_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/INSTALL.html: INSTALL.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/IPV6_README.html: IPV6_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/LDAP_README.html: LDAP_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/LINUX_README.html: LINUX_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/LOCAL_RECIPIENT_README.html: LOCAL_RECIPIENT_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/MAILDROP_README.html: MAILDROP_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/MAILLOG_README.html: MAILLOG_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/LMDB_README.html: LMDB_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/MEMCACHE_README.html: MEMCACHE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/MILTER_README.html: MILTER_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/MULTI_INSTANCE_README.html: MULTI_INSTANCE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/MYSQL_README.html: MYSQL_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/NFS_README.html: NFS_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/OVERVIEW.html: OVERVIEW.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/PACKAGE_README.html: PACKAGE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/PCRE_README.html: PCRE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/PGSQL_README.html: PGSQL_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/POSTSCREEN_README.html: POSTSCREEN_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/QMQP_README.html: QMQP_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/QSHAPE_README.html: QSHAPE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/RESTRICTION_CLASS_README.html: RESTRICTION_CLASS_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/SASL_README.html: SASL_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/SCHEDULER_README.html: SCHEDULER_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/SMTPD_ACCESS_README.html: SMTPD_ACCESS_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/SMTPD_POLICY_README.html: SMTPD_POLICY_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/SMTPD_PROXY_README.html: SMTPD_PROXY_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/SMTPUTF8_README.html: SMTPUTF8_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/SOHO_README.html: $(MAKESOHO) $(DEPSOHO) + $(MAKESOHO) | $(POSTLINK) | $(DETAB) >$@ + +../html/SQLITE_README.html: SQLITE_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/STANDARD_CONFIGURATION_README.html: STANDARD_CONFIGURATION_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/STRESS_README.html: STRESS_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/TUNING_README.html: TUNING_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/UUCP_README.html: UUCP_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/ULTRIX_README.html: ULTRIX_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/VERP_README.html: VERP_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/VIRTUAL_README.html: VIRTUAL_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/XCLIENT_README.html: XCLIENT_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/XFORWARD_README.html: XFORWARD_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/TLS_README.html: TLS_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../html/TLS_LEGACY_README.html: TLS_LEGACY_README.html + $(DETAB) $? | $(POSTLINK) >$@ + +../README_FILES/ADDRESS_CLASS_README: ADDRESS_CLASS_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/ADDRESS_REWRITING_README: ADDRESS_REWRITING_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/ADDRESS_VERIFICATION_README: ADDRESS_VERIFICATION_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/BACKSCATTER_README: BACKSCATTER_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/BASIC_CONFIGURATION_README: BASIC_CONFIGURATION_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/BDAT_README: BDAT_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/BUILTIN_FILTER_README: BUILTIN_FILTER_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/CDB_README: CDB_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/COMPATIBILITY_README: COMPATIBILITY_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/CONNECTION_CACHE_README: CONNECTION_CACHE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/CONTENT_INSPECTION_README: CONTENT_INSPECTION_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/CYRUS_README: CYRUS_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/DATABASE_README: DATABASE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/DB_README: DB_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/DEBUG_README: DEBUG_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/DSN_README: DSN_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/ETRN_README: ETRN_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/FILTER_README: FILTER_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/FORWARD_SECRECY_README: FORWARD_SECRECY_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/INSTALL: INSTALL.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/IPV6_README: IPV6_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/LDAP_README: LDAP_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/LINUX_README: LINUX_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/LOCAL_RECIPIENT_README: LOCAL_RECIPIENT_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/MAILDROP_README: MAILDROP_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/MAILLOG_README: MAILLOG_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/LMDB_README: LMDB_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/MEMCACHE_README: MEMCACHE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/MILTER_README: MILTER_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/MULTI_INSTANCE_README: MULTI_INSTANCE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/MYSQL_README: MYSQL_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/NFS_README: NFS_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/OVERVIEW: OVERVIEW.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/PACKAGE_README: PACKAGE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/PCRE_README: PCRE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/PGSQL_README: PGSQL_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/POSTSCREEN_README: POSTSCREEN_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/QMQP_README: QMQP_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/QSHAPE_README: QSHAPE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/RESTRICTION_CLASS_README: RESTRICTION_CLASS_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/SASL_README: SASL_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/SCHEDULER_README: SCHEDULER_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/SMTPD_ACCESS_README: SMTPD_ACCESS_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/SMTPD_POLICY_README: SMTPD_POLICY_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/SMTPD_PROXY_README: SMTPD_PROXY_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/SMTPUTF8_README: SMTPUTF8_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/SOHO_README: $(MAKESOHO) $(DEPSOHO) + $(MAKESOHO) | $(HT2READ) | $(DETAB) >$@ + +../README_FILES/SQLITE_README: SQLITE_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/STANDARD_CONFIGURATION_README: STANDARD_CONFIGURATION_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/STRESS_README: STRESS_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/TUNING_README: TUNING_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/UUCP_README: UUCP_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/ULTRIX_README: ULTRIX_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/VERP_README: VERP_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/VIRTUAL_README: VIRTUAL_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/XCLIENT_README: XCLIENT_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/XFORWARD_README: XFORWARD_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/TLS_README: TLS_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/TLS_LEGACY_README: TLS_LEGACY_README.html + $(DETAB) $? | $(HT2READ) >$@ + +../README_FILES/AAAREADME: ../html/index.html $(MAKEAAA) + $(MAKEAAA) ../html/index.html | $(HT2READ) | $(DETAB) >$@ + +../man/man5/postconf.5: postconf.man.prolog postconf.proto postconf.man.epilog \ + ../mantools/xpostconf ../mantools/postconf2html ../mantools/postconf2man + (cat postconf.man.prolog; ../mantools/xpostconf postconf.proto | \ + $(DETAB) | ../mantools/postconf2html -n | \ + ../mantools/postconf2man | \ + sed 's/\\e&/\\\&/'; cat postconf.man.epilog ) > $@ + +../html/postconf.5.html: postconf.html.prolog postconf.proto \ + postconf.html.epilog ../mantools/xpostconf ../mantools/postconf2html \ + ../mantools/postlink + (cat postconf.html.prolog; ../mantools/xpostconf postconf.proto | \ + ../mantools/postconf2html | ../mantools/postlink; \ + cat postconf.html.epilog ) | $(DETAB) > $@ + +../INSTALL: ../README_FILES/INSTALL + rm -f $@ + col -b < $? > $@ diff --git a/proto/NFS_README.html b/proto/NFS_README.html new file mode 100644 index 0000000..e8d44d9 --- /dev/null +++ b/proto/NFS_README.html @@ -0,0 +1,137 @@ + + + + + + +Postfix and NFS + + + + + + + +

Postfix and NFS

+ +
+ +

Postfix support status for NFS

+ +

What is the status of support for Postfix on NFS? The answer +is that Postfix itself is supported when you use NFS, but there is +no promise that an NFS-related problem will promptly receive a +Postfix workaround, or that a workaround will even be possible. +

+ +

That said, Postfix will in many cases work very well on NFS, +because Postfix implements a number of workarounds (see below). +Good NFS implementations seldom if ever give problems with Postfix, +so Wietse recommends that you spend your money wisely.

+ +

Postfix file locking and NFS

+ +

For the Postfix mail queue, it does not matter how well NFS +file locking works. The reason is that you cannot share Postfix +queues among multiple running Postfix instances. You can use NFS +to switch a Postfix mail queue from one NFS client to another one, +but only one NFS client can access a Postfix mail queue at any +particular point in time.

+ +

For mailbox file sharing with NFS, your options are to use +fcntl (kernel locks), dotlock (username.lock +files), to use both locking methods simultaneously, or to switch +to maildir format. The maildir format uses one file per message and +needs no file locking support in Postfix or in other mail software. +

+ +

Many sites that use mailbox format play safe and use both locking +methods simultaneously.

+ +
+
+/etc/postfix/main.cf:
+    virtual_mailbox_lock = fcntl, dotlock
+    mailbox_delivery_lock = fcntl, dotlock
+
+
+ +

Postfix NFS workarounds

+ +

The list below summarizes the workarounds that exist for running +Postfix on NFS as of the middle of 2003. As a reminder, Postfix +itself is still supported when it runs on NFS, but there is no +promise that an NFS-related problem will promptly receive a Postfix +workaround, or that a workaround will even be possible.

+ + + +

[1] How can an operation succeed and report an error +anyway?

+ +

Suppose that an NFS server executes a client request successfully, +and that the server's reply to the client is lost. After some time +the client retransmits the request to the server. Normally, the +server remembers that it already completed the request (it keeps a +list of recently-completed requests and replies), and simply +retransmits the reply.

+ +

However, when the server has rebooted or when it has been very +busy, the server no longer remembers that it already completed the +request, and repeats the operation. This causes no problems with +file read/write requests (they contain a file offset and can therefore +be repeated safely), but fails with non-idempotent operations. For +example, when the server executes a retransmitted rename() request, +the server reports an ENOENT error because the old name does not +exist; and when the server executes a retransmitted link(), mkdir() +or create() request, the server reports an EEXIST error because the +name already exists.

+ +

Thus, successful, non-idempotent, NFS operations will report +false errors when the server reply is lost, the client retransmits +the request, and the server does not remember that it already +completed the request.

+ + + diff --git a/proto/OVERVIEW.html b/proto/OVERVIEW.html new file mode 100644 index 0000000..fc62ce1 --- /dev/null +++ b/proto/OVERVIEW.html @@ -0,0 +1,854 @@ + + + + + + +Postfix Architecture Overview + + + + + + + +

Postfix +Architecture Overview

+ +
+ +

Introduction

+ +

This document presents an overview of the Postfix architecture, +and provides pointers to descriptions of every Postfix command +or server program. The text gives the general context in which +each command or server program is used, and provides pointers to +documents with specific usage examples and background information. +

+ +

Topics covered by this document:

+ + + +

How Postfix receives mail

+ +

When a message enters the Postfix mail system, the first stop +on the inside is the incoming queue. The figure below shows the +main processes that are involved with new mail. Names followed by +a number are Postfix commands or server programs, while unnumbered +names inside shaded areas represent Postfix queues.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
trivial-
rewrite(8)
Network -> smtpd(8) +
+^
| 		|
v +
\
Network -> qmqpd(8) + -> cleanup(8) + -> incoming
/
pickup(8) + <- maildrop
^
|
Local -> sendmail(1) + -> postdrop(1) +
+ +
+ + + +

How Postfix delivers mail

+ +

Once a message has reached the incoming queue the next step is +to deliver it. The figure shows the main components of the Postfix +mail delivery apparatus. Names followed by a number are Postfix +commands or server programs, while unnumbered names inside shaded +areas represent Postfix queues.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
trivial-
rewrite(8) +		 smtp(8) -> Network
/
+^
| 		|
v +
- lmtp(8) -> Network
/
incoming -> active -> qmgr(8) --- local(8) -> File, command
+^
| 		|
v +
\
- virtual(8) -> File
deferred \
+ + pipe(8) -> Command
+ +
+ + + +

Postfix behind the scenes

+ +

The previous sections gave an overview of how Postfix server +processes send and receive mail. These server processes rely on +other server processes that do things behind the scenes. The text +below attempts to visualize each service in its own context. As +before, names followed by a number are Postfix commands or server +programs, while unnumbered names inside shaded areas represent +Postfix queues.

+ + + +

Postfix support commands

+ +

The Postfix architecture overview ends with a summary of +command-line utilities for day-to-day use of the Postfix mail +system. Besides the Sendmail-compatible sendmail(1), mailq(1), and +newaliases(1) commands, the Postfix system comes with it own +collection of command-line utilities. For consistency, these are +all named postsomething.

+ + + + + + diff --git a/proto/PACKAGE_README.html b/proto/PACKAGE_README.html new file mode 100644 index 0000000..98bffd1 --- /dev/null +++ b/proto/PACKAGE_README.html @@ -0,0 +1,154 @@ + + + + + + +Guidelines for Package Builders + + + + + + + +

Guidelines for Package Builders

+ +
+ +

Purpose of this document

+ +

This document has hints and tips for those who manage their +own Postfix binary distribution for internal use, and for those who +maintain Postfix binary distributions for general use.

+ +

General distributions: please provide a small default main.cf +file

+ +

The installed main.cf file must be small. PLEASE resist the +temptation to list all parameters in the main.cf file. Postfix +is supposed to be easy to configure. Listing all parameters in main.cf +defeats the purpose. It is an invitation for hobbyists to make +random changes without understanding what they do, and gets them +into endless trouble.

+ +

General distributions: please include README or HTML files

+ +

Please provide the applicable README or HTML files. They are +referenced by the Postfix manual pages and by other files. Without +README or HTML files, Postfix will be difficult if not impossible +to configure.

+ +

Postfix Installation parameters

+ +

Postfix installation is controlled by a dozen installation +parameters. See the postfix-install and post-install files for +details. Most parameters have system-dependent default settings +that are configurable at compile time, as described in the INSTALL +file.

+ +

Preparing a pre-built package for distribution to other +systems

+ +

You can build a Postfix package on a machine that does not have +Postfix installed on it. All you need is Postfix source code and +a compilation environment that is compatible with the target system. +

+ +

You can build a pre-built Postfix package as an unprivileged +user.

+ +

First compile Postfix. After successful compilation, execute: +

+ +
 % make package
+
+ +

With Postfix versions before 2.2 you must invoke the post-install +script directly (% sh post-install).

+ +

You will be prompted for installation parameters. Specify an +install_root directory other than /. The mail_owner and setgid_group +installation parameter settings will be recorded in the main.cf +file, but they won't take effect until the package is unpacked and +installed on the destination machine.

+ +

If you want to fully automate this process, specify all the +non-default installation parameters on the command line:

+ +
+
 % make non-interactive-package install_root=/some/where...  
+
+ +

With Postfix versions before 2.2 you must invoke the post-install +script directly (% sh post-install -non-interactive +install_root...).

+ +

With Postfix 3.0 and later, the command "make package name=value +..." will replace the string MAIL_VERSION in a configuration parameter +value with the Postfix release version. Do not try to specify +something like $mail_version on this command line. This produces +inconsistent results with different versions of the make(1) command. +

+ +

Begin Security Alert

+ +

When building an archive for distribution, be sure to +archive only files and symbolic links, not their parent directories. +Otherwise, unpacking a pre-built Postfix package may mess up +permission and/or ownership of system directories such as / /etc +/usr /usr/bin /var /var/spool and so on. This is especially an +issue if you executed postfix-install (see above) as an unprivileged +user.

+ +

End Security Alert

+ +

Thus, to tar up the pre-built package, take the following steps: +

+ +
+% cd INSTALL_ROOT
+% rm -f SOMEWHERE/outputfile
+% find . \! -type d -print | xargs tar rf SOMEWHERE/outputfile
+% gzip SOMEWHERE/outputfile
+ +

This way you will not include any directories that might cause +trouble upon extraction.

+ +

Installing a pre-built Postfix package

+ + + + + + diff --git a/proto/PCRE_README.html b/proto/PCRE_README.html new file mode 100644 index 0000000..1f8059b --- /dev/null +++ b/proto/PCRE_README.html @@ -0,0 +1,106 @@ + + + + + + +Postfix PCRE Support + + + + + + + +

Postfix PCRE Support

+ +
+ +

PCRE (Perl Compatible Regular Expressions) map support

+ +

The optional "pcre" map type allows you to specify regular +expressions with the PERL style notation such as \s for space and +\S for non-space. The main benefit, however, is that pcre lookups +are often faster than regexp lookups. This is because the pcre +implementation is often more efficient than the POSIX regular +expression implementation that you find on many systems.

+ +

A description of how to use pcre tables, including examples, +is given in the pcre_table(5) manual page. Information about PCRE +itself can be found at http://www.pcre.org/.

+ +

Building Postfix with PCRE support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

Note: to use pcre with Debian GNU/Linux's Postfix, all you +need is to install the postfix-pcre package and you're done. There +is no need to recompile Postfix.

+ +

In some future, Postfix will have a plug-in interface for adding +map types. Until then, you need to compile PCRE support into Postfix. +

+ +

First of all, you need the PCRE library (Perl Compatible Regular +Expressions), which can be obtained from:

+ +
+ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/. +
+ +

NOTE: pcre versions prior to 2.06 cannot be used.

+ +

In order to build Postfix with PCRE support you need to add +-DHAS_PCRE and a -I option for the PCRE include file to CCARGS, and +add the path to the PCRE library to AUXLIBS_PCRE, for example:

+ +
+
+make -f Makefile.init makefiles \
+    "CCARGS=-DHAS_PCRE `pcre-config --cflags`" \
+    "AUXLIBS_PCRE=`pcre-config --libs`"
+
+
+ +

Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_PCRE. +With Postfix 3.0 and later, the old AUXLIBS variable still supports +building a statically-loaded PCRE database client, but only the new +AUXLIBS_PCRE variable supports building a dynamically-loaded or +statically-loaded PCRE database client.

+ +
+ +

Failure to use the AUXLIBS_PCRE variable will defeat the purpose +of dynamic database client loading. Every Postfix executable file +will have PCRE library dependencies. And that was exactly +what dynamic database client loading was meant to avoid.

+ +
+ +

Things to know

+ + + + + + diff --git a/proto/PGSQL_README.html b/proto/PGSQL_README.html new file mode 100644 index 0000000..ddbaa38 --- /dev/null +++ b/proto/PGSQL_README.html @@ -0,0 +1,170 @@ + + + + + + +Postfix PostgreSQL Howto + + + + + + + +

Postfix PostgreSQL Howto

+ +
+ +

Introduction

+ +

The Postfix pgsql map type allows you to hook up Postfix to a +PostgreSQL database. This implementation allows for multiple pgsql +databases: you can use one for a virtual(5) table, one for an +access(5) table, and one for an aliases(5) table if you want. You +can specify multiple servers for the same database, so that Postfix +can switch to a good database server if one goes bad.

+ +

Busy mail servers using pgsql maps will generate lots of +concurrent pgsql clients, so the pgsql server(s) should be run with +this fact in mind. You can reduce the number of concurrent pgsql +clients by using the Postfix proxymap(8) service.

+ +

Building Postfix with PostgreSQL support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

Note: to use pgsql with Debian GNU/Linux's Postfix, all you +need to do is to install the postfix-pgsql package and you're done. +There is no need to recompile Postfix.

+ +

In order to build Postfix with pgsql map support, you specify +-DHAS_PGSQL, the directory with the PostgreSQL header files, and +the location of the libpq library file.

+ +

For example:

+ +
+
+% make tidy
+% make -f Makefile.init makefiles \
+        'CCARGS=-DHAS_PGSQL -I/usr/local/include/pgsql' \
+        'AUXLIBS_PGSQL=-L/usr/local/lib -lpq'
+
+
+ +

Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_PGSQL. +With Postfix 3.0 and later, the old AUXLIBS variable still supports +building a statically-loaded PostgreSQL database client, but only +the new AUXLIBS_PGSQL variable supports building a dynamically-loaded +or statically-loaded PostgreSQL database client.

+ +
+ +

Failure to use the AUXLIBS_PGSQL variable will defeat the purpose +of dynamic database client loading. Every Postfix executable file +will have PGSQL database library dependencies. And that was exactly +what dynamic database client loading was meant to avoid.

+ +
+ +

Then just run 'make'.

+ +

Configuring PostgreSQL lookup tables

+ +

Once Postfix is built with pgsql support, you can specify a +map type in main.cf like this:

+ +
+
+/etc/postfix/main.cf:
+    alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf
+
+
+ +

The file /etc/postfix/pgsql-aliases.cf specifies lots of +information telling postfix how to reference the pgsql database. +For a complete description, see the pgsql_table(5) manual page.

+ +

Example: local aliases

+ +
+#
+# pgsql config file for local(8) aliases(5) lookups
+#
+
+#
+# The hosts that Postfix will try to connect to
+hosts = host1.some.domain host2.some.domain
+
+# The user name and password to log into the pgsql server.
+user = someone
+password = some_password
+
+# The database name on the servers.
+dbname = customer_database
+
+# Postfix 2.2 and later The SQL query template. See pgsql_table(5).
+query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
+
+# For Postfix releases prior to 2.2. See pgsql_table(5) for details.
+select_field = forw_addr
+table = mxaliases
+where_field = alias
+# Don't forget the leading "AND"!
+additional_conditions = AND status = 'paid'
+
+ +

Using mirrored databases

+ +

Sites that have a need for multiple mail exchangers may enjoy +the convenience of using a networked mailer database, but do not +want to introduce a single point of failure to their system.

+ +

For this reason we've included the ability to have Postfix +reference multiple hosts for access to a single pgsql map. This +will work if sites set up mirrored pgsql databases on two or more +hosts.

+ +

Whenever queries fail with an error at one host, the rest of +the hosts will be tried in random order. If no pgsql server hosts +are reachable, then mail will be deferred until at least one of +those hosts is reachable.

+ +

Credits

+ + + + + + diff --git a/proto/POSTSCREEN_README.html b/proto/POSTSCREEN_README.html new file mode 100644 index 0000000..66f8f87 --- /dev/null +++ b/proto/POSTSCREEN_README.html @@ -0,0 +1,1192 @@ + + + + +Postfix Postscreen Howto + + + + + + + +

Postfix Postscreen Howto

+ +
+ +

Introduction

+ +

This document describes features that are available in Postfix +2.8 and later.

+ +

The Postfix postscreen(8) daemon provides additional protection +against mail server overload. One postscreen(8) process handles +multiple inbound SMTP connections, and decides which clients may +talk to a Postfix SMTP server process. By keeping spambots away, +postscreen(8) leaves more SMTP server processes available for +legitimate clients, and delays the onset of server overload conditions.

+ +

postscreen(8) should not be used on SMTP ports that receive +mail from end-user clients (MUAs). In a typical deployment, +postscreen(8) handles the MX service on TCP port 25, while MUA +clients submit mail via the submission service on TCP port 587 which +requires client authentication. Alternatively, a site could set up +a dedicated, non-postscreen, "port 25" server that provides submission +service and client authentication, but no MX service.

+ +

postscreen(8) maintains a temporary whitelist for clients that +pass its tests; by allowing whitelisted clients to skip tests, +postscreen(8) minimizes its impact on legitimate email traffic. +

+ +

postscreen(8) is part of a multi-layer defense.

+ +

+ +

Each layer reduces the spam volume. The general strategy is to +use the less expensive defenses first, and to use the more expensive +defenses only for the spam that remains.

+ +

Topics in this document:

+ + + +

The basic idea behind postscreen(8)

+ +

Most email is spam, and most spam is sent out by zombies (malware +on compromised end-user computers). Wietse expects that the zombie +problem will get worse before things improve, if ever. Without a +tool like postscreen(8) that keeps the zombies away, Postfix would be +spending most of its resources not receiving email.

+ +

The main challenge for postscreen(8) is to make an is-a-zombie +decision based on a single measurement. This is necessary because +many zombies try to fly under the radar and avoid spamming the same +site repeatedly. Once postscreen(8) decides that a client is +not-a-zombie, it whitelists the client temporarily to avoid further +delays for legitimate mail.

+ +

Zombies have challenges too: they have only a limited amount +of time to deliver spam before their IP address becomes blacklisted. +To speed up spam deliveries, zombies make compromises in their SMTP +protocol implementation. For example, they speak before their turn, +or they ignore responses from SMTP servers and continue sending +mail even when the server tells them to go away.

+ +

postscreen(8) uses a variety of measurements to recognize +zombies. First, postscreen(8) determines if the remote SMTP client +IP address is blacklisted. Second, postscreen(8) looks for protocol +compromises that are made to speed up delivery. These are good +indicators for making is-a-zombie decisions based on single +measurements.

+ +

postscreen(8) does not inspect message content. Message content +can vary from one delivery to the next, especially with clients +that (also) send legitimate email. Content is not a good indicator +for making is-a-zombie decisions based on single measurements, +and that is the problem that postscreen(8) is focused on.

+ +

General operation

+ +

For each connection from an SMTP client, postscreen(8) performs +a number of tests +in the order as described below. Some tests introduce a delay of +a few seconds. postscreen(8) maintains a temporary whitelist for +clients that pass its tests; by allowing whitelisted clients to +skip tests, postscreen(8) minimizes its impact on legitimate email +traffic.

+ +

By default, postscreen(8) hands off all connections to a Postfix +SMTP server process after logging its findings. This mode is useful +for non-destructive testing.

+ +

In a typical production setting, postscreen(8) is configured +to reject mail from clients that fail one or more tests, after +logging the helo, sender and recipient information.

+ +

Note: postscreen(8) is not an SMTP proxy; this is intentional. +The purpose is to keep zombies away from Postfix, with minimal +overhead for legitimate clients.

+ +

Quick tests before everything else

+ +

Before engaging in SMTP-level tests. postscreen(8) queries a +number of local black and whitelists. These tests speed up the +handling of known clients.

+ + + +

Permanent white/blacklist test

+ +

The postscreen_access_list parameter (default: permit_mynetworks) +specifies a permanent access list for SMTP client IP addresses. Typically +one would specify something that whitelists local networks, followed +by a CIDR table for selective white- and blacklisting.

+ +

Example:

+ +
+/etc/postfix/main.cf:
+    postscreen_access_list = permit_mynetworks,
+        cidr:/etc/postfix/postscreen_access.cidr
+
+/etc/postfix/postscreen_access.cidr:
+   # Rules are evaluated in the order as specified.
+   # Blacklist 192.168.* except 192.168.0.1.
+   192.168.0.1          permit
+   192.168.0.0/16       reject
+
+ +

See the postscreen_access_list manpage documentation for more +details.

+ +

When the SMTP client address matches a "permit" action, +postscreen(8) logs this with the client address and port number as: +

+ +
+    WHITELISTED [address]:port
+
+ +

The whitelist action is not configurable: immediately hand off the +connection to a Postfix SMTP server process.

+ +

When the SMTP client address matches a "reject" action, +postscreen(8) logs this with the client address and port number as: +

+ +
+    BLACKLISTED [address]:port
+
+ +

The postscreen_blacklist_action parameter specifies the action +that is taken next. See "When tests +fail before the 220 SMTP server greeting" below.

+ +

Temporary whitelist test

+ +

The postscreen(8) daemon maintains a temporary +whitelist for SMTP client IP addresses that have passed all +the tests described below. The postscreen_cache_map parameter +specifies the location of the temporary whitelist. The +temporary whitelist is not used for SMTP client addresses +that appear on the permanent access list.

+ +

By default the temporary whitelist is not shared with other +postscreen(8) daemons. See Sharing +the temporary whitelist below for alternatives.

+ +

When the SMTP client address appears on the temporary +whitelist, postscreen(8) logs this with the client address and port +number as:

+ +
+    PASS OLD [address]:port
+
+ +

The action is not configurable: immediately hand off the +connection to a Postfix SMTP server process. The client is +excluded from further tests until its temporary whitelist +entry expires, as controlled with the postscreen_*_ttl +parameters. Expired entries are silently renewed if possible.

+ +

MX Policy test

+ +

When the remote SMTP client is not on the static access list +or temporary whitelist, postscreen(8) can implement a number of +whitelist tests, before it grants the client a temporary whitelist +status that allows it to talk to a Postfix SMTP server process.

+ +

When postscreen(8) is configured to monitor all primary and +backup MX addresses, it can refuse to whitelist clients that connect +to a backup MX address only (an old spammer trick to take advantage +of backup MX hosts with weaker anti-spam policies than primary MX +hosts).

+ +

NOTE: The following solution is for small sites. +Larger sites would have to share the postscreen(8) cache between +primary and backup MTAs, which would introduce a common point of +failure.

+ + + +

When a non-whitelisted client connects the backup MX address, +postscreen(8) logs this with the client address and port number as: +

+ +
+    CONNECT from [address]:port to [168.100.189.8]:25
+    WHITELIST VETO [address]:port
+
+ +

Translation: the client at [address]:port connected to +the backup MX address 168.100.189.8 while it was not whitelisted. +The client will not be granted the temporary whitelist status, even +if passes all the whitelist tests described below.

+ +

Tests before the 220 SMTP server greeting

+ +

The postscreen_greet_wait parameter specifies a short time +interval before the "220 text..." server greeting, where +postscreen(8) can run a number of tests in parallel.

+ +

When a good client passes these tests, and no "deep protocol tests" are configured, postscreen(8) +adds the client to the temporary whitelist and hands off the "live" +connection to a Postfix SMTP server process. The client can then +continue as if postscreen(8) never even existed (except of course +for the short postscreen_greet_wait delay).

+ + + +

Pregreet test

+ +

The SMTP protocol is a classic example of a protocol where the +server speaks before the client. postscreen(8) detects zombies +that are in a hurry and that speak before their turn. This test is +enabled by default.

+ +

The postscreen_greet_banner parameter specifies the text +portion of a "220-text..." teaser banner (default: $smtpd_banner). +Note that this becomes the first part of a multi-line server greeting. +The postscreen(8) daemon sends this before the postscreen_greet_wait +timer is started. The purpose of the teaser banner is to confuse +zombies so that they speak before their turn. It has no effect on +SMTP clients that correctly implement the protocol.

+ +

To avoid problems with poorly-implemented SMTP engines in network +appliances or network testing tools, either exclude them from all +tests with the postscreen_access_list feature or else specify +an empty teaser banner:

+ +
+/etc/postfix/main.cf:
+    # Exclude broken clients by whitelisting. Clients in mynetworks
+    # should always be whitelisted.
+    postscreen_access_list = permit_mynetworks, 
+        cidr:/etc/postfix/postscreen_access.cidr
+
+/etc/postfix/postscreen_access.cidr:
+    192.168.254.0/24 permit
+
+ +
+/etc/postfix/main.cf:
+    # Disable the teaser banner (try whitelisting first if you can).
+    postscreen_greet_banner =
+
+ +

When an SMTP client sends a command before the +postscreen_greet_wait time has elapsed, postscreen(8) logs this as: +

+ +
+    PREGREET count after time from [address]:port text...
+
+ +

Translation: the client at [address]:port sent count +bytes before its turn to speak. This happened time seconds +after the postscreen_greet_wait timer was started. The text +is what the client sent (truncated to 100 bytes, and with non-printable +characters replaced with C-style escapes such as \r for carriage-return +and \n for newline).

+ +

The postscreen_greet_action parameter specifies the action that +is taken next. See "When tests fail +before the 220 SMTP server greeting" below.

+ +

DNS White/blacklist test

+ +

The postscreen_dnsbl_sites parameter (default: empty) specifies +a list of DNS blocklist servers with optional filters and weight +factors (positive weights for blacklisting, negative for whitelisting). +These servers will be queried in parallel with the reverse client +IP address. This test is disabled by default.

+ +
+

+CAUTION: when postscreen rejects mail, its SMTP reply contains the +DNSBL domain name. Use the postscreen_dnsbl_reply_map feature to +hide "password" information in DNSBL domain names. +

+
+ +

When the postscreen_greet_wait time has elapsed, and the combined +DNSBL score is equal to or greater than the postscreen_dnsbl_threshold +parameter value, postscreen(8) logs this as:

+ +
+    DNSBL rank count for [address]:port
+
+ +

Translation: the SMTP client at [address]:port has a combined +DNSBL score of count.

+ +

The postscreen_dnsbl_action parameter specifies the action that +is taken when the combined DNSBL score is equal to or greater than +the threshold. See "When tests fail +before the 220 SMTP server greeting" below.

+ +

When tests fail before the 220 SMTP server greeting

+ +

When the client address matches the permanent blacklist, or +when the client fails the pregreet or DNSBL tests, the action is +specified with postscreen_blacklist_action, postscreen_greet_action, +or postscreen_dnsbl_action, respectively.

+ +
+ +
ignore (default)
+ +
Ignore the failure of this test. Allow other tests to complete. +Repeat this test the next time the client connects. This option +is useful for testing and collecting statistics without blocking +mail.
+ +
enforce
+ +
Allow other tests to complete. Reject attempts to deliver mail +with a 550 SMTP reply, and log the helo/sender/recipient information. +Repeat this test the next time the client connects.
+ +
drop
+ +
Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects.
+ +
+ +

Tests after the 220 SMTP server greeting

+ +

In this phase of the protocol, postscreen(8) implements a +number of "deep protocol" tests. These tests use an SMTP protocol +engine that is built into the postscreen(8) server.

+ +

Important note: these protocol tests are disabled by default. +They are more intrusive than the pregreet and DNSBL tests, and they +have limitations as discussed next.

+ + + +

The following "after 220 greeting" tests are available:

+ + + +

Command pipelining test

+ +

By default, SMTP is a half-duplex protocol: the sender and +receiver send one command and one response at a time. Unlike the +Postfix SMTP server, postscreen(8) does not announce support +for ESMTP command pipelining. Therefore, clients are not allowed +to send multiple commands. postscreen(8)'s deep +protocol test for this is disabled by default.

+ +

With "postscreen_pipelining_enable = yes", postscreen(8) detects +zombies that send multiple commands, instead of sending one command +and waiting for the server to reply.

+ +

This test is opportunistically enabled when postscreen(8) has +to use the built-in SMTP engine anyway. This is to make postscreen(8) +logging more informative.

+ +

When a client sends multiple commands, postscreen(8) logs this +as:

+ +
+    COMMAND PIPELINING from [address]:port after command: text
+
+ +

Translation: the SMTP client at [address]:port sent +multiple SMTP commands, instead of sending one command and then +waiting for the server to reply. This happened after the client +sent command. The text shows part of the input that +was sent too early; it is not logged with Postfix 2.8.

+ +

The postscreen_pipelining_action parameter specifies the action +that is taken next. See "When tests fail +after the 220 SMTP server greeting" below.

+ +

Non-SMTP command test

+ +

Some spambots send their mail through open proxies. A symptom +of this is the usage of commands such as CONNECT and other non-SMTP +commands. Just like the Postfix SMTP server's smtpd_forbidden_commands +feature, postscreen(8) has an equivalent postscreen_forbidden_commands +feature to block these clients. postscreen(8)'s deep +protocol test for this is disabled by default.

+ +

With "postscreen_non_smtp_command_enable = yes", postscreen(8) +detects zombies that send commands specified with the +postscreen_forbidden_commands parameter. This also detects commands +with the syntax of a message header label. The latter is a symptom +that the client is sending message content after ignoring all the +responses from postscreen(8) that reject mail.

+ +

This test is opportunistically enabled when postscreen(8) has +to use the built-in SMTP engine anyway. This is to make postscreen(8) +logging more informative.

+ +

When a client sends non-SMTP commands, postscreen(8) logs this +as:

+ +
+    NON-SMTP COMMAND from [address]:port after command: text
+
+ +

Translation: the SMTP client at [address]:port sent a +command that matches the postscreen_forbidden_commands +parameter, or that has the syntax of a message header label (text +followed by optional space and ":"). +The "after command" portion is logged with +Postfix 2.10 and later.

+ +

The postscreen_non_smtp_command_action parameter specifies +the action that is taken next. See "When +tests fail after the 220 SMTP server greeting" below.

+ +

Bare newline test

+ +

SMTP is a line-oriented protocol: lines have a limited length, +and are terminated with <CR><LF>. Lines ending in a +"bare" <LF>, that is newline not preceded by carriage return, +are not allowed in SMTP. postscreen(8)'s deep +protocol test for this is disabled by default.

+ +

With "postscreen_bare_newline_enable = yes", postscreen(8) +detects clients that send lines ending in bare newline characters. +

+ +

This test is opportunistically enabled when postscreen(8) has +to use the built-in SMTP engine anyway. This is to make postscreen(8) +logging more informative.

+ +

When a client sends bare newline characters, postscreen(8) logs +this as: +

+ +
+    BARE NEWLINE from [address]:port after command
+
+ +

Translation: the SMTP client at [address]:port sent a bare +newline character, that is newline not preceded by carriage +return. +The "after command" portion is logged with +Postfix 2.10 and later.

+ +

The postscreen_bare_newline_action parameter specifies the +action that is taken next. See "When +tests fail after the 220 SMTP server greeting" below.

+ +

When tests fail after the 220 SMTP server greeting

+ +

When the client fails the pipelining, non-SMTP command or bare +newline tests, the action is specified with postscreen_pipelining_action, +postscreen_non_smtp_command_action or postscreen_bare_newline_action, +respectively.

+ +
+ +
ignore (default for bare newline)
+ +
Ignore the failure of this test. Allow other tests to complete. +Do NOT repeat this test before the result from some other test +expires. + +This option is useful for testing and collecting statistics without +blocking mail permanently.
+ +
enforce (default for pipelining)
+ +
Allow other tests to complete. Reject attempts to deliver +mail with a 550 SMTP reply, and log the helo/sender/recipient +information. Repeat this test the next time the client connects. +
+ +
drop (default for non-SMTP commands)
+ +
Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects. This action is +compatible with the Postfix SMTP server's smtpd_forbidden_commands +feature.
+ +
+ +

Other errors

+ +

When an SMTP client hangs up unexpectedly, postscreen(8) logs +this as:

+ +
+    HANGUP after time from [address]:port in test name
+
+ +

Translation: the SMTP client at [address]:port disconnected +unexpectedly, time seconds after the start of the +test named test name.

+ +

There is no punishment for hanging up. A client that hangs up +without sending the QUIT command can still pass all postscreen(8) +tests.

+ + + +

The following errors are reported by the built-in SMTP engine. +This engine never accepts mail, therefore it has per-session limits +on the number of commands and on the session length.

+ +
+    COMMAND TIME LIMIT from [address]:port after command
+
+ +

Translation: the SMTP client at [address]:port reached the +per-command time limit as specified with the postscreen_command_time_limit +parameter. The session is terminated immediately. +The "after command" portion is logged with +Postfix 2.10 and later.

+ +
+    COMMAND COUNT LIMIT from [address]:port after command
+
+ +

Translation: the SMTP client at [address]:port reached the +per-session command count limit as specified with the +postscreen_command_count_limit parameter. The session is terminated +immediately. +The "after command" portion is logged with +Postfix 2.10 and later.

+ +
+    COMMAND LENGTH LIMIT from [address]:port after command
+
+ +

Translation: the SMTP client at [address]:port reached the +per-command length limit, as specified with the line_length_limit +parameter. The session is terminated immediately. +The "after command" portion is logged with +Postfix 2.10 and later.

+ +

When an SMTP client makes too many connections at the same time, +postscreen(8) rejects the connection with a 421 status code and logs:

+ +
+    NOQUEUE: reject: CONNECT from [address]:port: too many connections
+
+ +

The postscreen_client_connection_count_limit parameter controls this limit.

+ +

When an SMTP client connects after postscreen(8) has reached a +connection count limit, postscreen(8) rejects the connection with +a 421 status code and logs:

+ +
+    NOQUEUE: reject: CONNECT from [address]:port: all screening ports busy
+    NOQUEUE: reject: CONNECT from [address]:port: all server ports busy
+
+ +

The postscreen_pre_queue_limit and postscreen_post_queue_limit +parameters control these limits.

+ +

When all tests succeed

+ +

When a new SMTP client passes all tests (i.e. it is not whitelisted +via some mechanism), postscreen(8) logs this as:

+ +
+    PASS NEW [address]:port
+
+ +

Where [address]:port are the client IP address and port. +Then, postscreen(8) +creates a temporary whitelist entry that excludes the client IP +address from further tests until the temporary whitelist entry +expires, as controlled with the postscreen_*_ttl parameters.

+ +

When no "deep protocol tests" are +configured, postscreen(8) hands off the "live" connection to a Postfix +SMTP server process. The client can then continue as if postscreen(8) +never even existed (except for the short postscreen_greet_wait delay). +

+ +

When any "deep protocol tests" are +configured, postscreen(8) cannot hand off the "live" connection to +a Postfix SMTP server process in the middle of the session. Instead, +postscreen(8) defers mail delivery attempts with a 4XX status, logs +the helo/sender/recipient information, and waits for the client to +disconnect. The next time the client connects it will be allowed +to talk to a Postfix SMTP server process to deliver its mail. +postscreen(8) mitigates the impact of this limitation by giving +deep protocol tests a long expiration +time.

+ +

Configuring the postscreen(8) service +

+ +

postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6] +and Solaris 9 systems.

+ + + +

Turning on postscreen(8) without blocking mail

+ +

To enable the postscreen(8) service and log client information +without blocking mail:

+ +
    + +

  1. Make sure that local clients and systems with non-standard +SMTP implementations are excluded from any postscreen(8) tests. The +default is to exclude all clients in mynetworks. To exclude additional +clients, for example, third-party performance monitoring tools (these +tend to have broken SMTP implementations):

    + +
    +/etc/postfix/main.cf:
+    # Exclude broken clients by whitelisting. Clients in mynetworks
+    # should always be whitelisted.
+    postscreen_access_list = permit_mynetworks, 
+        cidr:/etc/postfix/postscreen_access.cidr
+
+/etc/postfix/postscreen_access.cidr:
+    192.168.254.0/24 permit
+
    + +

  2. Comment out the "smtp inet ... smtpd" service +in master.cf, including any "-o parameter=value" entries +that follow.

    + +
    +/etc/postfix/master.cf:
+    #smtp      inet  n       -       n       -       -       smtpd
+    #    -o parameter=value ...
+
    + +

  3. Uncomment the new "smtpd pass ... smtpd" service +in master.cf, and duplicate any "-o parameter=value" entries +from the smtpd service that was commented out in the previous step. +

    + +
    +/etc/postfix/master.cf:
+    smtpd     pass  -       -       n       -       -       smtpd
+        -o parameter=value ...
+
    + +

  4. Uncomment the new "smtp inet ... postscreen" +service in master.cf.

    + +
    +/etc/postfix/master.cf:
+    smtp      inet  n       -       n       -       1       postscreen
+
    + +

  5. Uncomment the new "tlsproxy unix ... tlsproxy" +service in master.cf. This service implements STARTTLS support for +postscreen(8).

    + +
    +/etc/postfix/master.cf:
+    tlsproxy  unix  -       -       n       -       0       tlsproxy
+
    + +

  6. Uncomment the new "dnsblog unix ... dnsblog" +service in master.cf. This service does DNSBL lookups for postscreen(8) +and logs results.

    + +
    +/etc/postfix/master.cf:
+    dnsblog   unix  -       -       n       -       0       dnsblog
+
    + +

  7. To enable DNSBL lookups, list some DNS blocklist sites in +main.cf, separated by whitespace. Different sites can have different +weights. For example: + +

    +/etc/postfix/main.cf:
+    postscreen_dnsbl_threshold = 2
+    postscreen_dnsbl_sites = zen.spamhaus.org*2 
+        bl.spamcop.net*1 b.barracudacentral.org*1
+
    + +

    Note: if your DNSBL queries have a "secret" in the domain name, +you must censor this information from the postscreen(8) SMTP replies. +For example:

    + +
    +/etc/postfix/main.cf:
+    postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
+
    + +
    +/etc/postfix/dnsbl_reply:
+    # Secret DNSBL name           Name in postscreen(8) replies
+    secret.zen.dq.spamhaus.net    zen.spamhaus.org
+
    + +

    The texthash: format is similar to hash: except that there is +no need to run postmap(1) before the file can be used, and that it +does not detect changes after the file is read. It is new with +Postfix version 2.8.

    + +

  8. Read the new configuration with "postfix reload". +

    + +
+ +

Notes:

+ + + +

postscreen(8) TLS configuration

+ +

postscreen(8) TLS support is available for remote SMTP clients +that aren't whitelisted, including clients that need to renew their +temporary whitelist status. When a remote SMTP client requests TLS +service, postscreen(8) invisibly hands off the connection to a +tlsproxy(8) process. Then, tlsproxy(8) encrypts and decrypts the +traffic between postscreen(8) and the remote SMTP client. One +tlsproxy(8) process can handle multiple SMTP sessions. The number +of tlsproxy(8) processes slowly increases with server load, but it +should always be much smaller than the number of postscreen(8) TLS +sessions.

+ +

TLS support for postscreen(8) and tlsproxy(8) uses the same +parameters as with smtpd(8). We recommend that you keep the relevant +configuration parameters in main.cf. If you must specify "-o +smtpd_mumble=value" parameter overrides in master.cf for a +postscreen-protected smtpd(8) service, then you should specify those +same parameter overrides for the postscreen(8) and tlsproxy(8) +services.

+ +

Blocking mail with postscreen(8)

+ +

For compatibility with smtpd(8), postscreen(8) implements the +soft_bounce safety feature. This causes Postfix to reject mail with +a "try again" reply code.

+ + + +

Execute "postfix reload" to make the change effective.

+ +

After testing, do not forget to remove the soft_bounce feature, +otherwise senders won't receive their non-delivery notification +until many days later.

+ +

To use the postscreen(8) service to block mail, edit main.cf and +specify one or more of:

+ + + +

Turning off postscreen(8)

+ +

To turn off postscreen(8) and handle mail directly with Postfix +SMTP server processes:

+ +
    + +

  1. Comment out the "smtp inet ... postscreen" service +in master.cf, including any "-o parameter=value" entries +that follow.

    + +
    +/etc/postfix/master.cf:
+    #smtp      inet  n       -       n       -       1       postscreen
+    #    -o parameter=value ...
+
    + +

  2. Comment out the "dnsblog unix ... dnsblog" service +in master.cf.

    + +
    +/etc/postfix/master.cf:
+    #dnsblog   unix  -       -       n       -       0       dnsblog
+
    + +

  3. Comment out the "smtpd pass ... smtpd" service +in master.cf, including any "-o parameter=value" entries +that follow.

    + +
    +/etc/postfix/master.cf:
+    #smtpd     pass  -       -       n       -       -       smtpd
+    #    -o parameter=value ...
+
    + +

  4. Comment out the "tlsproxy unix ... tlsproxy" +service in master.cf, including any "-o parameter=value" +entries that follow.

    + +
    +/etc/postfix/master.cf:
+    #tlsproxy  unix  -       -       n       -       0       tlsproxy
+    #    -o parameter=value ...
+
    + +

  5. Uncomment the "smtp inet ... smtpd" service in +master.cf, including any "-o parameter=value" entries that +may follow.

    + +
    +/etc/postfix/master.cf:
+    smtp       inet  n       -       n       -       -       smtpd
+        -o parameter=value ...
+
    + +

  6. Read the new configuration with "postfix reload". +

    + +
+ +

Sharing the temporary whitelist

+ +

By default, the temporary whitelist is not shared between +multiple postscreen(8) daemons. To enable sharing, choose one +of the following options:

+ + + +

Historical notes and credits

+ +

Many ideas in postscreen(8) were explored in earlier work by +Michael Tokarev, in OpenBSD spamd, and in MailChannels Traffic +Control.

+ +

Wietse threw together a crude prototype with pregreet and dnsbl +support in June 2009, because he needed something new for a Mailserver +conference presentation in July. Ralf Hildebrandt ran this code on +several servers to collect real-world statistics. This version used +the dnsblog(8) ad-hoc DNS client program.

+ +

Wietse needed new material for a LISA conference presentation +in November 2010, so he added support for DNSBL weights and filters +in August, followed by a major code rewrite, deep protocol tests, +helo/sender/recipient logging, and stress-adaptive behavior in +September. Ralf Hildebrandt ran this code on several servers to +collect real-world statistics. This version still used the embarrassing +dnsblog(8) ad-hoc DNS client program.

+ +

Wietse added STARTTLS support in December 2010. This makes +postscreen(8) usable for sites that require TLS support. The +implementation introduces the tlsproxy(8) event-driven TLS proxy +that decrypts/encrypts the sessions for multiple SMTP clients.

+ +

The tlsproxy(8) implementation led to the discovery of a "new" +class of vulnerability (CVE-2011-0411) that affected multiple implementations of SMTP, +POP, IMAP, NNTP, and FTP over TLS.

+ +

postscreen(8) was officially released as part of the Postfix +2.8 stable release in January 2011.

+ + + + + diff --git a/proto/QSHAPE_README.html b/proto/QSHAPE_README.html new file mode 100644 index 0000000..14209fe --- /dev/null +++ b/proto/QSHAPE_README.html @@ -0,0 +1,938 @@ + + + + + + +Postfix Bottleneck Analysis + + + + + + + +

Postfix Bottleneck Analysis

+ +
+ +

Purpose of this document

+ +

This document is an introduction to Postfix queue congestion analysis. +It explains how the qshape(1) program can help to track down the +reason for queue congestion. qshape(1) is bundled with Postfix +2.1 and later source code, under the "auxiliary" directory. This +document describes qshape(1) as bundled with Postfix 2.4.

+ +

This document covers the following topics:

+ + + +

Introducing the qshape tool

+ +

When mail is draining slowly or the queue is unexpectedly large, +run qshape(1) as the super-user (root) to help zero in on the problem. +The qshape(1) program displays a tabular view of the Postfix queue +contents.

+ + + +

For example, in the output below we see the top 10 lines of +the (mostly forged) sender domain distribution for captured spam +in the "hold" queue:

+ +
+
+$ qshape -s hold | head
+                         T  5 10 20 40 80 160 320 640 1280 1280+
+                 TOTAL 486  0  0  1  0  0   2   4  20   40   419
+             yahoo.com  14  0  0  1  0  0   0   0   1    0    12
+  extremepricecuts.net  13  0  0  0  0  0   0   0   2    0    11
+        ms35.hinet.net  12  0  0  0  0  0   0   0   0    1    11
+      winnersdaily.net  12  0  0  0  0  0   0   0   2    0    10
+           hotmail.com  11  0  0  0  0  0   0   0   0    1    10
+           worldnet.fr   6  0  0  0  0  0   0   0   0    0     6
+        ms41.hinet.net   6  0  0  0  0  0   0   0   0    0     6
+                osn.de   5  0  0  0  0  0   1   0   0    0     4
+
+
+ + + +

When the output is a terminal intermediate results showing the top 20 +domains (-n option) are displayed after every 1000 messages (-N option) +and the final output also shows only the top 20 domains. This makes +qshape useful even when the deferred queue is very large and it may +otherwise take prohibitively long to read the entire deferred queue.

+ +

By default, qshape shows statistics for the union of both the +incoming and active queues which are the most relevant queues to +look at when analyzing performance.

+ +

One can request an alternate list of queues:

+ +
+
+$ qshape deferred
+$ qshape incoming active deferred
+
+
+ +

this will show the age distribution of the deferred queue or +the union of the incoming active and deferred queues.

+ +

Command line options control the number of display "buckets", +the age limit for the smallest bucket, display of parent domain +counts and so on. The "-h" option outputs a summary of the available +switches.

+ +

Trouble shooting with qshape +

+ +

Large numbers in the qshape output represent a large number of +messages that are destined to (or alleged to come from) a particular +domain. It should be possible to tell at a glance which domains +dominate the queue sender or recipient counts, approximately when +a burst of mail started, and when it stopped.

+ +

The problem destinations or sender domains appear near the top +left corner of the output table. Remember that the active queue +can accommodate up to 20000 ($qmgr_message_active_limit) messages. +To check whether this limit has been reached, use:

+ +
+
+$ qshape -s active       (show sender statistics)
+
+
+ +

If the total sender count is below 20000 the active queue is +not yet saturated, any high volume sender domains show near the +top of the output. + +

With oqmgr(8) the active queue is also limited to at most 20000 +recipient addresses ($qmgr_message_recipient_limit). To check for +exhaustion of this limit use:

+ +
+
+$ qshape active          (show recipient statistics)
+
+
+ +

Having found the high volume domains, it is often useful to +search the logs for recent messages pertaining to the domains in +question.

+ +
+
+# Find deliveries to example.com
+#
+$ tail -10000 /var/log/maillog |
+        egrep -i ': to=<.*@example\.com>,' |
+        less
+
+# Find messages from example.com
+#
+$ tail -10000 /var/log/maillog |
+        egrep -i ': from=<.*@example\.com>,' |
+        less
+
+
+ +

You may want to drill in on some specific queue ids:

+ +
+
+# Find all messages for a specific queue id.
+#
+$ tail -10000 /var/log/maillog | egrep ': 2B2173FF68: '
+
+
+ +

Also look for queue manager warning messages in the log. These +warnings can suggest strategies to reduce congestion.

+ +
+
+$ egrep 'qmgr.*(panic|fatal|error|warning):' /var/log/maillog
+
+
+ +

When all else fails try the Postfix mailing list for help, but +please don't forget to include the top 10 or 20 lines of qshape(1) +output.

+ +

Example 1: Healthy queue

+ +

When looking at just the incoming and active queues, under +normal conditions (no congestion) the incoming and active queues +are nearly empty. Mail leaves the system almost as quickly as it +comes in or is deferred without congestion in the active queue. +

+ +
+
+$ qshape        (show incoming and active queue status)
+
+                 T  5 10 20 40 80 160 320 640 1280 1280+
+          TOTAL  5  0  0  0  1  0   0   0   1    1     2
+  meri.uwasa.fi  5  0  0  0  1  0   0   0   1    1     2
+
+
+ +

If one looks at the two queues separately, the incoming queue +is empty or perhaps briefly has one or two messages, while the +active queue holds more messages and for a somewhat longer time: +

+ +
+
+$ qshape incoming
+
+                 T  5 10 20 40 80 160 320 640 1280 1280+
+          TOTAL  0  0  0  0  0  0   0   0   0    0     0
+
+$ qshape active
+
+                 T  5 10 20 40 80 160 320 640 1280 1280+
+          TOTAL  5  0  0  0  1  0   0   0   1    1     2
+  meri.uwasa.fi  5  0  0  0  1  0   0   0   1    1     2
+
+
+ +

Example 2: Deferred queue full of +dictionary attack bounces

+ +

This is from a server where recipient validation is not yet +available for some of the hosted domains. Dictionary attacks on +the unvalidated domains result in bounce backscatter. The bounces +dominate the queue, but with proper tuning they do not saturate the +incoming or active queues. The high volume of deferred mail is not +a direct cause for alarm.

+ +
+
+$ qshape deferred | head
+
+                         T  5 10 20 40 80 160 320 640 1280 1280+
+                TOTAL 2234  4  2  5  9 31  57 108 201  464  1353
+  heyhihellothere.com  207  0  0  1  1  6   6   8  25   68    92
+  pleazerzoneprod.com  105  0  0  0  0  0   0   0   5   44    56
+       groups.msn.com   63  2  1  2  4  4  14  14  14    8     0
+    orion.toppoint.de   49  0  0  0  1  0   2   4   3   16    23
+          kali.com.cn   46  0  0  0  0  1   0   2   6   12    25
+        meri.uwasa.fi   44  0  0  0  0  1   0   2   8   11    22
+    gjr.paknet.com.pk   43  1  0  0  1  1   3   3   6   12    16
+ aristotle.algonet.se   41  0  0  0  0  0   1   2  11   12    15
+
+
+ +

The domains shown are mostly bulk-mailers and all the volume +is the tail end of the time distribution, showing that short term +arrival rates are moderate. Larger numbers and lower message ages +are more indicative of current trouble. Old mail still going nowhere +is largely harmless so long as the active and incoming queues are +short. We can also see that the groups.msn.com undeliverables are +low rate steady stream rather than a concentrated dictionary attack +that is now over.

+ +
+
+$ qshape -s deferred | head
+
+                     T  5 10 20 40 80 160 320 640 1280 1280+
+            TOTAL 2193  4  4  5  8 33  56 104 205  465  1309
+    MAILER-DAEMON 1709  4  4  5  8 33  55 101 198  452   849
+      example.com  263  0  0  0  0  0   0   0   0    2   261
+      example.org  209  0  0  0  0  0   1   3   6   11   188
+      example.net    6  0  0  0  0  0   0   0   0    0     6
+      example.edu    3  0  0  0  0  0   0   0   0    0     3
+      example.gov    2  0  0  0  0  0   0   0   1    0     1
+      example.mil    1  0  0  0  0  0   0   0   0    0     1
+
+
+ +

Looking at the sender distribution, we see that as expected +most of the messages are bounces.

+ +

Example 3: Congestion in the active +queue

+ +

This example is taken from a Feb 2004 discussion on the Postfix +Users list. Congestion was reported with the active and incoming +queues large and not shrinking despite very large delivery agent +process limits. The thread is archived at: +http://groups.google.com/groups?threadm=c0b7js$2r65$1@FreeBSD.csie.NCTU.edu.tw +and +http://archives.neohapsis.com/archives/postfix/2004-02/thread.html#1371 +

+ +

Using an older version of qshape(1) it was quickly determined +that all the messages were for just a few destinations:

+ +
+
+$ qshape        (show incoming and active queue status)
+
+                           T   A   5  10  20  40  80 160 320 320+
+                 TOTAL 11775 9996  0   0   1   1  42  94 221 1420
+  user.sourceforge.net  7678 7678  0   0   0   0   0   0   0    0
+ lists.sourceforge.net  2313 2313  0   0   0   0   0   0   0    0
+        gzd.gotdns.com   102    0  0   0   0   0   0   0   2  100
+
+
+ +

The "A" column showed the count of messages in the active queue, +and the numbered columns showed totals for the deferred queue. At +10000 messages (Postfix 1.x active queue size limit) the active +queue is full. The incoming was growing rapidly.

+ +

With the trouble destinations clearly identified, the administrator +quickly found and fixed the problem. It is substantially harder to +glean the same information from the logs. While a careful reading +of mailq(1) output should yield similar results, it is much harder +to gauge the magnitude of the problem by looking at the queue +one message at a time.

+ +

Example 4: High volume destination backlog

+ +

When a site you send a lot of email to is down or slow, mail +messages will rapidly build up in the deferred queue, or worse, in +the active queue. The qshape output will show large numbers for +the destination domain in all age buckets that overlap the starting +time of the problem:

+ +
+
+$ qshape deferred | head
+
+                    T   5  10  20  40   80  160 320 640 1280 1280+
+           TOTAL 5000 200 200 400 800 1600 1000 200 200  200   200
+  highvolume.com 4000 160 160 320 640 1280 1440   0   0    0     0
+             ...
+
+
+ +

Here the "highvolume.com" destination is continuing to accumulate +deferred mail. The incoming and active queues are fine, but the +deferred queue started growing some time between 1 and 2 hours ago +and continues to grow.

+ +

If the high volume destination is not down, but is instead +slow, one might see similar congestion in the active queue. Active +queue congestion is a greater cause for alarm; one might need to +take measures to ensure that the mail is deferred instead or even +add an access(5) rule asking the sender to try again later.

+ +

If a high volume destination exhibits frequent bursts of consecutive +connections refused by all MX hosts or "421 Server busy errors", it +is possible for the queue manager to mark the destination as "dead" +despite the transient nature of the errors. The destination will be +retried again after the expiration of a $minimal_backoff_time timer. +If the error bursts are frequent enough it may be that only a small +quantity of email is delivered before the destination is again marked +"dead". In some cases enabling static (not on demand) connection +caching by listing the appropriate nexthop domain in a table included in +"smtp_connection_cache_destinations" may help to reduce the error rate, +because most messages will re-use existing connections.

+ +

The MTA that has been observed most frequently to exhibit such +bursts of errors is Microsoft Exchange, which refuses connections +under load. Some proxy virus scanners in front of the Exchange +server propagate the refused connection to the client as a "421" +error.

+ +

Note that it is now possible to configure Postfix to exhibit similarly +erratic behavior by misconfiguring the anvil(8) service. Do not use +anvil(8) for steady-state rate limiting, its purpose is (unintentional) +DoS prevention and the rate limits set should be very generous!

+ +

If one finds oneself needing to deliver a high volume of mail to a +destination that exhibits frequent brief bursts of errors and connection +caching does not solve the problem, there is a subtle workaround.

+ + + +

The effect of this configuration is that up to 2000 +consecutive errors are tolerated without marking the destination +dead, while the total concurrency remains reasonable (10-20 +processes). This trick is only for a very specialized situation: +high volume delivery into a channel with multi-error bursts +that is capable of high throughput, but is repeatedly throttled by +the bursts of errors.

+ +

When a destination is unable to handle the load even after the +Postfix process limit is reduced to 1, a desperate measure is to +insert brief delays between delivery attempts.

+ + + +

Postfix queue directories

+ +

The following sections describe Postfix queues: their purpose, +what normal behavior looks like, and how to diagnose abnormal +behavior.

+ +

The "maildrop" queue

+ +

Messages that have been submitted via the Postfix sendmail(1) +command, but not yet brought into the main Postfix queue by the +pickup(8) service, await processing in the "maildrop" queue. Messages +can be added to the "maildrop" queue even when the Postfix system +is not running. They will begin to be processed once Postfix is +started.

+ +

The "maildrop" queue is drained by the single threaded pickup(8) +service scanning the queue directory periodically or when notified +of new message arrival by the postdrop(1) program. The postdrop(1) +program is a setgid helper that allows the unprivileged Postfix +sendmail(1) program to inject mail into the "maildrop" queue and +to notify the pickup(8) service of its arrival.

+ +

All mail that enters the main Postfix queue does so via the +cleanup(8) service. The cleanup service is responsible for envelope +and header rewriting, header and body regular expression checks, +automatic bcc recipient processing, milter content processing, and +reliable insertion of the message into the Postfix "incoming" queue.

+ +

In the absence of excessive CPU consumption in cleanup(8) header +or body regular expression checks or other software consuming all +available CPU resources, Postfix performance is disk I/O bound. +The rate at which the pickup(8) service can inject messages into +the queue is largely determined by disk access times, since the +cleanup(8) service must commit the message to stable storage before +returning success. The same is true of the postdrop(1) program +writing the message to the "maildrop" directory.

+ +

As the pickup service is single threaded, it can only deliver +one message at a time at a rate that does not exceed the reciprocal +disk I/O latency (+ CPU if not negligible) of the cleanup service. +

+ +

Congestion in this queue is indicative of an excessive local message +submission rate or perhaps excessive CPU consumption in the cleanup(8) +service due to excessive body_checks, or (Postfix ≥ 2.3) high latency +milters.

+ +

Note, that once the active queue is full, the cleanup service +will attempt to slow down message injection by pausing $in_flow_delay +for each message. In this case "maildrop" queue congestion may be +a consequence of congestion downstream, rather than a problem in +its own right.

+ +

Note, you should not attempt to deliver large volumes of mail via +the pickup(8) service. High volume sites should avoid using "simple" +content filters that re-inject scanned mail via Postfix sendmail(1) +and postdrop(1).

+ +

A high arrival rate of locally submitted mail may be an indication +of an uncaught forwarding loop, or a run-away notification program. +Try to keep the volume of local mail injection to a moderate level. +

+ +

The "postsuper -r" command can place selected messages into +the "maildrop" queue for reprocessing. This is most useful for +resetting any stale content_filter settings. Requeuing a large number +of messages using "postsuper -r" can clearly cause a spike in the +size of the "maildrop" queue.

+ +

The "hold" queue

+ +

The administrator can define "smtpd" access(5) policies, or +cleanup(8) header/body checks that cause messages to be automatically +diverted from normal processing and placed indefinitely in the +"hold" queue. Messages placed in the "hold" queue stay there until +the administrator intervenes. No periodic delivery attempts are +made for messages in the "hold" queue. The postsuper(1) command +can be used to manually release messages into the "deferred" queue. +

+ +

Messages can potentially stay in the "hold" queue longer than +$maximal_queue_lifetime. If such "old" messages need to be released from +the "hold" queue, they should typically be moved into the "maildrop" +queue using "postsuper -r", so that the message gets a new timestamp and +is given more than one opportunity to be delivered. Messages that are +"young" can be moved directly into the "deferred" queue using +"postsuper -H".

+ +

The "hold" queue plays little role in Postfix performance, and +monitoring of the "hold" queue is typically more closely motivated +by tracking spam and malware, than by performance issues.

+ +

The "incoming" queue

+ +

All new mail entering the Postfix queue is written by the +cleanup(8) service into the "incoming" queue. New queue files are +created owned by the "postfix" user with an access bitmask (or +mode) of 0600. Once a queue file is ready for further processing +the cleanup(8) service changes the queue file mode to 0700 and +notifies the queue manager of new mail arrival. The queue manager +ignores incomplete queue files whose mode is 0600, as these are +still being written by cleanup.

+ +

The queue manager scans the incoming queue bringing any new +mail into the "active" queue if the active queue resource limits +have not been exceeded. By default, the active queue accommodates +at most 20000 messages. Once the active queue message limit is +reached, the queue manager stops scanning the incoming (and deferred, +see below) queue.

+ +

Under normal conditions the incoming queue is nearly empty (has +only mode 0600 files), with the queue manager able to import new +messages into the active queue as soon as they become available. +

+ +

The incoming queue grows when the message input rate spikes +above the rate at which the queue manager can import messages into +the active queue. The main factors slowing down the queue manager +are disk I/O and lookup queries to the trivial-rewrite service. If the queue +manager is routinely not keeping up, consider not using "slow" +lookup services (MySQL, LDAP, ...) for transport lookups or speeding +up the hosts that provide the lookup service. If the problem is I/O +starvation, consider striping the queue over more disks, faster controllers +with a battery write cache, or other hardware improvements. At the very +least, make sure that the queue directory is mounted with the "noatime" +option if applicable to the underlying filesystem.

+ +

The in_flow_delay parameter is used to clamp the input rate +when the queue manager starts to fall behind. The cleanup(8) service +will pause for $in_flow_delay seconds before creating a new queue +file if it cannot obtain a "token" from the queue manager.

+ +

Since the number of cleanup(8) processes is limited in most +cases by the SMTP server concurrency, the input rate can exceed +the output rate by at most "SMTP connection count" / $in_flow_delay +messages per second.

+ +

With a default process limit of 100, and an in_flow_delay of +1s, the coupling is strong enough to limit a single run-away injector +to 1 message per second, but is not strong enough to deflect an +excessive input rate from many sources at the same time.

+ +

If a server is being hammered from multiple directions, consider +raising the in_flow_delay to 10 seconds, but only if the incoming +queue is growing even while the active queue is not full and the +trivial-rewrite service is using a fast transport lookup mechanism. +

+ +

The "active" queue

+ +

The queue manager is a delivery agent scheduler; it works to +ensure fast and fair delivery of mail to all destinations within +designated resource limits.

+ +

The active queue is somewhat analogous to an operating system's +process run queue. Messages in the active queue are ready to be +sent (runnable), but are not necessarily in the process of being +sent (running).

+ +

While most Postfix administrators think of the "active" queue +as a directory on disk, the real "active" queue is a set of data +structures in the memory of the queue manager process.

+ +

Messages in the "maildrop", "hold", "incoming" and "deferred" +queues (see below) do not occupy memory; they are safely stored on +disk waiting for their turn to be processed. The envelope information +for messages in the "active" queue is managed in memory, allowing +the queue manager to do global scheduling, allocating available +delivery agent processes to an appropriate message in the active +queue.

+ +

Within the active queue, (multi-recipient) messages are broken +up into groups of recipients that share the same transport/nexthop +combination; the group size is capped by the transport's recipient +concurrency limit.

+ +

Multiple recipient groups (from one or more messages) are queued +for delivery grouped by transport/nexthop combination. The +destination concurrency limit for the transports caps the number +of simultaneous delivery attempts for each nexthop. Transports with +a recipient concurrency limit of 1 are special: these are grouped +by the actual recipient address rather than the nexthop, yielding +per-recipient concurrency limits rather than per-domain +concurrency limits. Per-recipient limits are appropriate when +performing final delivery to mailboxes rather than when relaying +to a remote server.

+ +

Congestion occurs in the active queue when one or more destinations +drain slower than the corresponding message input rate.

+ +

Input into the active queue comes both from new mail in the "incoming" +queue, and retries of mail in the "deferred" queue. Should the "deferred" +queue get really large, retries of old mail can dominate the arrival +rate of new mail. Systems with more CPU, faster disks and more network +bandwidth can deal with larger deferred queues, but as a rule of thumb +the deferred queue scales to somewhere between 100,000 and 1,000,000 +messages with good performance unlikely above that "limit". Systems with +queues this large should typically stop accepting new mail, or put the +backlog "on hold" until the underlying issue is fixed (provided that +there is enough capacity to handle just the new mail).

+ +

When a destination is down for some time, the queue manager will +mark it dead, and immediately defer all mail for the destination without +trying to assign it to a delivery agent. In this case the messages +will quickly leave the active queue and end up in the deferred queue +(with Postfix < 2.4, this is done directly by the queue manager, +with Postfix ≥ 2.4 this is done via the "retry" delivery agent).

+ +

When the destination is instead simply slow, or there is a problem +causing an excessive arrival rate the active queue will grow and will +become dominated by mail to the congested destination.

+ +

The only way to reduce congestion is to either reduce the input +rate or increase the throughput. Increasing the throughput requires +either increasing the concurrency or reducing the latency of +deliveries.

+ +

For high volume sites a key tuning parameter is the number of +"smtp" delivery agents allocated to the "smtp" and "relay" transports. +High volume sites tend to send to many different destinations, many +of which may be down or slow, so a good fraction of the available +delivery agents will be blocked waiting for slow sites. Also mail +destined across the globe will incur large SMTP command-response +latencies, so high message throughput can only be achieved with +more concurrent delivery agents.

+ +

The default "smtp" process limit of 100 is good enough for most +sites, and may even need to be lowered for sites with low bandwidth +connections (no use increasing concurrency once the network pipe +is full). When one finds that the queue is growing on an "idle" +system (CPU, disk I/O and network not exhausted) the remaining +reason for congestion is insufficient concurrency in the face of +a high average latency. If the number of outbound SMTP connections +(either ESTABLISHED or SYN_SENT) reaches the process limit, mail +is draining slowly and the system and network are not loaded, raise +the "smtp" and/or "relay" process limits!

+ +

When a high volume destination is served by multiple MX hosts with +typically low delivery latency, performance can suffer dramatically when +one of the MX hosts is unresponsive and SMTP connections to that host +timeout. For example, if there are 2 equal weight MX hosts, the SMTP +connection timeout is 30 seconds and one of the MX hosts is down, the +average SMTP connection will take approximately 15 seconds to complete. +With a default per-destination concurrency limit of 20 connections, +throughput falls to just over 1 message per second.

+ +

The best way to avoid bottlenecks when one or more MX hosts is +non-responsive is to use connection caching. Connection caching was +introduced with Postfix 2.2 and is by default enabled on demand for +destinations with a backlog of mail in the active queue. When connection +caching is in effect for a particular destination, established connections +are re-used to send additional messages, this reduces the number of +connections made per message delivery and maintains good throughput even +in the face of partial unavailability of the destination's MX hosts.

+ +

If connection caching is not available (Postfix < 2.2) or does +not provide a sufficient latency reduction, especially for the "relay" +transport used to forward mail to "your own" domains, consider setting +lower than default SMTP connection timeouts (1-5 seconds) and higher +than default destination concurrency limits. This will further reduce +latency and provide more concurrency to maintain throughput should +latency rise.

+ +

Setting high concurrency limits to domains that are not your own may +be viewed as hostile by the receiving system, and steps may be taken +to prevent you from monopolizing the destination system's resources. +The defensive measures may substantially reduce your throughput or block +access entirely. Do not set aggressive concurrency limits to remote +domains without coordinating with the administrators of the target +domain.

+ +

If necessary, dedicate and tune custom transports for selected high +volume destinations. The "relay" transport is provided for forwarding mail +to domains for which your server is a primary or backup MX host. These can +make up a substantial fraction of your email traffic. Use the "relay" and +not the "smtp" transport to send email to these domains. Using the "relay" +transport allocates a separate delivery agent pool to these destinations +and allows separate tuning of timeouts and concurrency limits.

+ +

Another common cause of congestion is unwarranted flushing of the +entire deferred queue. The deferred queue holds messages that are likely +to fail to be delivered and are also likely to be slow to fail delivery +(time out). As a result the most common reaction to a large deferred queue +(flush it!) is more than likely counter-productive, and typically makes +the congestion worse. Do not flush the deferred queue unless you expect +that most of its content has recently become deliverable (e.g. relayhost +back up after an outage)!

+ +

Note that whenever the queue manager is restarted, there may +already be messages in the active queue directory, but the "real" +active queue in memory is empty. In order to recover the in-memory +state, the queue manager moves all the active queue messages +back into the incoming queue, and then uses its normal incoming +queue scan to refill the active queue. The process of moving all +the messages back and forth, redoing transport table (trivial-rewrite(8) +resolve service) lookups, and re-importing the messages back into +memory is expensive. At all costs, avoid frequent restarts of the +queue manager (e.g. via frequent execution of "postfix reload").

+ +

The "deferred" queue

+ +

When all the deliverable recipients for a message are delivered, +and for some recipients delivery failed for a transient reason (it +might succeed later), the message is placed in the deferred queue. +

+ +

The queue manager scans the deferred queue periodically. The scan +interval is controlled by the queue_run_delay parameter. While a deferred +queue scan is in progress, if an incoming queue scan is also in progress +(ideally these are brief since the incoming queue should be short), the +queue manager alternates between looking for messages in the "incoming" +queue and in the "deferred" queue. This "round-robin" strategy prevents +starvation of either the incoming or the deferred queues.

+ +

Each deferred queue scan only brings a fraction of the deferred +queue back into the active queue for a retry. This is because each +message in the deferred queue is assigned a "cool-off" time when +it is deferred. This is done by time-warping the modification +time of the queue file into the future. The queue file is not +eligible for a retry if its modification time is not yet reached. +

+ +

The "cool-off" time is at least $minimal_backoff_time and at +most $maximal_backoff_time. The next retry time is set by doubling +the message's age in the queue, and adjusting up or down to lie +within the limits. This means that young messages are initially +retried more often than old messages.

+ +

If a high volume site routinely has large deferred queues, it +may be useful to adjust the queue_run_delay, minimal_backoff_time and +maximal_backoff_time to provide short enough delays on first failure +(Postfix ≥ 2.4 has a sensibly low minimal backoff time by default), +with perhaps longer delays after multiple failures, to reduce the +retransmission rate of old messages and thereby reduce the quantity +of previously deferred mail in the active queue. If you want a really +low minimal_backoff_time, you may also want to lower queue_run_delay, +but understand that more frequent scans will increase the demand for +disk I/O.

+ +

One common cause of large deferred queues is failure to validate +recipients at the SMTP input stage. Since spammers routinely launch +dictionary attacks from unrepliable sender addresses, the bounces +for invalid recipient addresses clog the deferred queue (and at high +volumes proportionally clog the active queue). Recipient validation +is strongly recommended through use of the local_recipient_maps and +relay_recipient_maps parameters. Even when bounces drain quickly they +inundate innocent victims of forgery with unwanted email. To avoid +this, do not accept mail for invalid recipients.

+ +

When a host with lots of deferred mail is down for some time, +it is possible for the entire deferred queue to reach its retry +time simultaneously. This can lead to a very full active queue once +the host comes back up. The phenomenon can repeat approximately +every maximal_backoff_time seconds if the messages are again deferred +after a brief burst of congestion. Perhaps, a future Postfix release +will add a random offset to the retry time (or use a combination +of strategies) to reduce the odds of repeated complete deferred +queue flushes.

+ +

Credits

+ +

The qshape(1) program was developed by Victor Duchovni of Morgan +Stanley, who also wrote the initial version of this document.

+ + + + diff --git a/proto/README b/proto/README new file mode 100644 index 0000000..b1db3e4 --- /dev/null +++ b/proto/README @@ -0,0 +1,34 @@ +This directory contains source for manual pages that aren't generated +from C source code comments, and for README files. + +Tools for these conversions are found in the ../mantools subdirectory. +The most important tool is postlink, which adds all the hyperlinks +between manual pages, configuration parameters and README files. + +Manual pages are in the form of "shell" style comments. They are +converted into nroff(1) input with the srctoman utility, converted +to HTML with man2html, and hyperlinked with postlink. + +The README files are in the form of HTML. The are converted into +hyperlinked HTML with postlink, and are converted into ASCII files +with html2readme. + +The format of the README source files is a little tricky, because +of the way postlink works. + +- postlink hyperlinks all the references to Postfix manual pages, +configuration parameters, README file names, RFC documents, Postfix +address class names, and URLs. Therefore you should not hyperlink +those elements yourself. + +- URLs (such as "http://www.example.com") cannot contain quote, comma, +or space characters. + +- An URL that appears at the end of a line must be followed by one +other character. + +- Text must go between

and

, especially within lists, for +consistency of vertical space. + +- Code fragments must go between 
 and
, again for +consistency of vertical space. diff --git a/proto/RESTRICTION_CLASS_README.html b/proto/RESTRICTION_CLASS_README.html new file mode 100644 index 0000000..0ebce0f --- /dev/null +++ b/proto/RESTRICTION_CLASS_README.html @@ -0,0 +1,239 @@ + + + + + + +Postfix Per-Client/User/etc. Access Control + + + + + + + +

Postfix +Per-Client/User/etc. Access Control

+ +
+ +

Postfix restriction classes

+ +

The Postfix SMTP server supports access restrictions such as +reject_rbl_client or reject_unknown_client_hostname on the right-hand side +of SMTP server access(5) tables. This allows you to implement +different junk mail restrictions for different clients or users. +

+ +

Having to specify lists of access restrictions for every +recipient becomes tedious quickly. Postfix restriction classes +allow you to give easy-to-remember names to groups of UCE restrictions +(such as "permissive", "restrictive", and so on).

+ +

The real reason for the existence of Postfix restriction classes +is more mundane: you can't specify a lookup table on the right-hand +side of a Postfix access table. This is because Postfix needs to +open lookup tables ahead of time, but the reader probably does not +care about these low-level details.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_restriction_classes = restrictive, permissive
+    # With Postfix < 2.3 specify reject_unknown_client.
+    restrictive = reject_unknown_sender_domain reject_unknown_client_hostname ...
+    permissive = permit
+
+    smtpd_recipient_restrictions = 
+        permit_mynetworks
+	# reject_unauth_destination is not needed here if the mail
+	# relay policy is specified with smtpd_relay_restrictions
+	# (available with Postfix 2.10 and later).
+        reject_unauth_destination
+        check_recipient_access hash:/etc/postfix/recipient_access
+        ...
+
+/etc/postfix/recipient_access:
+    joe@my.domain       permissive
+    jane@my.domain      restrictive
+
+
+ +

With this in place, you can use "restrictive" or "permissive" +on the right-hand side of your per-client, helo, sender, or recipient +SMTPD access tables.

+ +

The remainder of this document gives examples of how Postfix +access restriction classes can be used to:

+ + + +

These questions come up frequently, and the examples hopefully +make clear that Postfix restriction classes aren't really the right +solution. They should be used for what they were designed to do, +different junk mail restrictions for different clients or users. +

+ +

Protecting internal email distribution +lists

+ +
+ +

We want to implement an internal email distribution list. +Something like all@our.domain.com, which aliases to all employees. +My first thought was to use the aliases map, but that would lead +to "all" being accessible from the "outside", and this is not +desired... :-)

+ +
+ +

Postfix can implement per-address access controls. What follows +is based on the SMTP client IP address, and therefore is subject +to IP spoofing.

+ +
+
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions =
+        ...
+        check_recipient_access hash:/etc/postfix/access
+        ...the usual stuff...
+
+/etc/postfix/access:
+    all@my.domain   permit_mynetworks,reject
+    all@my.hostname permit_mynetworks,reject
+
+
+ +

Specify dbm instead of hash if your system uses +dbm files instead of db files. To find out what map +types Postfix supports, use the command postconf -m.

+ +

Now, that would be sufficient when your machine receives all +Internet mail directly from the Internet. That's unlikely if your +network is a bit larger than an office. For example, your backup +MX hosts would "launder" the client IP address of mail from the +outside so it would appear to come from a trusted machine.

+ +

In the general case you need two lookup tables: one table that +lists destinations that need to be protected, and one table that +lists domains that are allowed to send to the protected destinations. +

+ +

What follows is based on the sender SMTP envelope address, and +therefore is subject to SMTP sender spoofing.

+ +
+
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions =
+        ...
+        check_recipient_access hash:/etc/postfix/protected_destinations
+        ...the usual stuff...
+
+    smtpd_restriction_classes = insiders_only
+    insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
+
+/etc/postfix/protected_destinations:
+    all@my.domain   insiders_only
+    all@my.hostname insiders_only
+
+/etc/postfix/insiders:
+    my.domain       OK  matches my.domain and subdomains
+    another.domain  OK  matches another.domain and subdomains
+
+
+ +

Getting past this scheme is relatively easy, because all one +has to do is to spoof the SMTP sender address.

+ +

If the internal list is a low-volume one, perhaps it makes more +sense to make it moderated.

+ +

Restricting what users can send mail to +off-site destinations

+ +
+ +

How can I configure Postfix in a way that some users can send +mail to the internet and other users not. The users with no access +should receive a generic bounce message. Please don't discuss +whether such access restrictions are necessary, it was not my +decision.

+ +
+ +

Postfix has support for per-user restrictions. The restrictions +are implemented by the SMTP server. Thus, users that violate the +policy have their mail rejected by the SMTP server. Like this: +

+ +
+
+554 <user@remote>: Access denied
+
+
+ +

The implementation uses two lookup tables. One table defines +what users are restricted in where they can send mail, and the +other table defines what destinations are local. It is left as an +exercise for the reader to change this into a scheme where only +some users have permission to send mail to off-site destinations, +and where most users are restricted.

+ +

The example assumes DB/DBM files, but this could also be done +with LDAP or SQL.

+ +
+
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions =
+        ...
+        check_sender_access hash:/etc/postfix/restricted_senders
+        ...other stuff...
+
+    smtpd_restriction_classes = local_only
+    local_only = 
+        check_recipient_access hash:/etc/postfix/local_domains, reject
+
+/etc/postfix/restricted_senders:
+    foo@domain      local_only
+    bar@domain      local_only
+
+/etc/postfix/local_domains:
+    this.domain     OK      matches this.domain and subdomains
+    that.domain     OK      matches that.domain and subdomains
+
+
+ +

Specify dbm instead of hash if your system uses +dbm files instead of db files. To find out what map +types Postfix supports, use the command postconf -m.

+ +

Note: this scheme does not authenticate the user, and therefore it can be +bypassed in several ways:

+ + + + + + diff --git a/proto/SASL_README.html b/proto/SASL_README.html new file mode 100644 index 0000000..89b1cf4 --- /dev/null +++ b/proto/SASL_README.html @@ -0,0 +1,2258 @@ + + + + +Postfix SASL Howto + + + + + + + +

Postfix SASL Howto

+ +
+ +

How Postfix uses SASL authentication

+ +

SMTP servers need to decide whether an SMTP client is authorized +to send mail to remote destinations, or only to destinations that +the server itself is responsible for. Usually, SMTP servers accept +mail to remote destinations when the client's IP address is in the +"same network" as the server's IP address.

+ +

SMTP clients outside the SMTP server's network need a different +way to get "same network" privileges. To address this need, Postfix +supports SASL authentication (RFC 4954, formerly RFC 2554). With +this a remote SMTP client can authenticate to the Postfix SMTP +server, and the Postfix SMTP client can authenticate to a remote +SMTP server. Once a client is authenticated, a server can give it +"same network" privileges.

+ +

Postfix does not implement SASL itself, but instead uses existing +implementations as building blocks. This means that some SASL-related +configuration files will belong to Postfix, while other +configuration files belong to the specific SASL +implementation that Postfix will use. This document covers both the +Postfix and non-Postfix configuration.

+ +

NOTE: People who go to the trouble of installing Postfix may +have the expectation that Postfix is more secure than some other +mailers. The Cyrus SASL library contains a lot of code. With this, +Postfix becomes as secure as other mail systems that use the Cyrus +SASL library. Dovecot provides an alternative that may be worth +considering.

+ +

You can read more about the following topics:

+ + + +

Configuring SASL authentication in the +Postfix SMTP server

+ +

As mentioned earlier, SASL is implemented separately from +Postfix. For this reason, configuring SASL authentication in the +Postfix SMTP server involves two different steps:

+ + + +

Successful authentication in the Postfix SMTP server requires +a functional SASL framework. Configuring SASL should therefore +always be the first step, before configuring Postfix.

+ +

You can read more about the following topics:

+ + + + +

Which SASL Implementations are +supported?

+ +

Currently the Postfix SMTP server supports the Cyrus SASL and +Dovecot SASL implementations.

+ +
+ +Note + +

Current Postfix versions have a plug-in architecture that can +support multiple SASL implementations. Before Postfix version 2.3, +Postfix had support only for Cyrus SASL.

+ +
+ +

To find out what SASL implementations are compiled into Postfix, +use the following commands:

+ +
+
+% postconf -a (SASL support in the SMTP server)
+% postconf -A (SASL support in the SMTP+LMTP client)
+
+
+ +

These commands are available only with Postfix version 2.3 and +later.

+ +

Configuring Dovecot SASL

+ +

Dovecot is a POP/IMAP server that has its own configuration to +authenticate POP/IMAP clients. When the Postfix SMTP server uses +Dovecot SASL, it reuses parts of this configuration. Consult the +Dovecot documentation for how +to configure and operate the Dovecot authentication server.

+ +

Postfix to Dovecot SASL communication

+ +

Communication between the Postfix SMTP server and Dovecot SASL +happens over a UNIX-domain socket or over a TCP socket. We will +be using a UNIX-domain socket for better privacy.

+ +

The following fragment for Dovecot version 2 assumes that the +Postfix queue is under /var/spool/postfix/.

+ +
+
+ 1 conf.d/10-master.conf:
+ 2     service auth {
+ 3       ...
+ 4       unix_listener /var/spool/postfix/private/auth {
+ 5         mode = 0660
+ 6         # Assuming the default Postfix user and group
+ 7         user = postfix
+ 8         group = postfix        
+ 9       }
+10       ...
+11     }
+12 
+13 conf.d/10-auth.conf
+14     auth_mechanisms = plain login
+
+
+ +

Line 4 places the Dovecot SASL socket in +/var/spool/postfix/private/auth, lines 5-8 limit +read+write permissions to user and group postfix only, +and line 14 provides plain and login as +mechanisms for the Postfix SMTP server.

+ +

Proceed with the section "Enabling +SASL authentication and authorization in the Postfix SMTP server" +to turn on and use SASL in the Postfix SMTP server.

+ +

Configuring Cyrus SASL

+ +

The Cyrus SASL framework supports a wide variety of applications +(POP, IMAP, SMTP, etc.). Different applications may require different +configurations. As a consequence each application may have its own +configuration file.

+ +

The first step configuring Cyrus SASL is to determine name and +location of a configuration file that describes how the Postfix +SMTP server will use the SASL framework.

+ +

Cyrus SASL configuration file name

+ +

The name of the configuration file (default: smtpd.conf) +is configurable. It is a concatenation from a value that the Postfix +SMTP server sends to the Cyrus SASL library, and the suffix +.conf, added by Cyrus SASL.

+ +

The value sent by Postfix is the name of the server component +that will use Cyrus SASL. It defaults to smtpd and +is configured with one of the following variables:

+ +
+
+/etc/postfix/main.cf:
+    # Postfix 2.3 and later
+    smtpd_sasl_path = smtpd
+
+    # Postfix < 2.3
+    smtpd_sasl_application_name = smtpd
+
+
+ +

Cyrus SASL configuration file +location

+ +

The location where Cyrus SASL searches for the named file depends +on the Cyrus SASL version and the OS/distribution used.

+ +

You can read more about the following topics:

+ + + +
+ +Note + +

Cyrus SASL searches /usr/lib/sasl2/ first. If it +finds the specified configuration file there, it will not examine +other locations.

+ +
+ +

Postfix to Cyrus SASL communication

+ +

As the Postfix SMTP server is linked with the Cyrus SASL library +libsasl, communication between Postfix and Cyrus SASL +takes place by calling functions in the SASL library.

+ +

The SASL library may use an external password verification +service, or an internal plugin to connect to authentication backends +and verify the SMTP client's authentication data against the system +password file or other databases.

+ +

The following table shows typical combinations discussed in +this document:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
authentication backendpassword verification service / plugin
/etc/shadowsaslauthd
PAMsaslauthd
IMAP serversaslauthd
sasldbsasldb
MySQL, PostgreSQL, SQLitesql
LDAPldapdb
+ +
+ +
+ +Note + +

Read the Cyrus SASL documentation for other backends it can +use.

+ +
+ +

saslauthd - Cyrus SASL password verification service

+ +

Communication between the Postfix SMTP server (read: Cyrus SASL's +libsasl) and the saslauthd server takes +place over a UNIX-domain socket.

+ +

saslauthd usually establishes the UNIX domain +socket in /var/run/saslauthd/ and waits for authentication +requests. The Postfix SMTP server must have read+execute permission +to this directory or authentication attempts will fail.

+ +
+ +Important + +

Some distributions require the user postfix to be +member of a special group e.g. sasl, otherwise it +will not be able to access the saslauthd socket +directory.

+ +
+ +

The following example configures the Cyrus SASL library to +contact saslauthd as its password verification service: +

+ +
+
+/etc/sasl2/smtpd.conf:
+    pwcheck_method: saslauthd
+    mech_list: PLAIN LOGIN
+
+
+ +
+ +Important + +

Do not specify any other mechanisms in mech_list +than PLAIN or LOGIN when using +saslauthd! It can only handle these two mechanisms, +and authentication will fail if clients are allowed to choose other +mechanisms.

+ +
+ +
+ +Important + +

Plaintext mechanisms (PLAIN, LOGIN) +send credentials unencrypted. This information should be protected +by an additional security layer such as a TLS-encrypted SMTP session +(see: TLS_README).

+ +
+ +

Additionally the saslauthd server itself must be +configured. It must be told which authentication backend to turn +to for password verification. The backend is selected with a +saslauthd command-line option and will be shown in the +following examples.

+ +
+ +Note + +

Some distributions use a configuration file to provide saslauthd +command line options to set e.g. the authentication backend. Typical +locations are /etc/sysconfig/saslauthd or +/etc/default/saslauthd.

+ +
+ +

Using saslauthd with /etc/shadow

+ +

Access to the /etc/shadow system password file +requires root privileges. The Postfix SMTP server +(and in consequence libsasl linked to the server) runs +with the least privilege possible. Direct access to +/etc/shadow would not be possible without breaking the +Postfix security architecture.

+ +

The saslauthd socket builds a safe bridge. Postfix, +running as limited user postfix, can access the +UNIX-domain socket that saslauthd receives commands +on; saslauthd, running as privileged user root, +has the privileges required to access the shadow file.

+ +

The saslauthd server verifies passwords against the +authentication backend /etc/shadow if started like this:

+ +
+
+% saslauthd -a shadow
+
+
+ +

See section "Testing saslauthd +authentication" for test instructions.

+ +

Using saslauthd with PAM

+ +

Cyrus SASL can use the PAM framework to authenticate credentials. +saslauthd uses the PAM framework when started like +this:

+ +
+
+% saslauthd -a pam
+
+
+ +
+ +Note + +

PAM configuration for the Postfix SMTP server is usually given +in /etc/pam.d/smtp and is beyond the scope of this +document.

+ +
+ +

See section "Testing saslauthd +authentication" for test instructions.

+ +

Using saslauthd with an IMAP server

+ +

saslauthd can verify the SMTP client credentials +by using them to log into an IMAP server. If the login succeeds, +SASL authentication also succeeds. saslauthd contacts +an IMAP server when started like this:

+ +
+
+% saslauthd -a rimap -O imap.example.com
+
+
+ +
+ +Note + +

The option "-O imap.example.com" specifies the +IMAP server saslauthd should contact when it verifies +credentials.

+ +
+ +
+ +Important + +

saslauthd sends IMAP login information unencrypted. +Any IMAP session leaving the local host should be protected by an +additional security layer such as an SSL tunnel.

+ +
+ +

See section "Testing saslauthd +authentication" for test instructions.

+ +

Testing saslauthd authentication

+ +

Cyrus SASL provides the testsaslauthd utility to +test saslauthd authentication. The username and password +are given as command line arguments. The example shows the response +when authentication is successful:

+ +
+
+% testsaslauthd -u username -p password
+0: OK "Success."
+
+
+ +
+ +Note + +

Sometimes the testsaslauthd program is not distributed +with a the Cyrus SASL main package. In that case, it may be +distributed with -devel, -dev or +-debug packages.

+ +
+ +

Specify an additional "-s smtp" if saslauthd +was configured to contact the PAM authentication framework, and +specify an additional "-f /path/to/socketdir/mux" +if saslauthd establishes the UNIX-domain socket in a +non-default location.

+ +

If authentication succeeds, proceed with the section "Enabling SASL authentication and authorization +in the Postfix SMTP server".

+ +

Cyrus SASL Plugins - auxiliary property +plugins

+ +

Cyrus SASL uses a plugin infrastructure (called auxprop) +to expand libsasl's capabilities. Currently Cyrus +SASL sources provide three authentication plugins.

+ +
+ + + + + + + + + + + +
Plugin Description
sasldb Accounts +are stored stored in a Cyrus SASL Berkeley DB database
sql Accounts are +stored in a SQL database
ldapdb Accounts +are stored stored in an LDAP database
+ +
+ +
+ +Important + +

These three plugins support shared-secret mechanisms i.e. +CRAM-MD5, DIGEST-MD5 and NTLM. These mechanisms send credentials +encrypted but their verification process requires the password to +be available in plaintext. Consequently passwords cannot (!) be +stored in encrypted form.

+ +
+ +

The sasldb plugin

+ +

The sasldb auxprop plugin authenticates SASL clients against +credentials that are stored in a Berkeley DB database. The database +schema is specific to Cyrus SASL. The database is usually located +at /etc/sasldb2.

+ +
+ +Note + +

The sasldb2 file contains passwords in +plaintext, and should have read+write access only to user +postfix or a group that postfix is member +of.

+ +
+ +

The saslpasswd2 command-line utility creates +and maintains the database:

+ +
+
+% saslpasswd2 -c -u example.com username
+Password:
+Again (for verification):
+
+
+ +

This command creates an account +username@example.com.

+ +
+ +Important + +

users must specify username@example.com +as login name, not username.

+ +
+ +

Run the following command to reuse the Postfix mydomain +parameter value as the login domain:

+ +
+
+% saslpasswd2 -c -u `postconf -h mydomain` username
+Password:
+Again (for verification):
+
+
+ +
+ +Note + +

Run saslpasswd2 without any options for further +help on how to use the command.

+ +
+ +

The sasldblistusers2 command lists all existing +users in the sasldb database:

+ +
+
+% sasldblistusers2
+username1@example.com: password1
+username2@example.com: password2
+
+
+ +

Configure libsasl to use sasldb with the following instructions:

+ +
+
+/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: sasldb
+    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+
+
+ +
+ +Note + +

In the above example adjust mech_list to the +mechanisms that are applicable for your environment.

+ +
+ +

The sql plugin

+ +

The sql auxprop plugin is a generic SQL plugin. It provides +access to credentials stored in a MySQL, PostgreSQL or SQLite +database. This plugin requires that SASL client passwords are +stored as plaintext.

+ +
+ +Tip + +

If you must store encrypted passwords, you cannot use the sql +auxprop plugin. Instead, see section "Using +saslauthd with PAM", and configure PAM to look up the encrypted +passwords with, for example, the pam_mysql module. +You will not be able to use any of the methods that require access +to plaintext passwords, such as the shared-secret methods CRAM-MD5 +and DIGEST-MD5.

+ +
+ +

The following example configures libsasl to use the sql plugin +and connects it to a PostgreSQL server:

+ +
+
+/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: sql
+    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+    sql_engine: pgsql
+    sql_hostnames: 127.0.0.1, 192.0.2.1
+    sql_user: username
+    sql_passwd: secret
+    sql_database: dbname
+    sql_select: SELECT password FROM users WHERE user = '%u@%r'
+
+
+ +
+ +Note + +

Set appropriate permissions if smtpd.conf contains +a password. The file should be readable by the postfix +user.

+ +
+ +
+ +Note + +

In the above example, adjust mech_list to the +mechanisms that are applicable for your environment.

+ +
+ +

The sql plugin has the following configuration options:

+ +
+ +
+ +
sql_engine
+ +
+ +

Specify mysql to connect to a MySQL server, +pgsql for a PostgreSQL server or sqlite +for an SQLite database

+ +
+ +
sql_hostnames
+ +
+ +

Specify one or more servers (hostname or hostname:port) separated +by commas.

+ +
+ +Note + +

With MySQL servers, specify localhost to connect +over a UNIX-domain socket, and specify 127.0.0.1 to +connect over a TCP socket.

+ +
+ +
+ +
sql_user
+ +
+ +

The login name to gain access to the database.

+ +
+ +
sql_passwd
+ +
+ +

The password to gain access to the database.

+ +
+ +
sql_database
+ +
+ +

The name of the database to connect to.

+ +
+ +
sql_select
+ +
+ +

The SELECT statement that should retrieve the plaintext password +from a database table.

+ +
+ +Important + +

Do not enclose the statement in quotes! Use single quotes to +escape macros!

+ +
+ +
+ +
+ +
+ +

The sql plugin provides macros to build sql_select +statements. They will be replaced with arguments sent from the client. The +following macros are available:

+ +
+ +
+ +
%u
+ +
+ +

The name of the user whose properties are being selected.

+ +
+ +
%p
+ +
+ +

The name of the property being selected. While this could technically be +anything, Cyrus SASL will try userPassword and cmusaslsecretMECHNAME (where +MECHNAME is the name of a SASL mechanism).

+ +
+ +
%r
+ +
+ +

The name of the realm to which the user belongs. This could be +the KERBEROS realm, the fully-qualified domain name of the computer +the SASL application is running on, or the domain after the "@" in a +username.

+ +
+ +
+ +
+ +

The ldapdb plugin

+ +

The ldapdb auxprop plugin provides access to credentials stored +in an LDAP server. This plugin requires that SASL client passwords are +stored as plaintext.

+ +
+ +Tip + +

If you must store encrypted passwords, you cannot use the ldapdb +auxprop plugin. Instead, you can use "saslauthd -a ldap" +to query the LDAP database directly, with appropriate configuration +in saslauthd.conf, as +described here. You will not be able to use any of the +methods that require access to plaintext passwords, such as the +shared-secret methods CRAM-MD5 and DIGEST-MD5.

+ +
+ +

The ldapdb plugin implements proxy authorization. This means +that the ldapdb plugin uses its own username and password to +authenticate with the LDAP server, before it asks the LDAP server +for the remote SMTP client's password. The LDAP server then decides +if the ldapdb plugin is authorized to read the remote SMTP client's +password.

+ +

In a nutshell: Configuring ldapdb means authentication and +authorization must be configured twice - once in the Postfix SMTP +server to authenticate and authorize the remote SMTP client, and +once in the LDAP server to authenticate and authorize the ldapdb +plugin.

+ +

This example configures libsasl to use the ldapdb plugin and +the plugin to connect to an LDAP server:

+ +
+
+/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: ldapdb
+    mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5
+    ldapdb_uri: ldap://localhost
+    ldapdb_id: proxyuser
+    ldapdb_pw: password
+    ldapdb_mech: DIGEST-MD5
+
+
+ +
+ +Important + +

Set appropriate permissions if smtpd.conf contains a +password. The file should be readable by the postfix +user.

+ +
+ +
+ +Note + +

The shared-secret mechanisms (CRAM-MD5, etc.) require that the +SASL client passwords are stored as plaintext.

+ +
+ +

The following is a summary of applicable smtpd.conf +file entries:

+ +
+ +
+ +
auxprop_plugin
+ +

Specify ldapdb to enable the plugin.

+ +
ldapdb_uri
+ +

Specify either ldapi:// for to connect over +a UNIX-domain socket, ldap:// for an unencrypted TCP +connection or ldaps:// for an encrypted TCP connection. +

+ +
ldapdb_id
+ +

The login name to authenticate the ldapdb plugin to the +LDAP server (proxy authorization).

+ +
ldapdb_pw
+ +

The password (in plaintext) to authenticate the ldapdb +plugin to the LDAP server (proxy authorization).

+ +
ldapdb_mech
+ +

The mechanism to authenticate the ldapdb plugin to the +LDAP server.

+ +
+ +Note + +

Specify a mechanism here that is supported by the LDAP server. +

+ +
+ +
+ +
ldapdb_rc (optional)
+ +

The path to a file containing individual configuration +options for the ldapdb LDAP client (libldap). This allows to specify +a TLS client certificate which in turn can be used to use the SASL +EXTERNAL mechanism.

+ +
+ +Note + +

This mechanism supports authentication over an encrypted transport +layer, which is recommended if the plugin must connect to an OpenLDAP +server on a remote machine.

+ +
+ +
+ +
ldapdb_starttls (optional)
+ +

The TLS policy for connecting to the LDAP server. Specify +either try or demand. If the option is +try the plugin will attempt to establish a TLS-encrypted +connection with the LDAP server, and will fallback to an unencrypted +connection if TLS fails. If the policy is demand and +a TLS-encrypted connection cannot be established, the connection +fails immediately.

+ +
+ +
+ +

When the ldapdb plugin connects to the OpenLDAP server and +successfully authenticates, the OpenLDAP server decides if the +plugin user is authorized to read SASL account information.

+ +

The following configuration gives an example of authorization configuration +in the OpenLDAP slapd server:

+ +
+
+/etc/openldap/slapd.conf:
+    authz-regexp
+    uid=(.*),cn=.*,cn=auth
+    ldap:///dc=example,dc=com??sub?cn=$1
+    authz-policy to
+
+
+ +

Here, the authz-regexp option serves for authentication +of the ldapdb user. It maps its login name to a DN in the LDAP +directory tree where slapd can look up the SASL account +information. The authz-policy options defines the +authentication policy. In this case it grants authentication +privileges "to" the ldapdb plugin.

+ +

The last configuration step is to tell the OpenLDAP slapd +server where ldapdb may search for usernames matching the one given +by the mail client. The example below adds an additional attribute +ldapdb user object (here: authzTo because the authz-policy +is "to") and configures the scope where the login name +"proxyuser" may search:

+ +
+
+dn: cn=proxyuser,dc=example,dc=com
+changetype: modify
+add: authzTo
+authzTo: dn.regex:uniqueIdentifier=(.*),ou=people,dc=example,dc=com
+
+
+ +

Use the ldapmodify or ldapadd command +to add the above attribute.

+ +
+ +Note + +

Read the chapter "Using SASL" in the OpenLDAP Admin Guide +for more detailed instructions to set up SASL authentication in +OpenLDAP.

+ +
+ +

Enabling SASL authentication and +authorization in the Postfix SMTP server

+ +

By default the Postfix SMTP server uses the Cyrus SASL +implementation. If the Dovecot SASL implementation should be used, +specify an smtpd_sasl_type value of dovecot +instead of cyrus:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sasl_type = dovecot
+
+
+ +

Additionally specify how Postfix SMTP server can find the Dovecot +authentication server. This depends on the settings that you have +selected in the section "Postfix to +Dovecot SASL communication".

+ + + +

Enabling SASL authentication +in the Postfix SMTP server

+ +

Regardless of the SASL implementation type, enabling SMTP +authentication in the Postfix SMTP server always requires setting +the smtpd_sasl_auth_enable option:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sasl_auth_enable = yes
+
+
+ +

After a "postfix reload", SMTP clients will see the additional +capability AUTH in an SMTP session, followed by a list of +authentication mechanisms the server supports:

+ +
+
+% telnet server.example.com 25
+...
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+...
+
+
+ +

However not all clients recognize the AUTH capability as defined +by the SASL authentication RFC. Some historical implementations expect the +server to send an "=" as separator between the AUTH +verb and the list of mechanisms that follows it.

+ +

The broken_sasl_auth_clients configuration option +lets Postfix repeat the AUTH statement in a form that these broken +clients understand:

+ +
+
+/etc/postfix/main.cf:
+    broken_sasl_auth_clients = yes
+
+
+ +
+ +Note + +

Enable this option for Outlook up to and including version 2003 +and Outlook Express up to version 6. This option does not hurt other +clients.

+ +
+ +

After "postfix reload", the Postfix SMTP server will propagate +the AUTH capability twice - once for compliant and once for broken +clients:

+ +
+
+% telnet server.example.com 25
+...
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5
+...
+
+
+ +

Postfix SMTP Server policy +- SASL mechanism properties

+ +

The Postfix SMTP server supports policies that limit the SASL +mechanisms that it makes available to clients, based on the properties +of those mechanisms. The next two sections give examples of how +these policies are used.

+ +
+ + + + + + + + + + + + + + + +
Property Description
noanonymous Don't use mechanisms that permit +anonymous authentication.
noplaintext Don't use mechanisms that transmit +unencrypted username and password information.
nodictionary Don't use mechanisms that are +vulnerable to dictionary attacks.
forward_secrecy Require forward secrecy between +sessions (breaking one session does not break earlier sessions). +
mutual_auth Use only mechanisms that authenticate +both the client and the server to each other.
+ +
+ +

Unencrypted SMTP session

+ +

The default policy is to allow any mechanism in the Postfix SMTP server +except for those based on anonymous authentication:

+ +
+
+/etc/postfix/main.cf:
+    # Specify a list of properties separated by comma or whitespace
+    smtpd_sasl_security_options = noanonymous
+
+
+ +
+ +Important + +

Always set at least the noanonymous option. +Otherwise, the Postfix SMTP server can give strangers the same +authorization as a properly-authenticated client.

+ +
+ +

Encrypted SMTP session (TLS)

+ +

A separate parameter controls Postfix SASL mechanism policy +during a TLS-encrypted SMTP session. The default is to copy the +settings from the unencrypted session:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
+
+
+ +

A more sophisticated policy allows plaintext mechanisms, but +only over a TLS-encrypted connection:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sasl_security_options = noanonymous, noplaintext
+    smtpd_sasl_tls_security_options = noanonymous
+
+
+ +

To offer SASL authentication only after a TLS-encrypted session has been +established specify this:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_auth_only = yes
+
+
+ +

Enabling SASL authorization in the Postfix +SMTP server

+ +

After the client has authenticated with SASL, the Postfix SMTP +server decides what the remote SMTP client will be authorized +for. Examples of possible SMTP clients authorizations are:

+ + + +

These permissions are not enabled by default.

+ +

Mail relay authorization

+ +

With permit_sasl_authenticated the Postfix SMTP +server can allow +SASL-authenticated SMTP clients to send mail to remote destinations. +Examples: +

+ +
+
+# With Postfix 2.10 and later, the mail relay policy is
+# preferably specified under smtpd_relay_restrictions.
+/etc/postfix/main.cf:
+    smtpd_relay_restrictions =
+	permit_mynetworks
+	permit_sasl_authenticated
+	reject_unauth_destination
+
+ +
+# Older configurations combine relay control and spam control under
+# smtpd_recipient_restrictions. To use this example with Postfix ≥
+# 2.10 specify "smtpd_relay_restrictions=".
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions =
+	permit_mynetworks
+	permit_sasl_authenticated
+	reject_unauth_destination
+	...other rules...
+
+
+ +

Envelope sender address +authorization

+ +

By default an SMTP client may specify any envelope sender address +in the MAIL FROM command. That is because the Postfix SMTP server +only knows the remote SMTP client hostname and IP address, but not +the user who controls the remote SMTP client.

+ +

This changes the moment an SMTP client uses SASL authentication. +Now, the Postfix SMTP server knows who the sender is. Given a table +of envelope sender addresses and SASL login names, the Postfix SMTP +server can decide if the SASL authenticated client is allowed to +use a particular envelope sender address:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
+
+    smtpd_recipient_restrictions =
+        ...
+        reject_sender_login_mismatch
+	permit_sasl_authenticated
+        ...
+
+
+ +

The controlled_envelope_senders table specifies +the binding between a sender envelope address and the SASL login +names that own that address:

+ +
+
+/etc/postfix/controlled_envelope_senders
+    # envelope sender           owners (SASL login names)
+    john@example.com            john@example.com
+    helpdesk@example.com        john@example.com, mary@example.com
+    postmaster                  admin@example.com
+    @example.net                barney, fred, john@example.com, mary@example.com
+
+
+ +

With this, the reject_sender_login_mismatch +restriction above will reject the sender address in the MAIL FROM +command if smtpd_sender_login_maps does not specify +the SMTP client's login name as an owner of that address.

+ +

See also reject_authenticated_sender_login_mismatch, +reject_known_sender_login_mismatch, and +reject_unauthenticated_sender_login_mismatch for additional +control over the SASL login name and the envelope sender.

+ +

Additional SMTP Server SASL options

+ +

Postfix provides a wide range of SASL authentication configuration +options. The next section lists a few that are discussed frequently. +See postconf(5) for a complete list.

+ +

Per-account access control

+ +

Postfix can implement policies that depend on the SASL login +name (Postfix 2.11 and later). Typically this is used to HOLD or +REJECT mail from accounts whose credentials have been compromised. +

+ +
+
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions = 
+	permit_mynetworks 
+	check_sasl_access hash:/etc/postfix/sasl_access
+	permit_sasl_authenticated
+	...
+
+/etc/postfix/sasl_access:
+     # Use this when smtpd_sasl_local_domain is empty.
+     username	HOLD
+     # Use this when smtpd_sasl_local_domain=example.com.
+     username@example.com HOLD
+
+
+ +

Default authentication domain

+ +

Postfix can append a domain name (or any other string) to a +SASL login name that does not have a domain part, e.g. "john" +instead of "john@example.com":

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sasl_local_domain = example.com
+
+
+ +

This is useful as a default setting and safety net for misconfigured +clients, or during a migration to an authentication method/backend +that requires an authentication REALM or domain name, before all +SMTP clients are configured to send such information.

+ +

Hiding SASL authentication from clients or +networks

+ +

Some clients insist on using SASL authentication if it is offered, even +when they are not configured to send credentials - and therefore +they will always fail and disconnect.

+ +

Postfix can hide the AUTH capability from these clients/networks:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24
+
+
+ +

Adding the SASL login name to mail headers

+ +

To report SASL login names in Received: message headers (Postfix +version 2.3 and later):

+ +
+
+/etc/postfix/main.cf:
+    smtpd_sasl_authenticated_header = yes
+
+
+ +
+ +Note + +

The SASL login names will be shared with the entire world.

+ +
+ +

Testing SASL authentication in the Postfix SMTP Server

+ +

To test the server side, connect (for example, with +telnet) to the Postfix SMTP server port and you should +be able to have a conversation as shown below. Information sent by +the client (that is, you) is shown in bold font. +

+ +
+
+% telnet server.example.com 25
+...
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-ETRN
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+250 8BITMIME
+AUTH PLAIN AHRlc3QAdGVzdHBhc3M=
+235 Authentication successful
+
+
+ +

To test this over a connection that is encrypted with TLS, use +openssl s_client instead of telnet: + +

+
+% openssl s_client -connect server.example.com:25 -starttls smtp
+...
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+...see above example for more...
+
+
+ +

Instead of AHRlc3QAdGVzdHBhc3M=, specify the +base64-encoded form of \0username\0password (the \0 +is a null byte). The example above is for a user named `test' +with password `testpass'.

+
+ +Caution + +

When posting logs of the SASL negotiations to public lists, +please keep in mind that username/password information is trivial +to recover from the base64-encoded form.

+ +
+ +

You can use one of the following commands to generate base64 +encoded authentication information:

+ + + +

Configuring SASL authentication in the Postfix SMTP/LMTP client

+ +

The Postfix SMTP and the LMTP client can authenticate with a +remote SMTP server via the Cyrus SASL framework. At this time, the +Dovecot SASL implementation does not provide client functionality. +

+ +
+ +Note + +

The examples in this section discuss only the SMTP client. +Replace smtp_ with lmtp_ to get the +corresponding LMTP client configuration.

+ +
+ +

You can read more about the following topics:

+ + + +

Enabling SASL authentication in the +Postfix SMTP/LMTP client

+ +

This section shows a typical scenario where the Postfix SMTP +client sends all messages via a mail gateway server that requires +SASL authentication.

+ +
+ + Trouble solving tips: + + + +
+ +

To make the example more readable we introduce it in two parts. +The first part takes care of the basic configuration, while the +second part sets up the username/password information.

+ +
+
+/etc/postfix/main.cf:
+    smtp_sasl_auth_enable = yes
+    smtp_tls_security_level = encrypt
+    smtp_sasl_tls_security_options = noanonymous
+    relayhost = [mail.isp.example]
+    # Alternative form:
+    # relayhost = [mail.isp.example]:submission
+    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+
+
+ + + +
+
+/etc/postfix/sasl_passwd:
+    # destination                   credentials
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
+
+ +
+ +Important + +

Keep the SASL client password file in /etc/postfix, +and make the file read+write only for root to protect +the username/password combinations against other users. The Postfix +SMTP client will still be able to read the SASL client passwords. +It opens the file as user root before it drops privileges, +and before entering an optional chroot jail.

+ +
+ + + +

Configuring Sender-Dependent SASL +authentication

+ +

Postfix supports different ISP accounts for different sender +addresses (version 2.3 and later). This can be useful when one +person uses the same machine for work and for personal use, or when +people with different ISP accounts share the same Postfix server. +

+ +

To make this possible, Postfix supports per-sender SASL passwords +and per-sender relay hosts. In the example below, the Postfix SMTP +client will search the SASL password file by sender address before +it searches that same file by destination. Likewise, the Postfix +trivial-rewrite(8) daemon will search the per-sender relayhost file, +and use the default relayhost setting only as a final +resort.

+ +
+
+/etc/postfix/main.cf:
+    smtp_sender_dependent_authentication = yes
+    sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
+    smtp_sasl_auth_enable = yes
+    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+    relayhost = [mail.isp.example]
+    # Alternative form:
+    # relayhost = [mail.isp.example]:submission
+
+
+ +
+
+/etc/postfix/sasl_passwd:
+    # Per-sender authentication; see also /etc/postfix/sender_relay.
+    user1@example.com               username1:password1
+    user2@example.net               username2:password2
+    # Login information for the default relayhost.
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
+
+ +
+
+/etc/postfix/sender_relay:
+    # Per-sender provider; see also /etc/postfix/sasl_passwd.
+    user1@example.com               [mail.example.com]:submission
+    user2@example.net               [mail.example.net]
+
+
+ + + +

Postfix SMTP/LMTP client policy - +SASL mechanism properties

+ +

Just like the Postfix SMTP server, the SMTP client has a policy +that determines which SASL mechanisms are acceptable, based on their +properties. The next two sections give examples of how these policies +are used.

+ +
+ + + + + + + + + + + + + +
Property Description
noanonymous Don't use mechanisms that permit +anonymous authentication.
noplaintext Don't use mechanisms that transmit +unencrypted username and password information.
nodictionary Don't use mechanisms that are +vulnerable to dictionary attacks.
mutual_auth Use only mechanisms that authenticate +both the client and the server to each other.
+ +
+ +

Unencrypted SMTP session

+ +

The default policy is stricter than that of the Postfix SMTP +server - plaintext mechanisms are not allowed (nor is any anonymous +mechanism):

+ +
+
+/etc/postfix/main.cf:
+    smtp_sasl_security_options = noplaintext, noanonymous
+
+
+ +

This default policy, which allows no plaintext passwords, leads +to authentication failures if the remote server only offers plaintext +authentication mechanisms (the SMTP server announces "AUTH +PLAIN LOGIN"). In such cases the SMTP client will log the +following error message:

+ +
+
+SASL authentication failure: No worthy mechs found
+
+
+ +
+ +Note + +

This same error message will also be logged when the +libplain.so or liblogin.so modules are +not installed in the /usr/lib/sasl2 directory.

+ +
+ +

The insecure approach is to lower the security standards and +permit plaintext authentication mechanisms:

+ +
+
+/etc/postfix/main.cf:
+    smtp_sasl_security_options = noanonymous
+
+
+ +

The more secure approach is to protect the plaintext username +and password with TLS session encryption. To find out if the remote +SMTP server supports TLS, connect to the server and see if it +announces STARTTLS support as shown in the example. Information +sent by the client (that is, you) is shown in bold +font.

+ +
+
+% telnet server.example.com 25
+...
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-STARTTLS
+...
+
+
+ +

Instead of port 25 (smtp), specify port 587 (submission) where +appropriate.

+ +

Encrypted SMTP session (TLS)

+ +

To turn on TLS in the Postfix SMTP client, see TLS_README for +configuration details.

+ +

The smtp_sasl_tls_security_options parameter controls Postfix +SASL mechanism policy during a TLS-encrypted SMTP session. The +default is to copy the settings from the unencrypted session:

+ +
+
+/etc/postfix/main.cf:
+    smtp_sasl_tls_security_options = $smtp_sasl_security_options
+
+
+ +

A more sophisticated policy allows plaintext mechanisms, but +only over a TLS-encrypted connection:

+ +
+
+/etc/postfix/main.cf:
+    smtp_sasl_security_options = noanonymous, noplaintext
+    smtp_sasl_tls_security_options = noanonymous
+
+
+ +

Postfix SMTP/LMTP client policy - +SASL mechanism names

+ +

Given the SASL security options of the previous section, the +Cyrus SASL library will choose the most secure authentication +mechanism that both the SMTP client and server implement. Unfortunately, +that authentication mechanism may fail because the client or server +is not configured to use that mechanism.

+ +

To prevent this, the Postfix SMTP client can filter the names +of the authentication mechanisms from the remote SMTP server. Used +correctly, the filter hides unwanted mechanisms from the Cyrus SASL +library, forcing the library to choose from the mechanisms the +Postfix SMTP client filter passes through.

+ +

The following example filters out everything but the mechanisms +PLAIN and LOGIN:

+ +
+
+/etc/postfix/main.cf:
+    smtp_sasl_mechanism_filter = plain, login
+
+
+ +
+ +Note + +

If the remote server does not offer any of the mechanisms on +the filter list, authentication will fail.

+ +
+ +

We close this section with an example that passes every mechanism +except for GSSAPI and LOGIN:

+ +
+
+/etc/postfix/main.cf:
+    smtp_sasl_mechanism_filter = !gssapi, !login, static:all
+
+
+ +

Building Postfix with SASL support

+ +

As mentioned elsewhere, Postfix supports two SASL implementations: +Cyrus SASL (SMTP client and server) and Dovecot SASL (SMTP server +only). Both implementations can be built into Postfix simultaneously. +

+ + + +

Building Dovecot SASL support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

Support for the Dovecot version 1 SASL protocol is available +in Postfix 2.3 and later. At the time of writing, only server-side +SASL support is available, so you can't use it to authenticate the +Postfix SMTP client to your network provider's server.

+ +

Dovecot uses its own daemon process for authentication. This +keeps the Postfix build process simple, because there is no need +to link extra libraries into Postfix.

+ +

To generate the necessary Makefiles, execute the following in +the Postfix top-level directory:

+ +
+
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS='-DUSE_SASL_AUTH \
+    -DDEF_SERVER_SASL_TYPE=\"dovecot\"'
+
+
+ +

After this, proceed with "make" as described in +the INSTALL document.

+ +Note + + + +

Building Cyrus SASL support

+ +

Building the Cyrus SASL library

+ +

Postfix works with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are +available from ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.

+ +
+ +Important + +

If you install the Cyrus SASL libraries as per the default, you will have +to create a symlink /usr/lib/sasl -> +/usr/local/lib/sasl for version 1.5.x or +/usr/lib/sasl2 -> /usr/local/lib/sasl2 +for version 2.1.x.

+ +
+ +

Reportedly, Microsoft Outlook (Express) requires the non-standard LOGIN +and/or NTLM authentication mechanism. To enable these authentication +mechanisms, build the Cyrus SASL libraries with:

+ +
+
+% ./configure --enable-login --enable-ntlm
+
+
+ +

Building Postfix with Cyrus SASL support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

The following assumes that the Cyrus SASL include files are in +/usr/local/include, and that the Cyrus SASL libraries are in +/usr/local/lib.

+ +

On some systems this generates the necessary Makefile +definitions:

+ +
+ +
Cyrus SASL version 2.1.x
+ +
+ +
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib -lsasl2"
+
+ +
+ +
Cyrus SASL version 1.5.x
+ +
+ +
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include" AUXLIBS="-L/usr/local/lib -lsasl"
+
+ +
+ +
+ +

On Solaris 2.x you need to specify run-time link information, +otherwise the ld.so run-time linker will not find the SASL shared +library:

+ +
+ +
Cyrus SASL version 2.1.x
+ +
+ +
+% make tidy # remove left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib \
+    -R/usr/local/lib -lsasl2"
+
+ +
+ +
Cyrus SASL version 1.5.x
+ +
+ +
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include" AUXLIBS="-L/usr/local/lib \
+    -R/usr/local/lib -lsasl"
+
+ +
+ +
+ +

Using Cyrus SASL version 1.5.x

+ +

Postfix supports Cyrus SASL version 1.x, but you shouldn't use +it unless you are forced to. The makers of Cyrus SASL write:

+ +
This library is being deprecated and applications +should transition to using the SASLv2 library (source: Project Cyrus: +Downloads).
+ +

If you still need to set it up, here's a quick rundown:

+ +

Read the regular section on SMTP server configurations for the +Cyrus SASL framework. The differences are:

+ + + +

Credits

+ + + + + + + diff --git a/proto/SCHEDULER_README.html b/proto/SCHEDULER_README.html new file mode 100644 index 0000000..f1fbbb2 --- /dev/null +++ b/proto/SCHEDULER_README.html @@ -0,0 +1,1837 @@ + + + + + + +Postfix Queue Scheduler + + + + + + + +

Postfix +Queue Scheduler

+ +
+ +

Disclaimer

+ +

Many of the transport-specific configuration parameters +discussed in this document will not show up in "postconf" command +output before Postfix version 2.9. This limitation applies to many +parameters whose name is a combination of a master.cf service name +such as "relay" and a built-in suffix such as +"_destination_concurrency_limit".

+ +

Overview

+ +

The queue manager is by far the most complex part of the Postfix +mail system. It schedules delivery of new mail, retries failed +deliveries at specific times, and removes mail from the queue after +the last delivery attempt. There are two major classes of mechanisms +that control the operation of the queue manager.

+ +

Topics covered by this document:

+ + + + + +

Concurrency scheduling

+ +

The following sections document the Postfix 2.5 concurrency +scheduler, after a discussion of the limitations of the earlier +concurrency scheduler. This is followed by results of medium-concurrency +experiments, and a discussion of trade-offs between performance and +robustness.

+ +

The material is organized as follows:

+ + + +

Drawbacks of the existing +concurrency scheduler

+ +

From the start, Postfix has used a simple but robust algorithm +where the per-destination delivery concurrency is decremented by 1 +after delivery failed due to connection or handshake failure, and +incremented by 1 otherwise. Of course the concurrency is never +allowed to exceed the maximum per-destination concurrency limit. +And when a destination's concurrency level drops to zero, the +destination is declared "dead" and delivery is suspended.

+ +

Drawbacks of +/-1 concurrency feedback per delivery are:

+ +

+ +

(*) A pseudo-cohort is a number of delivery requests equal to +a destination's delivery concurrency.

+ +

The revised concurrency scheduler has a highly modular structure. +It uses separate mechanisms for per-destination concurrency control +and for "dead destination" detection. The concurrency control in +turn is built from two separate mechanisms: it supports less-than-1 +feedback per delivery to allow for more gradual concurrency +adjustments, and it uses feedback hysteresis to suppress concurrency +oscillations. And instead of waiting for delivery concurrency to +throttle down to zero, a destination is declared "dead" after a +configurable number of pseudo-cohorts reports connection or handshake +failure.

+ +

Summary of the Postfix 2.5 +concurrency feedback algorithm

+ +

We want to increment a destination's delivery concurrency when +some (not necessarily consecutive) number of deliveries complete +without connection or handshake failure. This is implemented with +positive feedback g(N) where N is the destination's delivery +concurrency. With g(N)=1 feedback per delivery, concurrency increases +by 1 after each positive feedback event; this gives us the old +scheduler's exponential growth in time. With g(N)=1/N feedback per +delivery, concurrency increases by 1 after an entire pseudo-cohort +N of positive feedback reports; this gives us linear growth in time. +Less-than-1 feedback per delivery and integer truncation naturally +give us hysteresis, so that transitions to larger concurrency happen +every 1/g(N) positive feedback events.

+ +

We want to decrement a destination's delivery concurrency when +some (not necessarily consecutive) number of deliveries complete +after connection or handshake failure. This is implemented with +negative feedback f(N) where N is the destination's delivery +concurrency. With f(N)=1 feedback per delivery, concurrency decreases +by 1 after each negative feedback event; this gives us the old +scheduler's behavior where concurrency is throttled down dramatically +after a single pseudo-cohort failure. With f(N)=1/N feedback per +delivery, concurrency backs off more gently. Again, less-than-1 +feedback per delivery and integer truncation naturally give us +hysteresis, so that transitions to lower concurrency happen every +1/f(N) negative feedback events.

+ +

However, with negative feedback we introduce a subtle twist. +We "reverse" the negative hysteresis cycle so that the transition +to lower concurrency happens at the beginning of a sequence +of 1/f(N) negative feedback events. Otherwise, a correction for +overload would be made too late. This makes the choice of f(N) +relatively unimportant, as borne out by measurements later in this +document.

+ +

In summary, the main ingredients for the Postfix 2.5 concurrency +feedback algorithm are a) the option of less-than-1 positive feedback +per delivery to avoid overwhelming servers, b) the option of +less-than-1 negative feedback per delivery to avoid giving up too +fast, c) feedback hysteresis to avoid rapid oscillation, and d) a +"reverse" hysteresis cycle for negative feedback, so that it can +correct for overload quickly.

+ +

Summary of the Postfix 2.5 "dead destination" detection algorithm

+ +

We want to suspend deliveries to a specific destination after +some number of deliveries suffers connection or handshake failure. +The old scheduler declares a destination "dead" when negative (-1) +feedback throttles the delivery concurrency down to zero. With +less-than-1 feedback per delivery, this throttling down would +obviously take too long. We therefore have to separate "dead +destination" detection from concurrency feedback. This is implemented +by introducing the concept of pseudo-cohort failure. The Postfix +2.5 concurrency scheduler declares a destination "dead" after a +configurable number of pseudo-cohorts suffers from connection or +handshake failures. The old scheduler corresponds to the special +case where the pseudo-cohort failure limit is equal to 1.

+ +

Pseudocode for the Postfix 2.5 concurrency scheduler

+ +

The pseudo code shows how the ideas behind new concurrency +scheduler are implemented as of November 2007. The actual code can +be found in the module qmgr/qmgr_queue.c.

+ +
+Types:
+        Each destination has one set of the following variables
+        int concurrency
+        double success
+        double failure
+        double fail_cohorts
+
+Feedback functions:
+        N is concurrency; x, y are arbitrary numbers in [0..1] inclusive
+        positive feedback: g(N) = x/N | x/sqrt(N) | x
+        negative feedback: f(N) = y/N | y/sqrt(N) | y
+
+Initialization:
+        concurrency = initial_concurrency
+        success = 0
+        failure = 0
+        fail_cohorts = 0
+
+After success:
+        fail_cohorts = 0
+        Be prepared for feedback > hysteresis, or rounding error
+        success += g(concurrency)
+        while (success >= 1)            Hysteresis 1
+            concurrency += 1            Hysteresis 1
+            failure = 0
+            success -= 1                Hysteresis 1
+        Be prepared for overshoot
+        if (concurrency > concurrency limit)
+            concurrency = concurrency limit
+
+Safety:
+        Don't apply positive feedback unless
+            concurrency < busy_refcount + init_dest_concurrency
+        otherwise negative feedback effect could be delayed
+
+After failure:
+        if (concurrency > 0)
+            fail_cohorts += 1.0 / concurrency
+            if (fail_cohorts > cohort_failure_limit)
+                concurrency = 0
+        if (concurrency > 0)
+            Be prepared for feedback > hysteresis, rounding errors
+            failure -= f(concurrency)
+            while (failure < 0)
+                concurrency -= 1        Hysteresis 1
+                failure += 1            Hysteresis 1
+                success = 0
+            Be prepared for overshoot
+            if (concurrency < 1)
+                concurrency = 1
+
+ +

Results for delivery to concurrency-limited servers

+ +

Discussions about the concurrency scheduler redesign started +early 2004, when the primary goal was to find alternatives that did +not exhibit exponential growth or rapid concurrency throttling. No +code was implemented until late 2007, when the primary concern had +shifted towards better handling of server concurrency limits. For +this reason we measure how well the new scheduler does this +job. The table below compares mail delivery performance of the old ++/-1 feedback per delivery with several less-than-1 feedback +functions, for different limited-concurrency server scenarios. +Measurements were done with a FreeBSD 6.2 client and with FreeBSD +6.2 and various Linux servers.

+ +

Server configuration:

+ + + +

Client configuration:

+ + + +

Impact of the 30s SMTP connect timeout

+ +

The first results are for a FreeBSD 6.2 server, where our +artificially low listen(2) backlog results in a very short kernel +queue for established connections. The table shows that all deferred +deliveries failed due to a 30s connection timeout, and none failed +due to a server greeting timeout. This measurement simulates what +happens when the server's connection queue is completely full under +load, and the TCP engine drops new connections.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +
client
limit		 server
limit		 feedback
+style		 connection
caching		 percentage
+deferred		 client concurrency
average/stddev		timed-out in
connect/greeting
20 5 1/N no 9.9 19.4 0.49 198 -
20 5 1/N yes 10.3 19.4 0.49 206 -
20 5 1/sqrt(N) no10.4 19.6 0.59 208 -
20 5 1/sqrt(N) yes10.6 19.6 0.61 212 -
20 5 1 no 10.1 19.5 1.29 202 -
20 5 1 yes 10.8 19.3 1.57 216 -
+ +

A busy server with a completely full connection queue. N is +the client delivery concurrency. Failed deliveries time out after +30s without completing the TCP handshake. See text for a discussion +of results.

+ +
+ +

Impact of the 300s SMTP greeting timeout

+ +

The next table shows results for a Fedora Core 8 server (results +for RedHat 7.3 are identical). In this case, the artificially small +listen(2) backlog argument does not impact our measurement. The +table shows that practically all deferred deliveries fail after the +300s SMTP greeting timeout. As these timeouts were 10x longer than +with the first measurement, we increased the recipient count (and +thus the running time) by a factor of 10 to keep the results +comparable. The deferred mail percentages are a factor 10 lower +than with the first measurement, because the 1s per-recipient delay +was 1/300th of the greeting timeout instead of 1/30th of the +connection timeout.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +
client
limit		 server
limit		 feedback
+style		 connection
caching		 percentage
+deferred		 client concurrency
average/stddev		timed-out in
connect/greeting
20 5 1/N no 1.16 19.8 0.37 - 230
20 5 1/N yes 1.36 19.8 0.36 - 272
20 5 1/sqrt(N) no1.21 19.9 0.23 4 238
20 5 1/sqrt(N) yes1.36 20.0 0.23 - 272
20 5 1 no 1.18 20.0 0.16 - 236
20 5 1 yes 1.39 20.0 0.16 - 278
+ +

A busy server with a non-full connection queue. N is the client +delivery concurrency. Failed deliveries complete at the TCP level, +but time out after 300s while waiting for the SMTP greeting. See +text for a discussion of results.

+ +
+ +

Impact of active server concurrency limiter

+ +

The final concurrency-limited result shows what happens when +SMTP connections don't time out, but are rejected immediately with +the Postfix server's smtpd_client_connection_count_limit feature +(the server replies with a 421 status and disconnects immediately). +Similar results can be expected with concurrency limiting features +built into other MTAs or firewalls. For this measurement we specified +a server concurrency limit and a client initial destination concurrency +of 5, and a server process limit of 10; all other conditions were +the same as with the first measurement. The same result would be +obtained with a FreeBSD or Linux server, because the "pushing back" +is done entirely by the receiving side.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +
client
limit		 server
limit		 feedback
+style		 connection
caching		 percentage
+deferred		 client concurrency
average/stddev		theoretical
defer rate
20 5 1/N no 16.5 5.17 0.38 1/6
20 5 1/N yes 16.5 5.17 0.38 1/6
20 5 1/sqrt(N) no24.5 5.28 0.45 1/4
20 5 1/sqrt(N) yes24.3 5.28 0.46 1/4
20 5 1 no 49.7 5.63 0.67 1/2
20 5 1 yes 49.7 5.68 0.70 1/2
+ +

A server with active per-client concurrency limiter that replies +with 421 and disconnects. N is the client delivery concurrency. +The theoretical defer rate is 1/(1+roundup(1/feedback)). This is +always 1/2 with the fixed +/-1 feedback per delivery; with the +concurrency-dependent feedback variants, the defer rate decreases +with increasing concurrency. See text for a discussion of results. +

+ +
+ +

Discussion of concurrency-limited server results

+ +

All results in the previous sections are based on the first +delivery runs only; they do not include any second etc. delivery +attempts. It's also worth noting that the measurements look at +steady-state behavior only. They don't show what happens when the +client starts sending at a much higher or lower concurrency. +

+ +

The first two examples show that the effect of feedback +is negligible when concurrency is limited due to congestion. This +is because the initial concurrency is already at the client's +concurrency maximum, and because there is 10-100 times more positive +than negative feedback. Under these conditions, it is no surprise +that the contribution from SMTP connection caching is also negligible. +

+ +

In the last example, the old +/-1 feedback per delivery will +defer 50% of the mail when confronted with an active (anvil-style) +server concurrency limit, where the server hangs up immediately +with a 421 status (a TCP-level RST would have the same result). +Less aggressive feedback mechanisms fare better than more aggressive +ones. Concurrency-dependent feedback fares even better at higher +concurrencies than shown here, but has limitations as discussed in +the next section.

+ +

Limitations of less-than-1 per delivery feedback

+ +

Less-than-1 feedback is of interest primarily when sending large +amounts of mail to destinations with active concurrency limiters +(servers that reply with 421, or firewalls that send RST). When +sending small amounts of mail per destination, less-than-1 per-delivery +feedback won't have a noticeable effect on the per-destination +concurrency, because the number of deliveries to the same destination +is too small. You might just as well use zero per-delivery feedback +and stay with the initial per-destination concurrency. And when +mail deliveries fail due to congestion instead of active concurrency +limiters, the measurements above show that per-delivery feedback +has no effect. With large amounts of mail you might just as well +use zero per-delivery feedback and start with the maximal per-destination +concurrency.

+ +

The scheduler with less-than-1 concurrency +feedback per delivery solves a problem with servers that have active +concurrency limiters. This works only because feedback is handled +in a peculiar manner: positive feedback will increment the concurrency +by 1 at the end of a sequence of events of length 1/feedback, +while negative feedback will decrement concurrency by 1 at the +beginning of such a sequence. This is how Postfix adjusts +quickly for overshoot without causing lots of mail to be deferred. +Without this difference in feedback treatment, less-than-1 feedback +per delivery would defer 50% of the mail, and would be no better +in this respect than the old +/-1 feedback per delivery.

+ +

Unfortunately, the same feature that corrects quickly for +concurrency overshoot also makes the scheduler more sensitive for +noisy negative feedback. The reason is that one lonely negative +feedback event has the same effect as a complete sequence of length +1/feedback: in both cases delivery concurrency is dropped by 1 +immediately. As a worst-case scenario, consider multiple servers +behind a load balancer on a single IP address, and no backup MX +address. When 1 out of K servers fails to complete the SMTP handshake +or drops the connection, a scheduler with 1/N (N = concurrency) +feedback stops increasing its concurrency once it reaches a concurrency +level of about K, even though the good servers behind the load +balancer are perfectly capable of handling more traffic.

+ +

This noise problem gets worse as the amount of positive feedback +per delivery gets smaller. A compromise is to use fixed less-than-1 +positive feedback values instead of concurrency-dependent positive +feedback. For example, to tolerate 1 of 4 bad servers in the above +load balancer scenario, use positive feedback of 1/4 per "good" +delivery (no connect or handshake error), and use an equal or smaller +amount of negative feedback per "bad" delivery. The downside of +using concurrency-independent feedback is that some of the old +/-1 +feedback problems will return at large concurrencies. Sites that +must deliver mail at non-trivial per-destination concurrencies will +require special configuration.

+ +

Concurrency configuration parameters

+ +

The Postfix 2.5 concurrency scheduler is controlled with the +following configuration parameters, where "transport_foo" +provides a transport-specific parameter override. All parameter +default settings are compatible with earlier Postfix versions.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +
Parameter name Postfix version +Description
initial_destination_concurrency
+transport_initial_destination_concurrency 		all
2.5 		Initial per-destination +delivery concurrency
default_destination_concurrency_limit
+transport_destination_concurrency_limit 		+all
all 		Maximum per-destination delivery concurrency +
default_destination_concurrency_positive_feedback
+transport_destination_concurrency_positive_feedback 		2.5
2.5 		Per-destination positive +feedback amount, per delivery that does not fail with connection +or handshake failure
default_destination_concurrency_negative_feedback
+transport_destination_concurrency_negative_feedback 		2.5
2.5 		Per-destination negative +feedback amount, per delivery that fails with connection or handshake +failure
default_destination_concurrency_failed_cohort_limit
+transport_destination_concurrency_failed_cohort_limit 		2.5
2.5 		Number of failed +pseudo-cohorts after which a destination is declared "dead" and +delivery is suspended
destination_concurrency_feedback_debug +2.5 Enable verbose logging of concurrency scheduler +activity
+ +
+ +

Preemptive scheduling

+ +

+ +The following sections describe the new queue manager and its +preemptive scheduler algorithm. Note that the document was originally +written to describe the changes between the new queue manager (in +this text referred to as nqmgr, the name it was known by +before it became the default queue manager) and the old queue manager +(referred to as oqmgr). This is why it refers to oqmgr +every so often. + +

+ +

+ +This document is divided into sections as follows: + +

+ + + +

The structures used by +nqmgr

+ +

+ +Let's start by recapitulating the structures and terms used when +referring to queue manager and how it operates. Many of these are +partially described elsewhere, but it is nice to have a coherent +overview in one place: + +

+ + + +

+ +The first four structures are common to both nqmgr and +oqmgr, the latter two were introduced by nqmgr. + +

+ +

+ +These terms are used extensively in the text below, feel free to +look up the description above anytime you'll feel you have lost a +sense what is what. + +

+ +

What happens when nqmgr picks +up the message

+ +

+ +Whenever nqmgr moves a queue file into the active queue, +the following happens: It reads all necessary information from the +queue file as oqmgr does, and also reads as many recipients +as possible - more on that later, for now let's just pretend it +always reads all recipients. + +

+ +

+ +Then it resolves the recipients as oqmgr does, which +means obtaining (address, nexthop, transport) triple for each +recipient. For each triple, it finds the transport; if it does not +exist yet, it instantiates it (unless it's dead). Within the +transport, it finds the destination queue for given nexthop; if it +does not exist yet, it instantiates it (unless it's dead). The +triple is then bound to given destination queue. This happens in +qmgr_resolve() and is basically the same as in oqmgr. + +

+ +

+ +Then for each triple which was bound to some queue (and thus +transport), the program finds the job which represents the message +within that transport's context; if it does not exist yet, it +instantiates it. Within the job, it finds the peer which represents +the bound destination queue within this jobs context; if it does +not exist yet, it instantiates it. Finally, it stores the address +from the resolved triple to the recipient entry which is appended +to both the queue entry list and the peer entry list. The addresses +for same nexthop are batched in the entries up to recipient_concurrency +limit for that transport. This happens in qmgr_assign() and apart +from that it operates with job and peer structures it is basically the +same as in oqmgr. + +

+ +

+ +When the job is instantiated, it is enqueued on the transport's job +list based on the time its message was picked up by nqmgr. +For first batch of recipients this means it is appended to the end +of the job list, but the ordering of the job list by the enqueue +time is important as we will see shortly. + +

+ +

+ +[Now you should have pretty good idea what is the state of the +nqmgr after couple of messages was picked up, what is the +relation between all those job, peer, queue and entry structures.] + +

+ +

How the entry selection +works

+ +

+ +Having prepared all those above mentioned structures, the task of +the nqmgr's scheduler is to choose the recipient entries +one at a time and pass them to the delivery agent for corresponding +transport. Now how does this work? + +

+ +

+ +The first approximation of the new scheduling algorithm is like this: + +

+ +
+
+foreach transport (round-robin-by-transport)
+do
+    if transport busy continue
+    if transport process limit reached continue
+    foreach transport's job (in the order of the transport's job list)
+    do
+	foreach job's peer (round-robin-by-destination)
+	     if peer->queue->concurrency < peer->queue->window
+		 return next peer entry.
+	done
+    done
+done
+
+
+ +

+ +Now what is the "order of the transport's job list"? As we know +already, the job list is by default kept in the order the message +was picked up by the nqmgr. So by default we get the +top-level round-robin transport, and within each transport we get +the FIFO message delivery. The round-robin of the peers by the +destination is perhaps of little importance in most real-life cases +(unless the recipient_concurrency limit is reached, in one job there +is only one peer structure for each destination), but theoretically +it makes sure that even within single jobs, destinations are treated +fairly. + +

+ +

+ +[By now you should have a feeling you really know how the scheduler +works, except for the preemption, under ideal conditions - that is, +no recipient resource limits and no destination concurrency problems.] + +

+ +

How the preemption +works

+ +

+ +As you might perhaps expect by now, the transport's job list does +not remain sorted by the job's message enqueue time all the time. +The most cool thing about nqmgr is not the simple FIFO +delivery, but that it is able to slip mail with little recipients +past the mailing-list bulk mail. This is what the job preemption +is about - shuffling the jobs on the transport's job list to get +the best message delivery rates. Now how is it achieved? + +

+ +

+ +First I have to tell you that there are in fact two job lists in +each transport. One is the scheduler's job list, which the scheduler +is free to play with, while the other one keeps the jobs always +listed in the order of the enqueue time and is used for recipient +pool management we will discuss later. For now, we will deal with +the scheduler's job list only. + +

+ +

+ +So, we have the job list, which is first ordered by the time the +jobs' messages were enqueued, oldest messages first, the most recently +picked one at the end. For now, let's assume that there are no +destination concurrency problems. Without preemption, we pick some +entry of the first (oldest) job on the queue, assign it to delivery +agent, pick another one from the same job, assign it again, and so +on, until all the entries are used and the job is delivered. We +would then move onto the next job and so on and on. Now how do we +manage to sneak in some entries from the recently added jobs when +the first job on the job list belongs to a message going to the +mailing-list and has thousands of recipient entries? + +

+ +

+ +The nqmgr's answer is that we can artificially "inflate" +the delivery time of that first job by some constant for free - it +is basically the same trick you might remember as "accumulation of +potential" from the amortized complexity lessons. For example, +instead of delivering the entries of the first job on the job list +every time a delivery agent becomes available, we can do it only +every second time. If you view the moments the delivery agent becomes +available on a timeline as "delivery slots", then instead of using +every delivery slot for the first job, we can use only every other +slot, and still the overall delivery efficiency of the first job +remains the same. So the delivery 11112222 becomes +1.1.1.1.2.2.2.2 (1 and 2 are the imaginary job numbers, . +denotes the free slot). Now what do we do with free slots? + +

+ +

+ +As you might have guessed, we will use them for sneaking the mail +with little recipients in. For example, if we have one four-recipient +mail followed by four one recipients mail, the delivery sequence +(that is, the sequence in which the jobs are assigned to the +delivery slots) might look like this: 12131415. Hmm, fine +for sneaking in the single recipient mail, but how do we sneak in +the mail with more than one recipient? Say if we have one four-recipient +mail followed by two two-recipient mails? + +

+ +

+ +The simple answer would be to use delivery sequence 12121313. +But the problem is that this does not scale well. Imagine you have +mail with thousand recipients followed by mail with hundred recipients. +It is tempting to suggest the delivery sequence like 121212...., +but alas! Imagine there arrives another mail with say ten recipients. +But there are no free slots anymore, so it can't slip by, not even +if it had just only one recipients. It will be stuck until the +hundred-recipient mail is delivered, which really sucks. + +

+ +

+ +So, it becomes obvious that while inflating the message to get +free slots is great idea, one has to be really careful of how the +free slots are assigned, otherwise one might corner himself. So, +how does nqmgr really use the free slots? + +

+ +

+ +The key idea is that one does not have to generate the free slots +in a uniform way. The delivery sequence 111...1 is no +worse than 1.1.1.1, in fact, it is even better as some +entries are in the first case selected earlier than in the second +case, and none is selected later! So it is possible to first +"accumulate" the free delivery slots and then use them all at once. +It is even possible to accumulate some, then use them, then accumulate +some more and use them again, as in 11..1.1 . + +

+ +

+ +Let's get back to the one hundred recipient example. We now know +that we could first accumulate one hundred free slots, and only +after then to preempt the first job and sneak the one hundred +recipient mail in. Applying the algorithm recursively, we see the +hundred recipient job can accumulate ten free delivery slots, and +then we could preempt it and sneak in the ten-recipient mail... +Wait wait wait! Could we? Aren't we overinflating the original one +thousand recipient mail? + +

+ +

+ +Well, despite it looks so at the first glance, another trick will +allow us to answer "no, we are not!". If we had said that we will +inflate the delivery time twice at maximum, and then we consider +every other slot as a free slot, then we would overinflate in case +of the recursive preemption. BUT! The trick is that if we use only +every n-th slot as a free slot for n>2, there is always some worst +inflation factor which we can guarantee not to be breached, even +if we apply the algorithm recursively. To be precise, if for every +k>1 normally used slots we accumulate one free delivery slot, than +the inflation factor is not worse than k/(k-1) no matter how many +recursive preemptions happen. And it's not worse than (k+1)/k if +only non-recursive preemption happens. Now, having got through the +theory and the related math, let's see how nqmgr implements +this. + +

+ +

+ +Each job has so called "available delivery slot" counter. Each +transport has a transport_delivery_slot_cost parameter, which +defaults to default_delivery_slot_cost parameter which is set to 5 +by default. This is the k from the paragraph above. Each time k +entries of the job are selected for delivery, this counter is +incremented by one. Once there are some slots accumulated, job which +requires no more than that number of slots to be fully delivered +can preempt this job. + +

+ +

+ +[Well, the truth is, the counter is incremented every time an entry +is selected and it is divided by k when it is used. +But for the understanding it's good enough to use +the above approximation of the truth.] + +

+ +

+ +OK, so now we know the conditions which must be satisfied so one +job can preempt another one. But what job gets preempted, how do +we choose what job preempts it if there are several valid candidates, +and when does all this exactly happen? + +

+ +

+ +The answer for the first part is simple. The job whose entry was +selected the last time is so called current job. Normally, it is +the first job on the scheduler's job list, but destination concurrency +limits may change this as we will see later. It is always only the +current job which may get preempted. + +

+ +

+ +Now for the second part. The current job has certain amount of +recipient entries, and as such may accumulate at maximum some amount +of available delivery slots. It might have already accumulated some, +and perhaps even already used some when it was preempted before +(remember a job can be preempted several times). In either case, +we know how many are accumulated and how many are left to deliver, +so we know how many it may yet accumulate at maximum. Every other +job which may be delivered by less than that number of slots is a +valid candidate for preemption. How do we choose among them? + +

+ +

+ +The answer is - the one with maximum enqueue_time/recipient_entry_count. +That is, the older the job is, the more we should try to deliver +it in order to get best message delivery rates. These rates are of +course subject to how many recipients the message has, therefore +the division by the recipient (entry) count. No one shall be surprised +that message with n recipients takes n times longer to deliver than +message with one recipient. + +

+ +

+ +Now let's recap the previous two paragraphs. Isn't it too complicated? +Why don't the candidates come only among the jobs which can be +delivered within the number of slots the current job already +accumulated? Why do we need to estimate how much it has yet to +accumulate? If you found out the answer, congratulate yourself. If +we did it this simple way, we would always choose the candidate +with least recipient entries. If there were enough single recipient +mails coming in, they would always slip by the bulk mail as soon +as possible, and the two and more recipients mail would never get +a chance, no matter how long they have been sitting around in the +job list. + +

+ +

+ +This candidate selection has interesting implication - that when +we choose the best candidate for preemption (this is done in +qmgr_choose_candidate()), it may happen that we may not use it for +preemption immediately. This leads to an answer to the last part +of the original question - when does the preemption happen? + +

+ +

+ +The preemption attempt happens every time next transport's recipient +entry is to be chosen for delivery. To avoid needless overhead, the +preemption is not attempted if the current job could never accumulate +more than transport_minimum_delivery_slots (defaults to +default_minimum_delivery_slots which defaults to 3). If there is +already enough accumulated slots to preempt the current job by the +chosen best candidate, it is done immediately. This basically means +that the candidate is moved in front of the current job on the +scheduler's job list and decreasing the accumulated slot counter +by the amount used by the candidate. If there is not enough slots... +well, I could say that nothing happens and the another preemption +is attempted the next time. But that's not the complete truth. + +

+ +

+ +The truth is that it turns out that it is not really necessary to +wait until the jobs counter accumulates all the delivery slots in +advance. Say we have ten-recipient mail followed by two two-recipient +mails. If the preemption happened when enough delivery slot accumulate +(assuming slot cost 2), the delivery sequence becomes +11112211113311. Now what would we get if we would wait +only for 50% of the necessary slots to accumulate and we promise +we would wait for the remaining 50% later, after we get back +to the preempted job? If we use such slot loan, the delivery sequence +becomes 11221111331111. As we can see, it makes it no +considerably worse for the delivery of the ten-recipient mail, but +it allows the small messages to be delivered sooner. + +

+ +

+ +The concept of these slot loans is where the +transport_delivery_slot_discount and +transport_delivery_slot_loan come from (they default to +default_delivery_slot_discount and default_delivery_slot_loan, whose +values are by default 50 and 3, respectively). The discount (resp. +loan) specifies how many percent (resp. how many slots) one "gets +in advance", when the number of slots required to deliver the best +candidate is compared with the number of slots the current slot had +accumulated so far. + +

+ +

+ +And it pretty much concludes this chapter. + +

+ +

+ +[Now you should have a feeling that you pretty much understand the +scheduler and the preemption, or at least that you will have it +after you read the last chapter couple more times. You shall clearly +see the job list and the preemption happening at its head, in ideal +delivery conditions. The feeling of understanding shall last until +you start wondering what happens if some of the jobs are blocked, +which you might eventually figure out correctly from what had been +said already. But I would be surprised if your mental image of the +scheduler's functionality is not completely shattered once you +start wondering how it works when not all recipients may be read +in-core. More on that later.] + +

+ +

How destination concurrency +limits affect the scheduling algorithm

+ +

+ +The nqmgr uses the same algorithm for destination concurrency +control as oqmgr. Now what happens when the destination +limits are reached and no more entries for that destination may be +selected by the scheduler? + +

+ +

+ +From user's point of view it is all simple. If some of the peers +of a job can't be selected, those peers are simply skipped by the +entry selection algorithm (the pseudo-code described before) and +only the selectable ones are used. If none of the peers may be +selected, the job is declared a "blocker job". Blocker jobs are +skipped by the entry selection algorithm and they are also excluded +from the candidates for preemption of current job. Thus the scheduler +effectively behaves as if the blocker jobs didn't exist on the job +list at all. As soon as at least one of the peers of a blocker job +becomes unblocked (that is, the delivery agent handling the delivery +of the recipient entry for given destination successfully finishes), +the job's blocker status is removed and the job again participates +in all further scheduler actions normally. + +

+ +

+ +So the summary is that the users don't really have to be concerned +about the interaction of the destination limits and scheduling +algorithm. It works well on its own and there are no knobs they +would need to control it. + +

+ +

+ +From a programmer's point of view, the blocker jobs complicate the +scheduler quite a lot. Without them, the jobs on the job list would +be normally delivered in strict FIFO order. If the current job is +preempted, the job preempting it is completely delivered unless it +is preempted itself. Without blockers, the current job is thus +always either the first job on the job list, or the top of the stack +of jobs preempting the first job on the job list. + +

+ +

+ +The visualization of the job list and the preemption stack without +blockers would be like this: + +

+ +
+
+first job->    1--2--3--5--6--8--...    <- job list
+on job list    |
+               4    <- preemption stack
+               |
+current job->  7
+
+
+ +

+ +In the example above we see that job 1 was preempted by job 4 and +then job 4 was preempted by job 7. After job 7 is completed, remaining +entries of job 4 are selected, and once they are all selected, job +1 continues. + +

+ +

+ +As we see, it's all very clean and straightforward. Now how does +this change because of blockers? + +

+ +

+ +The answer is: a lot. Any job may become blocker job at any time, +and also become normal job again at any time. This has several +important implications: + +

+ +
    + +

  1. + +The jobs may be completed in arbitrary order. For example, in the +example above, if the current job 7 becomes blocked, the next job +4 may complete before the job 7 becomes unblocked again. Or if both +7 and 4 are blocked, then 1 is completed, then 7 becomes unblocked +and is completed, then 2 is completed and only after that 4 becomes +unblocked and is completed... You get the idea. + +

    + +

    + +[Interesting side note: even when jobs are delivered out of order, +from single destination's point of view the jobs are still delivered +in the expected order (that is, FIFO unless there was some preemption +involved). This is because whenever a destination queue becomes +unblocked (the destination limit allows selection of more recipient +entries for that destination), all jobs which have peers for that +destination are unblocked at once.] + +

    + +

  2. + +The idea of the preemption stack at the head of the job list is +gone. That is, it must be possible to preempt any job on the job +list. For example, if the jobs 7, 4, 1 and 2 in the example above +become all blocked, job 3 becomes the current job. And of course +we do not want the preemption to be affected by the fact that there +are some blocked jobs or not. Therefore, if it turns out that job +3 might be preempted by job 6, the implementation shall make it +possible. + +

    + +

  3. + +The idea of the linear preemption stack itself is gone. It's no +longer true that one job is always preempted by only one job at one +time (that is directly preempted, not counting the recursively +nested jobs). For example, in the example above, job 1 is directly +preempted by only job 4, and job 4 by job 7. Now assume job 7 becomes +blocked, and job 4 is being delivered. If it accumulates enough +delivery slots, it is natural that it might be preempted for example +by job 8. Now job 4 is preempted by both job 7 AND job 8 at the +same time. + +

    + +
+ +

+ +Now combine the points 2) and 3) with point 1) again and you realize +that the relations on the once linear job list became pretty +complicated. If we extend the point 3) example: jobs 7 and 8 preempt +job 4, now job 8 becomes blocked too, then job 4 completes. Tricky, +huh? + +

+ +

+ +If I illustrate the relations after the above mentioned examples +(but those in point 1)), the situation would look like this: + +

+ +
+
+                            v- parent
+
+adoptive parent ->    1--2--3--5--...      <- "stack" level 0
+                      |     |
+parent gone ->        ?     6              <- "stack" level 1
+                     / \
+children ->         7   8   ^- child       <- "stack" level 2
+
+                      ^- siblings
+
+
+ +

+ +Now how does nqmgr deal with all these complicated relations? + +

+ +

+ +Well, it maintains them all as described, but fortunately, all these +relations are necessary only for purposes of proper counting of +available delivery slots. For purposes of ordering the jobs for +entry selection, the original rule still applies: "the job preempting +the current job is moved in front of the current job on the job +list". So for entry selection purposes, the job relations remain +as simple as this: + +

+ +
+
+7--8--1--2--6--3--5--..   <- scheduler's job list order
+
+
+ +

+ +The job list order and the preemption parent/child/siblings relations +are maintained separately. And because the selection works only +with the job list, you can happily forget about those complicated +relations unless you want to study the nqmgr sources. In +that case the text above might provide some helpful introduction +to the problem domain. Otherwise I suggest you just forget about +all this and stick with the user's point of view: the blocker jobs +are simply ignored. + +

+ +

+ +[By now, you should have a feeling that there is more things going +under the hood than you ever wanted to know. You decide that +forgetting about this chapter is the best you can do for the sake +of your mind's health and you basically stick with the idea how the +scheduler works in ideal conditions, when there are no blockers, +which is good enough.] + +

+ +

Dealing with memory resource +limits

+ +

+ +When discussing the nqmgr scheduler, we have so far assumed +that all recipients of all messages in the active queue are completely +read into the memory. This is simply not true. There is an upper +bound on the amount of memory the nqmgr may use, and +therefore it must impose some limits on the information it may store +in the memory at any given time. + +

+ +

+ +First of all, not all messages may be read in-core at once. At any +time, only qmgr_message_active_limit messages may be read in-core +at maximum. When read into memory, the messages are picked from the +incoming and deferred message queues and moved to the active queue +(incoming having priority), so if there is more than +qmgr_message_active_limit messages queued in the active queue, the +rest will have to wait until (some of) the messages in the active +queue are completely delivered (or deferred). + +

+ +

+ +Even with the limited amount of in-core messages, there is another +limit which must be imposed in order to avoid memory exhaustion. +Each message may contain huge amount of recipients (tens or hundreds +of thousands are not uncommon), so if nqmgr read all +recipients of all messages in the active queue, it may easily run +out of memory. Therefore there must be some upper bound on the +amount of message recipients which are read into the memory at the +same time. + +

+ +

+ +Before discussing how exactly nqmgr implements the recipient +limits, let's see how the sole existence of the limits themselves +affects the nqmgr and its scheduler. + +

+ +

+ +The message limit is straightforward - it just limits the size of +the +lookahead the nqmgr's scheduler has when choosing which +message can preempt the current one. Messages not in the active +queue simply are not considered at all. + +

+ +

+ +The recipient limit complicates more things. First of all, the +message reading code must support reading the recipients in batches, +which among other things means accessing the queue file several +times and continuing where the last recipient batch ended. This is +invoked by the scheduler whenever the current job has space for more +recipients, subject to transport's refill_limit and refill_delay parameters. +It is also done any time when all +in-core recipients of the message are dealt with (which may also +mean they were deferred) but there are still more in the queue file. + +

+ +

+ +The second complication is that with some recipients left unread +in the queue file, the scheduler can't operate with exact counts +of recipient entries. With unread recipients, it is not clear how +many recipient entries there will be, as they are subject to +per-destination grouping. It is not even clear to what transports +(and thus jobs) the recipients will be assigned. And with messages +coming from the deferred queue, it is not even clear how many unread +recipients are still to be delivered. This all means that the +scheduler must use only estimates of how many recipients entries +there will be. Fortunately, it is possible to estimate the minimum +and maximum correctly, so the scheduler can always err on the safe +side. Obviously, the better the estimates, the better results, so +it is best when we are able to read all recipients in-core and turn +the estimates into exact counts, or at least try to read as many +as possible to make the estimates as accurate as possible. + +

+ +

+ +The third complication is that it is no longer true that the scheduler +is done with a job once all of its in-core recipients are delivered. +It is possible that the job will be revived later, when another +batch of recipients is read in core. It is also possible that some +jobs will be created for the first time long after the first batch +of recipients was read in core. The nqmgr code must be +ready to handle all such situations. + +

+ +

+ +And finally, the fourth complication is that the nqmgr +code must somehow impose the recipient limit itself. Now how does +it achieve it? + +

+ +

+ +Perhaps the easiest solution would be to say that each message may +have at maximum X recipients stored in-core, but such solution would +be poor for several reasons. With reasonable qmgr_message_active_limit +values, the X would have to be quite low to maintain reasonable +memory footprint. And with low X lots of things would not work well. +The nqmgr would have problems to use the +transport_destination_recipient_limit efficiently. The +scheduler's preemption would be suboptimal as the recipient count +estimates would be inaccurate. The message queue file would have +to be accessed many times to read in more recipients again and +again. + +

+ +

+ +Therefore it seems reasonable to have a solution which does not use +a limit imposed on per-message basis, but which maintains a pool +of available recipient slots, which can be shared among all messages +in the most efficient manner. And as we do not want separate +transports to compete for resources whenever possible, it seems +appropriate to maintain such recipient pool for each transport +separately. This is the general idea, now how does it work in +practice? + +

+ +

+ +First we have to solve little chicken-and-egg problem. If we want +to use the per-transport recipient pools, we first need to know to +what transport(s) is the message assigned. But we will find that +out only after we read in the recipients first. So it is obvious +that we first have to read in some recipients, use them to find out +to what transports is the message to be assigned, and only after +that we can use the per-transport recipient pools. + +

+ +

+ +Now how many recipients shall we read for the first time? This is +what qmgr_message_recipient_minimum and qmgr_message_recipient_limit +values control. The qmgr_message_recipient_minimum value specifies +how many recipients of each message we will read for the first time, +no matter what. It is necessary to read at least one recipient +before we can assign the message to a transport and create the first +job. However, reading only qmgr_message_recipient_minimum recipients +even if there are only few messages with few recipients in-core would +be wasteful. Therefore if there is less than qmgr_message_recipient_limit +recipients in-core so far, the first batch of recipients may be +larger than qmgr_message_recipient_minimum - as large as is required +to reach the qmgr_message_recipient_limit limit. + +

+ +

+ +Once the first batch of recipients was read in core and the message +jobs were created, the size of the subsequent recipient batches (if +any - of course it's best when all recipients are read in one batch) +is based solely on the position of the message jobs on their +corresponding transports' job lists. Each transport has a pool of +transport_recipient_limit recipient slots which it can +distribute among its jobs (how this is done is described later). +The subsequent recipient batch may be as large as the sum of all +recipient slots of all jobs of the message permits (plus the +qmgr_message_recipient_minimum amount which always applies). + +

+ +

+ +For example, if a message has three jobs, first with 1 recipient +still in-core and 4 recipient slots, second with 5 recipient in-core +and 5 recipient slots, and third with 2 recipients in-core and 0 +recipient slots, it has 1+5+2=7 recipients in-core and 4+5+0=9 jobs' +recipients slots in total. This means that we could immediately +read 2+qmgr_message_recipient_minimum more recipients of that message +in core. + +

+ +

+ +The above example illustrates several things which might be worth +mentioning explicitly: first, note that although the per-transport +slots are assigned to particular jobs, we can't guarantee that once +the next batch of recipients is read in core, that the corresponding +amounts of recipients will be assigned to those jobs. The jobs lend +its slots to the message as a whole, so it is possible that some +jobs end up sponsoring other jobs of their message. For example, +if in the example above the 2 newly read recipients were assigned +to the second job, the first job sponsored the second job with 2 +slots. The second notable thing is the third job, which has more +recipients in-core than it has slots. Apart from sponsoring by other +job we just saw it can be result of the first recipient batch, which +is sponsored from global recipient pool of qmgr_message_recipient_limit +recipients. It can be also sponsored from the message recipient +pool of qmgr_message_recipient_minimum recipients. + +

+ +

+ +Now how does each transport distribute the recipient slots among +its jobs? The strategy is quite simple. As most scheduler activity +happens on the head of the job list, it is our intention to make +sure that the scheduler has the best estimates of the recipient +counts for those jobs. As we mentioned above, this means that we +want to try to make sure that the messages of those jobs have all +recipients read in-core. Therefore the transport distributes the +slots "along" the job list from start to end. In this case the job +list sorted by message enqueue time is used, because it doesn't +change over time as the scheduler's job list does. + +

+ +

+ +More specifically, each time a job is created and appended to the +job list, it gets all unused recipient slots from its transport's +pool. It keeps them until all recipients of its message are read. +When this happens, all unused recipient slots are transferred to +the next job (which is now in fact now first such job) on the job +list which still has some recipients unread, or eventually back to +the transport pool if there is no such job. Such transfer then also +happens whenever a recipient entry of that job is delivered. + +

+ +

+ +There is also a scenario when a job is not appended to the end of +the job list (for example it was created as a result of second or +later recipient batch). Then it works exactly as above, except that +if it was put in front of the first unread job (that is, the job +of a message which still has some unread recipients in queue file), +that job is first forced to return all of its unused recipient slots +to the transport pool. + +

+ +

+ +The algorithm just described leads to the following state: The first +unread job on the job list always gets all the remaining recipient +slots of that transport (if there are any). The jobs queued before +this job are completely read (that is, all recipients of their +message were already read in core) and have at maximum as many slots +as they still have recipients in-core (the maximum is there because +of the sponsoring mentioned before) and the jobs after this job get +nothing from the transport recipient pool (unless they got something +before and then the first unread job was created and enqueued in +front of them later - in such case the also get at maximum as many +slots as they have recipients in-core). + +

+ +

+ +Things work fine in such state for most of the time, because the +current job is either completely read in-core or has as much recipient +slots as there are, but there is one situation which we still have +to take care of specially. Imagine if the current job is preempted +by some unread job from the job list and there are no more recipient +slots available, so this new current job could read only batches +of qmgr_message_recipient_minimum recipients at a time. This would +really degrade performance. For this reason, each transport has +extra pool of transport_extra_recipient_limit recipient +slots, dedicated exactly for this situation. Each time an unread +job preempts the current job, it gets half of the remaining recipient +slots from the normal pool and this extra pool. + +

+ +

+ +And that's it. It sure does sound pretty complicated, but fortunately +most people don't really have to care how exactly it works as long +as it works. Perhaps the only important things to know for most +people are the following upper bound formulas: + +

+ +

+ +Each transport has at maximum + +

+ +
+
+max(
+qmgr_message_recipient_minimum * qmgr_message_active_limit
++ *_recipient_limit + *_extra_recipient_limit,
+qmgr_message_recipient_limit
+)
+
+
+ +

+ +recipients in core. + +

+ +

+ +The total amount of recipients in core is + +

+ +
+
+max(
+qmgr_message_recipient_minimum * qmgr_message_active_limit
++ sum( *_recipient_limit + *_extra_recipient_limit ),
+qmgr_message_recipient_limit
+)
+
+
+ +

+ +where the sum is over all used transports. + +

+ +

+ +And this terribly complicated chapter concludes the documentation +of nqmgr scheduler. + +

+ +

+ +[By now you should theoretically know the nqmgr scheduler +inside out. In practice, you still hope that you will never have +to really understand the last or last two chapters completely, and +fortunately most people really won't. Understanding how the scheduler +works in ideal conditions is more than good enough for vast majority +of users.] + +

+ +

Credits

+ + + + + + diff --git a/proto/SMTPD_ACCESS_README.html b/proto/SMTPD_ACCESS_README.html new file mode 100644 index 0000000..af73f78 --- /dev/null +++ b/proto/SMTPD_ACCESS_README.html @@ -0,0 +1,438 @@ + + + + + + +Postfix SMTP relay and access control + + + + + + + +

Postfix +SMTP relay and access control

+ +
+ +

Introduction

+ +

The Postfix SMTP server receives mail from the network and is +exposed to the big bad world of junk email and viruses. This document +introduces the built-in and external methods that control what SMTP +mail Postfix will accept, what mistakes to avoid, and how to test +your configuration.

+ +

Topics covered in this document:

+ + + +

Relay control, junk mail control, and per-user +policies

+ +

In a distant past, the Internet was a friendly environment. +Mail servers happily forwarded mail on behalf of anyone towards +any destination. On today's Internet, spammers abuse servers that +forward mail from arbitrary systems, and abused systems end up on +anti-spammer blacklists. See, for example, the information on +http://www.mail-abuse.org/ and other websites.

+ +

By default, Postfix has a moderately restrictive approach to +mail relaying. Postfix forwards mail only from clients in trusted +networks, from clients that have authenticated with SASL, or to +domains that are configured as authorized relay +destinations. For a description of the default mail relay policy, +see the smtpd_relay_restrictions parameter in the postconf(5) manual +page, and the information that is referenced from there.

+ +

NOTE: Postfix versions before 2.10 did not have +smtpd_relay_restrictions. They combined the mail relay and spam +blocking policies, under smtpd_recipient_restrictions. This could +lead to unexpected results. For example, a permissive spam blocking +policy could unexpectedly result in a permissive mail relay policy. +An example of this is documented under "Dangerous +use of smtpd_recipient_restrictions".

+ +

Most of the Postfix SMTP server access controls are targeted +at stopping junk email.

+ + + +

Unfortunately, all junk mail controls have the possibility of +falsely rejecting legitimate mail. This can be a problem for sites +with many different types of users. For some users it is unacceptable +when any junk email slips through, while for other users the world +comes to an end when a single legitimate email message is blocked. +Because there is no single policy that is "right" for all users, +Postfix supports different SMTP access restrictions for different +users. This is described in the RESTRICTION_CLASS_README document. +

+ +

Restrictions that apply to all SMTP mail

+ +

Besides the restrictions that can be made configurable per +client or per user as described in the next section, Postfix +implements a few restrictions that apply to all SMTP mail.

+ + + +

Getting selective with SMTP access restriction +lists

+ +

Postfix allows you to specify lists of access restrictions for +each stage of the SMTP conversation. Individual restrictions are +described in the postconf(5) manual page.

+ +

Examples of simple restriction lists are:

+ +
+/etc/postfix/main.cf:
+    # Allow connections from trusted networks only.
+    smtpd_client_restrictions = permit_mynetworks, reject
+
+    # Don't talk to mail systems that don't know their own hostname.
+    # With Postfix < 2.3, specify reject_unknown_hostname.
+    smtpd_helo_restrictions = reject_unknown_helo_hostname
+
+    # Don't accept mail from domains that don't exist.
+    smtpd_sender_restrictions = reject_unknown_sender_domain
+
+    # Spam control: exclude local clients and authenticated clients
+    # from DNSBL lookups.
+    smtpd_recipient_restrictions = permit_mynetworks, 
+	permit_sasl_authenticated,
+	# reject_unauth_destination is not needed here if the mail
+	# relay policy is specified under smtpd_relay_restrictions
+	# (available with Postfix 2.10 and later).
+	reject_unauth_destination
+	reject_rbl_client zen.spamhaus.org,
+	reject_rhsbl_reverse_client dbl.spamhaus.org,
+	reject_rhsbl_helo dbl.spamhaus.org,
+	reject_rhsbl_sender dbl.spamhaus.org
+
+    # Relay control (Postfix 2.10 and later): local clients and
+    # authenticated clients may specify any destination domain.
+    smtpd_relay_restrictions = permit_mynetworks, 
+	permit_sasl_authenticated,
+	reject_unauth_destination
+
+    # Block clients that speak too early.
+    smtpd_data_restrictions = reject_unauth_pipelining
+
+    # Enforce mail volume quota via policy service callouts.
+    smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
+
+ +

Each restriction list is evaluated from left to right until +some restriction produces a result of PERMIT, REJECT or DEFER (try +again later). The end of each list is equivalent to a PERMIT result. +By placing a PERMIT restriction before a REJECT restriction you +can make exceptions for specific clients or users. This is called +whitelisting; the fourth example above allows mail from local +networks but otherwise rejects mail to arbitrary destinations.

+ +

The table below summarizes the purpose of each SMTP access +restriction list. All lists use the exact same syntax; they differ +only in the time of evaluation and in the effect of a REJECT or +DEFER result.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Restriction list name Version Status + Effect +of REJECT or DEFER result
smtpd_client_restrictions All +Optional +Reject all client commands
smtpd_helo_restrictions All Optional + +Reject HELO/EHLO information
smtpd_sender_restrictions All +Optional +Reject MAIL FROM information
smtpd_recipient_restrictions ≥ +2.10 Required if smtpd_relay_restrictions does not enforce +relay policy Reject RCPT TO information
< 2.10 Required
smtpd_relay_restrictions ≥ 2.10 + Required if smtpd_recipient_restrictions does not enforce +relay policy Reject RCPT TO information
< 2.10 Not available
smtpd_data_restrictions ≥ 2.0 +Optional +Reject DATA command
smtpd_end_of_data_restrictions ≥ 2.2 Optional +Reject END-OF-DATA command
smtpd_etrn_restrictions All Optional + +Reject ETRN command
+ +
+ +

Delayed evaluation of SMTP access restriction lists +

+ +

Early Postfix versions evaluated SMTP access restrictions lists +as early as possible. The client restriction list was evaluated +before Postfix sent the "220 $myhostname..." greeting banner to +the SMTP client, the helo restriction list was evaluated before +Postfix replied to the HELO (EHLO) command, the sender restriction +list was evaluated before Postfix replied to the MAIL FROM command, +and so on. This approach turned out to be difficult to use.

+ +

Current Postfix versions postpone the evaluation of client, +helo and sender restriction lists until the RCPT TO or ETRN command. +This behavior is controlled by the smtpd_delay_reject parameter. +Restriction lists are still evaluated in the proper order of (client, +helo, etrn) or (client, helo, sender, relay, recipient, data, or +end-of-data) restrictions. +When a restriction list (example: client) evaluates to REJECT or +DEFER the restriction lists that follow (example: helo, sender, etc.) +are skipped.

+ +

Around the time that smtpd_delay_reject was introduced, Postfix +was also changed to support mixed restriction lists that combine +information about the client, helo, sender and recipient or etrn +command.

+ +

Benefits of delayed restriction evaluation, and of restriction +mixing:

+ + + +

Dangerous use of smtpd_recipient_restrictions

+ +

By now the reader may wonder why we need smtpd client, helo +or sender restrictions, when their evaluation is postponed until +the RCPT TO or ETRN command. Some people recommend placing ALL the +access restrictions in the smtpd_recipient_restrictions list. +Unfortunately, this can result in too permissive access. How is +this possible?

+ +

The purpose of the smtpd_recipient_restrictions feature is to +control how Postfix replies to the RCPT TO command. If the restriction +list evaluates to REJECT or DEFER, the recipient address is rejected; +no surprises here. If the result is PERMIT, then the recipient +address is accepted. And this is where surprises can happen.

+ +

The problem is that Postfix versions before 2.10 did not have +smtpd_relay_restrictions. They combined the mail relay and spam +blocking policies, under smtpd_recipient_restrictions. The result +is that a permissive spam blocking policy could unexpectedly result +in a permissive mail relay policy.

+ +

Here is an example that shows when a PERMIT result can result +in too much access permission:

+ +
+1 /etc/postfix/main.cf:
+2     smtpd_recipient_restrictions = 
+3         permit_mynetworks
+4         check_helo_access hash:/etc/postfix/helo_access
+5         reject_unknown_helo_hostname
+6         reject_unauth_destination
+7 
+8 /etc/postfix/helo_access:
+9     localhost.localdomain PERMIT
+
+ +

Line 5 rejects mail from hosts that don't specify a proper +hostname in the HELO command (with Postfix < 2.3, specify +reject_unknown_hostname). Lines 4 and 9 make an exception to +allow mail from some machine that announces itself with "HELO +localhost.localdomain".

+ +

The problem with this configuration is that +smtpd_recipient_restrictions evaluates to PERMIT for EVERY host +that announces itself as "localhost.localdomain", making Postfix +an open relay for all such hosts.

+ +

With Postfix before version 2.10 you should place non-recipient +restrictions AFTER the reject_unauth_destination restriction, not +before. In the above example, the HELO based restrictions should +be placed AFTER reject_unauth_destination, or better, the HELO +based restrictions should be placed under smtpd_helo_restrictions +where they can do no harm.

+ +
+1 /etc/postfix/main.cf:
+2     smtpd_recipient_restrictions = 
+3         permit_mynetworks
+4         reject_unauth_destination
+5         check_helo_access hash:/etc/postfix/helo_access
+6         reject_unknown_helo_hostname
+7 
+8 /etc/postfix/helo_access:
+9     localhost.localdomain PERMIT
+
+ +

The above mistake will not happen with Postfix 2.10 and later, +when the relay policy is specified under smtpd_relay_restrictions, +and the spam blocking policy under smtpd_recipient_restrictions. +Then, a permissive spam blocking policy will not result in a +permissive mail relay policy.

+ +

SMTP access rule testing

+ +

Postfix has several features that aid in SMTP access rule +testing:

+ +
+ +
soft_bounce

This is a safety net that changes +SMTP server REJECT actions into DEFER (try again later) actions. +This keeps mail queued that would otherwise be returned to the +sender. Specify "soft_bounce = yes" in the main.cf file to prevent +the Postfix SMTP server from rejecting mail permanently, by changing +all 5xx SMTP reply codes into 4xx.

+ +
warn_if_reject

When placed before a reject-type +restriction, access table query, or check_policy_service query, +this logs a "reject_warning" message instead of rejecting a request +(when a reject-type restriction fails due to a temporary error, +this logs a "reject_warning" message for any implicit "defer_if_permit" +actions that would normally prevent mail from being accepted by +some later access restriction). This feature has no effect on +defer_if_reject restrictions.

+ +
XCLIENT

With this feature, an authorized SMTP +client can impersonate other systems and perform realistic SMTP +access rule tests. Examples of how to impersonate other systems +for access rule testing are given at the end of the XCLIENT_README +document.
This feature is available in Postfix 2.1.

+
+ +
+ + + + diff --git a/proto/SMTPD_POLICY_README.html b/proto/SMTPD_POLICY_README.html new file mode 100644 index 0000000..99225ec --- /dev/null +++ b/proto/SMTPD_POLICY_README.html @@ -0,0 +1,811 @@ + + + + + + +Postfix SMTP Access Policy Delegation + + + + + + + +

Postfix SMTP Access Policy Delegation

+ +
+ +

Purpose of Postfix SMTP access policy delegation

+ +

The Postfix SMTP server has a number of built-in mechanisms to +block or accept mail at specific SMTP protocol stages. In addition, +the Postfix SMTP server can delegate decisions to an external policy +server (Postfix 2.1 and later).

+ +

With this policy delegation mechanism, a simple +greylist policy can be implemented with only a dozen lines of +Perl, as is shown at the end of this document. A complete example +can be found in the Postfix source code, in the directory +examples/smtpd-policy.

+ +

Another example of policy delegation is the SPF policy server +at http://www.openspf.org/Software.

+ +

Policy delegation is now the preferred method for adding policies +to Postfix. It's much easier to develop a new feature in few lines +of Perl, Python, Ruby, or TCL, than trying to do the same in C code. +The difference in +performance will be unnoticeable except in the most demanding +environments. On active systems a policy daemon process is used +multiple times, for up to $max_use incoming SMTP connections.

+ +

This document covers the following topics:

+ + + +

Protocol description

+ +

The Postfix policy delegation protocol is really simple. The client +sends a request and the server sends a response. Unless there was an +error, the server must not close the connection, so that the same +connection can be used multiple times.

+ +

The client request is a sequence of name=value attributes separated +by newline, and is terminated by an empty line. The server reply is one +name=value attribute and it, too, is terminated by an empty line.

+ +

Here is an example of all the attributes that the Postfix SMTP +server sends in a delegated SMTPD access policy request:

+ +
+
+Postfix version 2.1 and later:
+request=smtpd_access_policy
+protocol_state=RCPT
+protocol_name=SMTP
+helo_name=some.domain.tld
+queue_id=8045F2AB23
+sender=foo@bar.tld
+recipient=bar@foo.tld
+recipient_count=0
+client_address=1.2.3.4
+client_name=another.domain.tld
+reverse_client_name=another.domain.tld
+instance=123.456.7
+Postfix version 2.2 and later:
+sasl_method=plain
+sasl_username=you
+sasl_sender=
+size=12345
+ccert_subject=solaris9.porcupine.org
+ccert_issuer=Wietse+20Venema
+ccert_fingerprint=C2:9D:F4:87:71:73:73:D9:18:E7:C2:F3:C1:DA:6E:04
+Postfix version 2.3 and later:
+encryption_protocol=TLSv1/SSLv3
+encryption_cipher=DHE-RSA-AES256-SHA
+encryption_keysize=256
+etrn_domain=
+Postfix version 2.5 and later:
+stress=
+Postfix version 2.9 and later:
+ccert_pubkey_fingerprint=68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40
+Postfix version 3.0 and later:
+client_port=1234
+Postfix version 3.1 and later:
+policy_context=submission
+Postfix version 3.2 and later:
+server_address=10.3.2.1
+server_port=54321
+[empty line]
+
+
+ +

Notes:

+ + + +

The following is specific to SMTPD delegated policy requests: +

+ + + +

The policy server replies with any action that is allowed in a +Postfix SMTPD access(5) table. Example:

+ +
+
+action=defer_if_permit Service temporarily unavailable
+[empty line]
+
+
+ +

This causes the Postfix SMTP server to reject the request with +a 450 temporary error code and with text "Service temporarily +unavailable", if the Postfix SMTP server finds no reason to reject +the request permanently.

+ +

In case of trouble the policy server must not send a reply. +Instead the server must log a warning and disconnect. Postfix will +retry the request at some later time.

+ +

Simple policy client/server configuration

+ +

The Postfix delegated policy client can connect to a TCP socket +or to a UNIX-domain socket. Examples:

+ +
+
+inet:127.0.0.1:9998
+unix:/some/where/policy
+unix:private/policy
+
+
+ +

The first example specifies that the policy server listens on +a TCP socket at 127.0.0.1 port 9998. The second example specifies +an absolute pathname of a UNIX-domain socket. The third example +specifies a pathname relative to the Postfix queue directory; use +this for policy servers that are spawned by the Postfix master +daemon.

+ +

To create a policy service that listens on a UNIX-domain socket +called "policy", and that runs under control of the Postfix spawn(8) +daemon, you would use something like this:

+ +
+
+ 1 /etc/postfix/master.cf:
+ 2     policy  unix  -       n       n       -       0       spawn
+ 3       user=nobody argv=/some/where/policy-server
+ 4 
+ 5 /etc/postfix/main.cf:
+ 6     smtpd_recipient_restrictions =
+ 7         ... 
+ 8         reject_unauth_destination 
+ 9         check_policy_service unix:private/policy 
+10         ...
+11     policy_time_limit = 3600
+12     # smtpd_policy_service_request_limit = 1
+
+
+ +

NOTES:

+ + + +
+
+ 1 /etc/postfix/master.cf:
+ 2     127.0.0.1:9998  inet  n       n       n       -       0       spawn
+ 3       user=nobody argv=/some/where/policy-server
+ 4 
+ 5 /etc/postfix/main.cf:
+ 6     smtpd_recipient_restrictions =
+ 7         ... 
+ 8         reject_unauth_destination 
+ 9         check_policy_service inet:127.0.0.1:9998
+10         ...
+11     127.0.0.1:9998_time_limit = 3600
+12     # smtpd_policy_service_request_limit = 1
+
+
+ +

Configuration parameters that control the client side of the +policy delegation protocol:

+ + + +

Configuration parameters that control the server side of the +policy delegation protocol:

+ + + +

Advanced policy client configuration

+ +

The previous section lists a number of Postfix main.cf parameters +that control time limits and other settings for all policy clients. +This is sufficient for simple configurations. With more complex +configurations it becomes desirable to have different settings per +policy client. This is supported with Postfix 3.0 and later.

+ +

The following example shows a "non-critical" policy service +with a short timeout, and with "DUNNO" as default action when the +service is unvailable. The "DUNNO" action causes Postfix to ignore +the result.

+ +
+
+1 /etc/postfix/main.cf:
+2     mua_recipient_restrictions = 
+3         ...
+4         reject_unauth_destination
+5         check_policy_service { inet:host:port, 
+6             timeout=10s, default_action=DUNNO
+7             policy_context=submission }
+8         ...
+
+
+ +

Instead of a server endpoint, we now have a list enclosed in {}.

+ + + +

Inside the list, syntax is similar to what we already know from +main.cf: items separated by space or comma. There is one difference: +you must enclose a setting in parentheses, as in "{ name = value +}", if you want to have space or comma within a value or around +"=". This comes in handy when different policy servers require +different default actions with different SMTP status codes or text: +

+ +
+
+1 /etc/postfix/main.cf:
+2     smtpd_recipient_restrictions = 
+3         ...
+4         reject_unauth_destination
+5         check_policy_service {
+6           inet:host:port1, 
+7           { default_action = 451 4.3.5 See http://www.example.com/support1 }
+8         } 
+9         ...
+
+
+ +

Example: greylist policy server

+ +

Greylisting is a defense against junk email that is described at +http://www.greylisting.org/. The idea was discussed on the +postfix-users mailing list +one year before it was popularized.

+ +

The file examples/smtpd-policy/greylist.pl in the Postfix source +tree implements a simplified greylist policy server. This server +stores a time stamp for every (client, sender, recipient) triple. +By default, mail is not accepted until a time stamp is more than +60 seconds old. This stops junk mail with randomly selected sender +addresses, and mail that is sent through randomly selected open +proxies. It also stops junk mail from spammers that change their +IP address frequently.

+ +

Copy examples/smtpd-policy/greylist.pl to /usr/libexec/postfix +or whatever location is appropriate for your system.

+ +

In the greylist.pl Perl script you need to specify the +location of the greylist database file, and how long mail will +be delayed before it is accepted. The default settings are: +

+ +
+
+$database_name="/var/mta/greylist.db";
+$greylist_delay=60;
+
+
+ +

The /var/mta directory (or whatever you choose) should be +writable by "nobody", or by whatever username you configure below +in master.cf for the policy service.

+ +

Example:

+ +
+
+# mkdir /var/mta
+# chown nobody /var/mta
+
+
+ +

Note: DO NOT create the greylist database in a world-writable +directory such as /tmp or /var/tmp, and DO NOT create the greylist +database in a file system that may run out of space. Postfix can +survive "out of space" conditions with the mail queue and with the +mailbox store, but it cannot survive a corrupted greylist database. +If the file becomes corrupted you may not be able to receive mail +at all until you delete the file by hand.

+ +

The greylist.pl Perl script can be run under control by +the Postfix master daemon. For example, to run the script as user +"nobody", using a UNIX-domain socket that is accessible by Postfix +processes only:

+ +
+
+ 1 /etc/postfix/master.cf:
+ 2     greylist  unix  -       n       n       -       0       spawn
+ 3       user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
+ 4 
+ 5 /etc/postfix/main.cf:
+ 6     greylist_time_limit = 3600
+ 7     smtpd_recipient_restrictions =
+ 8         ... 
+ 9         reject_unauth_destination 
+10         check_policy_service unix:private/greylist
+11         ...
+12     # smtpd_policy_service_request_limit = 1
+
+
+ +

Notes:

+ + + +

With Solaris < 9, or Postfix < 2.10 on any Solaris +version, use inet: style sockets instead of unix: +style, as detailed in the "Policy +client/server configuration" section above.

+ +
+
+ 1 /etc/postfix/master.cf:
+ 2     127.0.0.1:9998  inet  n       n       n       -       0       spawn
+ 3       user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
+ 4 
+ 5 /etc/postfix/main.cf:
+ 6     127.0.0.1:9998_time_limit = 3600
+ 7     smtpd_recipient_restrictions =
+ 8         ... 
+ 9         reject_unauth_destination 
+10         check_policy_service inet:127.0.0.1:9998
+11         ...
+12     # smtpd_policy_service_request_limit = 1
+
+
+ +

Greylisting mail from frequently forged domains

+ +

It is relatively safe to turn on greylisting for specific +domains that often appear in forged email. At some point +in cyberspace/time a list of frequently +forged MAIL FROM domains could be found at +http://www.monkeys.com/anti-spam/filtering/sender-domain-validate.in. + +

+
+ 1 /etc/postfix/main.cf:
+ 2     smtpd_recipient_restrictions =
+ 3         reject_unlisted_recipient
+ 4         ...
+ 5         reject_unauth_destination 
+ 6         check_sender_access hash:/etc/postfix/sender_access
+ 7         ...
+ 8     smtpd_restriction_classes = greylist
+ 9     greylist = check_policy_service unix:private/greylist
+10 
+11 /etc/postfix/sender_access:
+12     aol.com     greylist
+13     hotmail.com greylist
+14     bigfoot.com greylist
+15     ... etcetera ...
+
+
+ +

NOTES:

+ + + +

Greylisting all your mail

+ +

If you turn on greylisting for all mail you may want to make +exceptions for mailing lists that use one-time sender addresses, +because each message will be delayed due to greylisting, and the +one-time sender addresses can pollute your greylist database +relatively quickly. Instead of making exceptions, you can automatically +whitelist clients that survive greylisting repeatedly; this avoids +most of the delays and most of the database pollution problem.

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     smtpd_recipient_restrictions =
+ 3         reject_unlisted_recipient
+ 4         ...
+ 5         reject_unauth_destination 
+ 6         check_sender_access hash:/etc/postfix/sender_access
+ 7         check_policy_service unix:private/policy
+ 8         ...
+ 9 
+10 /etc/postfix/sender_access:
+11     securityfocus.com OK
+12     ...
+
+
+ +

NOTES:

+ + + +

Routine greylist maintenance

+ +

The greylist database grows over time, because the greylist server +never removes database entries. If left unattended, the greylist +database will eventually run your file system out of space.

+ +

When the status file size exceeds some threshold you can simply +rename or remove the file without adverse effects; Postfix +automatically creates a new file. In the worst case, new mail will +be delayed by an hour or so. To lessen the impact, rename or remove +the file in the middle of the night at the beginning of a weekend. +

+ +

Example Perl greylist server

+ +

This is the Perl subroutine that implements the example greylist +policy. It is part of a general purpose sample policy server that +is distributed with the Postfix source as +examples/smtpd-policy/greylist.pl.

+ +
+#
+# greylist status database and greylist time interval. DO NOT create the
+# greylist status database in a world-writable directory such as /tmp
+# or /var/tmp. DO NOT create the greylist database in a file system
+# that can run out of space.
+#
+$database_name="/var/mta/greylist.db";
+$greylist_delay=60;
+
+#
+# Auto-whitelist threshold. Specify 0 to disable, or the number of
+# successful "come backs" after which a client is no longer subject
+# to greylisting.
+#
+$auto_whitelist_threshold = 10;
+
+#
+# Demo SMTPD access policy routine. The result is an action just like
+# it would be specified on the right-hand side of a Postfix access
+# table.  Request attributes are available via the %attr hash.
+#
+sub smtpd_access_policy {
+    my($key, $time_stamp, $now);
+
+    # Open the database on the fly.
+    open_database() unless $database_obj;
+
+    # Search the auto-whitelist.
+    if ($auto_whitelist_threshold > 0) {
+        $count = read_database($attr{"client_address"});
+        if ($count > $auto_whitelist_threshold) {
+            return "dunno";
+        }
+    }
+
+    # Lookup the time stamp for this client/sender/recipient.
+    $key =
+        lc $attr{"client_address"}."/".$attr{"sender"}."/".$attr{"recipient"};
+    $time_stamp = read_database($key);
+    $now = time();
+
+    # If new request, add this client/sender/recipient to the database.
+    if ($time_stamp == 0) {
+        $time_stamp = $now;
+        update_database($key, $time_stamp);
+    }
+
+    # The result can be any action that is allowed in a Postfix access(5) map.
+    #
+    # To label the mail, return ``PREPEND headername: headertext''
+    #
+    # In case of success, return ``DUNNO'' instead of ``OK'', so that the
+    # check_policy_service restriction can be followed by other restrictions.
+    #
+    # In case of failure, return ``DEFER_IF_PERMIT optional text...'',
+    # so that mail can still be blocked by other access restrictions.
+    #
+    syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
+    if ($now - $time_stamp > $greylist_delay) {
+        # Update the auto-whitelist.
+        if ($auto_whitelist_threshold > 0) {
+            update_database($attr{"client_address"}, $count + 1);
+        }
+        return "dunno";
+    } else {
+        return "defer_if_permit Service temporarily unavailable";
+    }
+}
+
+ + + + diff --git a/proto/SMTPD_PROXY_README.html b/proto/SMTPD_PROXY_README.html new file mode 100644 index 0000000..0b57807 --- /dev/null +++ b/proto/SMTPD_PROXY_README.html @@ -0,0 +1,411 @@ + + + + + + +Postfix Before-Queue Content Filter + + + + + + + +

Postfix Before-Queue Content Filter

+ +
+ +

WARNING

+ +

The before-queue content filtering feature described in this +document limits the amount of mail that a site can handle. See the +"Pros and Cons" section below for details. +

+ +

The Postfix before-queue content filter feature

+ +

As of version 2.1, the Postfix SMTP server can forward all +incoming mail to a content filtering proxy server that inspects all +mail BEFORE it is stored in the Postfix mail queue. It is roughly +equivalent in capabilities to the approach described in MILTER_README, +except that the latter uses a dedicated protocol instead of SMTP. + +

The before-queue content filter is meant to be used as follows:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet -> Postfix SMTP server + -> Before queue filter -> Postfix SMTP server + -> Postfix cleanup + server -> Postfix queue -< smtp
local
virtual
+ +
+ +

The before-queue content filter is not to be confused with the +approach described in the FILTER_README document, where mail is +filtered AFTER it is stored in the Postfix mail queue.

+ +

This document describes the following topics:

+ + + +

Principles of operation

+ +

As shown in the diagram above, the before-queue filter sits +between two Postfix SMTP server processes.

+ + + +

The before-queue content filter described here works just like +the after-queue content filter described in the FILTER_README +document. In many cases you can use the same software, within the +limitations as discussed in the "Pros and +Cons" section below.

+ +

Pros and cons of before-queue content +filtering

+ + + +

Configuring the Postfix SMTP pass-through +proxy feature

+ +

In the following example, the before-filter Postfix SMTP server +gives mail to a content filter that listens on localhost port 10025. +The after-filter Postfix SMTP server receives mail from the content +filter via localhost port 10026. From then on mail is processed as +usual.

+ +

The content filter itself is not described here. You can use +any filter that is SMTP enabled. For non-SMTP capable content +filtering software, Bennett Todd's SMTP proxy implements a nice +Perl-based framework. See: http://bent.latency.net/smtpprox/ or +https://github.com/jnorell/smtpprox.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet -> Postfix SMTP server on + port 25 -> filter on localhost port 10025 -> Postfix SMTP server on + localhost port 10026 -> Postfix cleanup + server -> Postfix incoming queue
+ +
+ +

This is configured by editing the master.cf file:

+ +
+
+/etc/postfix/master.cf:
+    # =============================================================
+    # service type  private unpriv  chroot  wakeup  maxproc command
+    #               (yes)   (yes)   (yes)   (never) (100)
+    # =============================================================
+    #
+    # Before-filter SMTP server. Receive mail from the network and
+    # pass it to the content filter on localhost port 10025.
+    #
+    smtp      inet  n       -       n       -       20      smtpd
+        -o smtpd_proxy_filter=127.0.0.1:10025
+        -o smtpd_client_connection_count_limit=10
+        # Postfix 2.7 and later performance feature.
+        # -o smtpd_proxy_options=speed_adjust
+    #
+    # After-filter SMTP server. Receive mail from the content filter
+    # on localhost port 10026.
+    #
+    127.0.0.1:10026 inet n  -       n       -        -      smtpd
+        -o smtpd_authorized_xforward_hosts=127.0.0.0/8
+        -o smtpd_client_restrictions=
+        -o smtpd_helo_restrictions=
+        -o smtpd_sender_restrictions=
+        # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+        -o smtpd_relay_restrictions=
+        -o smtpd_recipient_restrictions=permit_mynetworks,reject
+        -o smtpd_data_restrictions=
+        -o mynetworks=127.0.0.0/8
+        -o receive_override_options=no_unknown_recipient_checks
+
+
+ +

Note: do not specify spaces around the "=" or "," characters.

+ +

The before-filter SMTP server entry is a modified version of the +default Postfix SMTP server entry that is normally configured at +the top of the master.cf file:

+ + + +

The after-filter SMTP server is a new master.cf entry:

+ + + +

By default, the filter has 100 seconds to do its work. If it +takes longer then Postfix gives up and reports an error to the +remote SMTP client. You can increase this time limit (see configuration +parameter section below) but doing so is pointless because you +can't control when the remote SMTP client times out.

+ +

Configuration parameters

+ +

Parameters that control proxying:

+ + + +

How Postfix talks to the before-queue content +filter

+ +

The before-filter Postfix SMTP server connects to the content +filter, delivers one message, and disconnects. While sending mail +into the content filter, Postfix speaks ESMTP but uses no command +pipelining. Postfix generates its own EHLO, XFORWARD (for logging +the remote client IP address instead of localhost[127.0.0.1]), DATA +and QUIT commands, and forwards unmodified copies of all the MAIL +FROM and RCPT TO commands that the before-filter Postfix SMTP server +didn't reject itself. +Postfix sends no other SMTP commands.

+ +

The content filter should accept the same MAIL FROM and RCPT +TO command syntax as the before-filter Postfix SMTP server, and +should forward the commands without modification to the after-filter +SMTP server. If the content filter or after-filter SMTP server +does not support all the ESMTP features that the before-filter +Postfix SMTP server supports, then the missing features must be +turned off in the before-filter Postfix SMTP server with the +smtpd_discard_ehlo_keywords parameter.

+ +

When the filter rejects content, it should send a negative SMTP +response back to the before-filter Postfix SMTP server, and it +should abort the connection with the after-filter Postfix SMTP +server without completing the SMTP conversation with the after-filter +Postfix SMTP server.

+ + + + diff --git a/proto/SMTPUTF8_README.html b/proto/SMTPUTF8_README.html new file mode 100644 index 0000000..9389297 --- /dev/null +++ b/proto/SMTPUTF8_README.html @@ -0,0 +1,399 @@ + + + + + + +Postfix SMTPUTF8 support + + + + + + + +

+Postfix SMTPUTF8 support +

+ +
+ +

Overview

+ +

This document describes Postfix support for Email Address +Internationalization (EAI) as defined in RFC 6531 (SMTPUTF8 extension), +RFC 6532 (Internationalized email headers) and RFC 6533 (Internationalized +delivery status notifications). Introduced with Postfix version +3.0, this fully supports UTF-8 email addresses and UTF-8 message +header values.

+ +

Topics covered in this document:

+ + + +

Building Postfix with/without SMTPUTF8 support

+ +

Postfix will build with SMTPUTF8 support if the ICU version +≥ 46 library and header files are installed on the system. The +package name varies with the OS distribution. The table shows package +names for a number of platforms at the time this text was written. +

+ +
+ + + + + + + + + + + +
OS Distribution Package
FreeBSD, NetBSD, etc. icu
Centos, Fedora, RHEL libicu-devel
Debian, Ubuntu libicu-dev
+ +
+ +

To force Postfix to build without SMTPUTF8, specify:

+ +
+
+$ make makefiles CCARGS="-DNO_EAI ..."
+
+
+ +

See the INSTALL document for more "make makefiles" options.

+ +

Enabling Postfix SMTPUTF8 support

+ +

There is more to SMTPUTF8 than just Postfix itself. The rest +of your email infrastructure also needs to be able to handle UTF-8 +email addresses and message header values. This includes SMTPUTF8 +protocol support in SMTP-based content filters (Amavisd), LMTP +servers (Dovecot), and down-stream SMTP servers.

+ +

Postfix SMTPUTF8 support is enabled by default, but it may be +disabled as part of a backwards-compatibility safety net (see the +COMPATIBILITY_README file).

+ +

SMTPUTF8 support is enabled by setting the smtputf8_enable +parameter in main.cf:

+ +
+
+# postconf "smtputf8_enable = yes"
+# postfix reload
+
+
+ +

(With Postfix ≤ 3.1, you may also need to specify "option_group += client" in Postfix MySQL client files, to enable UTF8 support +in MySQL queries. This setting is the default as of Postfix 3.2.)

+ +

With SMTPUTF8 support enabled, Postfix changes behavior with +respect to earlier Postfix releases:

+ + + +

Postfix already permitted UTF-8 in message header values +and in address localparts. This does not change.

+ +

Using Postfix SMTPUTF8 support

+ +

After Postfix SMTPUTF8 support is turned on, Postfix behavior +will depend on 1) whether a remote SMTP client requests SMTPUTF8 +support, 2) the presence of UTF-8 content in the message envelope +and headers, and 3) whether a down-stream SMTP (or LMTP) server +announces SMTPUTF8 support.

+ + + +

SMTPUTF8 autodetection

+ +

This section applies only to systems that have SMTPUTF8 support +turned on (smtputf8_enable = yes).

+ +

For compatibility with pre-SMTPUTF8 environments, Postfix does +not automatically set the "SMTPUTF8 requested" flag on messages +from non-SMTPUTF8 clients that contain an UTF-8 header value or +UTF-8 address localpart. This would make such messages undeliverable +to non-SMTPUTF8 servers, and could be a barrier to SMTPUTF8 adoption. +

+ +

By default, Postfix sets the "SMTPUTF8 requested" flag only on +address verification probes and on Postfix sendmail submissions +that contain UTF-8 in the sender address, UTF-8 in a recipient +address, or UTF-8 in a message header value.

+ +
+
+/etc/postfix/main.cf:
+    smtputf8_autodetect_classes = sendmail, verify
+
+
+ +

However, if you have a non-ASCII myorigin or mydomain setting, +or if you have a configuration that introduces UTF-8 addresses with +virtual aliases, canonical mappings, or BCC mappings, then you may +have to apply SMTPUTF8 autodetection to all email:

+ +
+
+/etc/postfix/main.cf:
+    smtputf8_autodetect_classes = all
+
+
+ +

This will, of course, also flag email that was received without +SMTPUTF8 request, but that contains UTF-8 in a sender address +localpart, receiver address localpart, or message header value. +Such email was not standards-compliant, but Postfix would have +delivered it if SMTPUTF8 support was disabled.

+ +

Limitations of the current implementation +

+ +

The Postfix implementation is a work in progress; limitations +are steadily being removed. The text below describes the situation +at one point in time.

+ +

No automatic conversions between ASCII and UTF-8 domain names.

+ +

Some background: According to RFC 6530 and related documents, +an internationalized domain name can appear in two forms: the UTF-8 +form, and the ASCII (xn--mumble) form. An internationalized address +localpart must be encoded in UTF-8; the RFCs do not define an ASCII +alternative form.

+ +

Postfix currently does not convert internationalized domain +names from UTF-8 into ASCII (or from ASCII into UTF-8) before using +domain names in SMTP commands and responses, before looking up +domain names in lists such as mydestination, relay_domains or in +lookup tables such as access tables, etc., before using domain names +in a policy daemon or Milter request, or before logging events. +

+ +

Postfix does, however, casefold domain names and email addresses +before matching them against a Postfix configuration parameter or +lookup table.

+ +

In order to use Postfix SMTPUTF8 support:

+ + + +

Compatibility with pre-SMTPUTF8 +environments

+ +

Mailing lists with UTF-8 and non-UTF-8 subscribers

+ +

With Postfix, there is no need to split mailing lists into UTF-8 and +non-UTF-8 members. Postfix will try to deliver the non-UTF8 subscribers +over "traditional" non-SMTPUTF8 sessions, as long as the message +has an ASCII envelope sender address and all-ASCII header values. +The mailing list manager may have to apply RFC 2047 encoding to +satisfy that last condition.

+ +

Pre-existing non-ASCII email flows

+ +

With "smtputf8_enable = no", Postfix handles email with non-ASCII +in address localparts (and in headers) as before. The vast majority +of email software is perfectly capable of handling such email, even +if pre-SMTPUTF8 standards do not support such practice.

+ +

Rejecting non-UTF8 addresses

+ +

With "smtputf8_enable = yes", Postfix +requires that non-ASCII address information is encoded in UTF-8 and +will reject other encodings such as ISO-8859. It is not practical +for Postfix to support multiple encodings at the same time. There +is no problem with RFC 2047 encodings such as "=?ISO-8859-1?Q?text?=", +because those use only characters from the ASCII characterset.

+ +

Rejecting non-ASCII addresses in non-SMTPUTF8 transactions

+ +

Setting "strict_smtputf8 = yes" in addition to "smtputf8_enable += yes" will enable stricter enforcement of the SMTPUTF8 protocol. +Specifically, the Postfix SMTP server will not only reject non-UTF8 +sender or recipient addresses, it will in addition accept UTF-8 +sender or recipient addresses only when the client requests an +SMTPUTF8 mail transaction.

+ +

Compatibility with IDNA2003

+ +

Postfix ≥ 3.2 by default disables the 'transitional' +compatibility between IDNA2003 and IDNA2008, when converting UTF-8 +domain names to/from the ASCII form that is used in DNS lookups. +This makes Postfix behavior consistent with current versions of the +Firefox and Chrome web browsers. Specify "enable_idna2003_compatibility += yes" to get the historical behavior.

+ +

This affects the conversion of domain names that contain for +example the German sz (ß) and the Greek zeta (ς). See +http://unicode.org/cldr/utility/idna.jsp for more examples.

+ +

Credits

+ + + + + + + diff --git a/proto/SQLITE_README.html b/proto/SQLITE_README.html new file mode 100644 index 0000000..2cd36ad --- /dev/null +++ b/proto/SQLITE_README.html @@ -0,0 +1,116 @@ + + + + + + +Postfix SQLite Howto + + + + + + + +

Postfix SQLite Howto

+ +
+ +

Introduction

+ +

The Postfix sqlite map type allows you to hook up Postfix to a +SQLite database. This implementation allows for multiple sqlite +databases: you can use one for a virtual(5) table, one for an +access(5) table, and one for an aliases(5) table if you want.

+ +

Building Postfix with SQLite support

+ +

The Postfix SQLite client utilizes the sqlite3 library, +which can be obtained from:

+ +
+

http://www.sqlite.org/

+
+ +

In order to build Postfix with sqlite map support, you will +need to add to CCARGS the flags -DHAS_SQLITE and -I with the directory +containing the sqlite header files, and you will need to add to +AUXLIBS the directory and name of the sqlite3 library, plus the +name of the standard POSIX thread library (pthread). For example: +

+ +
+
+make -f Makefile.init makefiles \
+     'CCARGS=-DHAS_SQLITE -I/usr/local/include' \
+     'AUXLIBS_SQLITE=-L/usr/local/lib -lsqlite3 -lpthread'
+
+
+ +

Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_SQLITE. +With Postfix 3.0 and later, the old AUXLIBS variable still supports +building a statically-loaded SQLite database client, but only the new +AUXLIBS_SQLITE variable supports building a dynamically-loaded or +statically-loaded SQLite database client.

+ +
+ +

Failure to use the AUXLIBS_SQLITE variable will defeat the purpose +of dynamic database client loading. Every Postfix executable file +will have SQLITE database library dependencies. And that was exactly +what dynamic database client loading was meant to avoid.

+ +
+ +

Then, just run 'make'.

+ +

Using SQLite tables

+ +

Once Postfix is built with sqlite support, you can specify a +map type in main.cf like this:

+ +
+
+alias_maps = sqlite:/etc/postfix/sqlite-aliases.cf
+
+
+ +

The file /etc/postfix/sqlite-aliases.cf specifies lots of +information telling Postfix how to reference the sqlite database. +For a complete description, see the sqlite_table(5) manual page.

+ +

Example: local aliases

+ +
+#
+# sqlite config file for local(8) aliases(5) lookups
+#
+
+# Path to database 
+dbpath = /some/path/to/sqlite_database
+
+# See sqlite_table(5) for details.
+query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
+
+ +

Additional notes

+ +

The SQLite configuration interface setup allows for multiple +sqlite databases: you can use one for a virtual table, one for an +access table, and one for an aliases table if you want.

+ +

Credits

+ +

SQLite support was added with Postfix version 2.8.

+ + + + + + diff --git a/proto/STANDARD_CONFIGURATION_README.html b/proto/STANDARD_CONFIGURATION_README.html new file mode 100644 index 0000000..4fbea57 --- /dev/null +++ b/proto/STANDARD_CONFIGURATION_README.html @@ -0,0 +1,851 @@ + + + + + + +Postfix Standard Configuration Examples + + + + + + + +

Postfix Standard Configuration Examples

+ +
+ +

Purpose of this document

+ +

This document presents a number of typical Postfix configurations. +This document should be reviewed after you have followed the basic +configuration steps as described in the BASIC_CONFIGURATION_README +document. In particular, do not proceed here if you don't already +have Postfix working for local mail submission and for local mail +delivery.

+ +

The first part of this document presents standard configurations +that each solve one specific problem.

+ + + +

The second part of this document presents additional configurations +for hosts in specific environments.

+ + + +

Postfix on a stand-alone Internet host

+ +

Postfix should work out of the box without change on a stand-alone +machine that has direct Internet access. At least, that is how +Postfix installs when you download the Postfix source code via +http://www.postfix.org/.

+ +

You can use the command "postconf -n" to find out what +settings are overruled by your main.cf. Besides a few pathname +settings, few parameters should be set on a stand-alone box, beyond +what is covered in the BASIC_CONFIGURATION_README document:

+ +
+
+/etc/postfix/main.cf:
+    # Optional: send mail as user@domainname instead of user@hostname.
+    #myorigin = $mydomain
+
+    # Optional: specify NAT/proxy external address.
+    #proxy_interfaces = 1.2.3.4
+
+    # Alternative 1: don't relay mail from other hosts.
+    mynetworks_style = host
+    relay_domains =
+
+    # Alternative 2: relay mail from local clients only.
+    # mynetworks = 192.168.1.0/28
+    # relay_domains =
+
+
+ +

See also the section "Postfix on hosts without +a real Internet hostname" if this is applicable to your configuration. +

+ +

Postfix on a null client

+ +

A null client is a machine that can only send mail. It receives no +mail from the network, and it does not deliver any mail locally. A +null client typically uses POP, IMAP or NFS for mailbox access.

+ +

In this example we assume that the Internet domain name is +"example.com" and that the machine is named "hostname.example.com". +As usual, the examples show only parameters that are not left at +their default settings.

+ +
+
+1 /etc/postfix/main.cf:
+2     myhostname = hostname.example.com
+3     myorigin = $mydomain
+4     relayhost = $mydomain
+5     inet_interfaces = loopback-only
+6     mydestination =
+
+
+ +

Translation:

+ + + +

Postfix on a local network

+ +

This section describes a local area network environment of one +main server and multiple other systems that send and receive email. +As usual we assume that the Internet domain name is "example.com". +All systems are configured to send mail as "user@example.com", and +all systems receive mail for "user@hostname.example.com". The main +server also receives mail for "user@example.com". We call this +machine by the name of mailhost.example.com.

+ +

A drawback of sending mail as "user@example.com" is that mail +for "root" and other system accounts is also sent to the central +mailhost. See the section "Delivering some +but not all accounts locally" below for possible solutions. +

+ +

As usual, the examples show only parameters that are not left +at their default settings.

+ +

First we present the non-mailhost configuration, because it is +the simpler one. This machine sends mail as "user@example.com" and +is final destination for "user@hostname.example.com".

+ +
+
+1 /etc/postfix/main.cf:
+2     myorigin = $mydomain
+3     mynetworks = 127.0.0.0/8 10.0.0.0/24
+4     relay_domains =
+5     # Optional: forward all non-local mail to mailhost
+6     #relayhost = $mydomain
+
+
+ +

Translation:

+ + + +

Next we present the mailhost configuration. This machine sends +mail as "user@example.com" and is final destination for +"user@hostname.example.com" as well as "user@example.com".

+ +
+
+ 1 DNS:
+ 2     example.com    IN    MX  10 mailhost.example.com.
+ 3 
+ 4 /etc/postfix/main.cf:
+ 5     myorigin = $mydomain
+ 6     mydestination = $myhostname localhost.$mydomain localhost $mydomain
+ 7     mynetworks = 127.0.0.0/8 10.0.0.0/24
+ 8     relay_domains =
+ 9     # Optional: forward all non-local mail to firewall
+10     #relayhost = [firewall.example.com]
+
+
+ +

Translation:

+ + + +

In an environment like this, users access their mailbox in one +or more of the following ways: + +

+ +

In the latter case, each user has an alias on the mailhost that +forwards mail to her preferred machine:

+ +
+
+/etc/aliases:
+    joe:    joe@joes.preferred.machine
+    jane:   jane@janes.preferred.machine
+
+
+ +

On some systems the alias database is not in /etc/aliases. To +find out the location for your system, execute the command "postconf +alias_maps".

+ +

Execute the command "newaliases" whenever you change +the aliases file.

+ +

Postfix email firewall/gateway

+ +

The idea is to set up a Postfix email firewall/gateway that +forwards mail for "example.com" to an inside gateway machine but +rejects mail for "anything.example.com". There is only one problem: +with "relay_domains = example.com", the firewall normally also +accepts mail for "anything.example.com". That would not be right. +

+ +

Note: this example requires Postfix version 2.0 and later. To find +out what Postfix version you have, execute the command "postconf +mail_version".

+ +

The solution is presented in multiple parts. This first part +gets rid of local mail delivery on the firewall, making the firewall +harder to break.

+ +
+
+1 /etc/postfix/main.cf:
+2     myorigin = example.com
+3     mydestination =
+4     local_recipient_maps =
+5     local_transport = error:local mail delivery is disabled
+6 
+7 /etc/postfix/master.cf:
+8     Comment out the local delivery agent
+
+
+ +

Translation:

+ + + +

For the sake of technical correctness the firewall must be able +to receive mail for postmaster@[firewall ip address]. Reportedly, +some things actually expect this ability to exist. The second part +of the solution therefore adds support for postmaster@[firewall ip +address], and as a bonus we do abuse@[firewall ip address] as well. +All the mail to these two accounts is forwarded to an inside address. +

+ +
+
+1 /etc/postfix/main.cf:
+2     virtual_alias_maps = hash:/etc/postfix/virtual
+3 
+4 /etc/postfix/virtual:
+5     postmaster      postmaster@example.com
+6     abuse           abuse@example.com
+
+
+ +

Translation:

+ + + +

The last part of the solution does the email forwarding, which +is the real purpose of the firewall email function.

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     mynetworks = 127.0.0.0/8 12.34.56.0/24
+ 3     relay_domains = example.com
+ 4     parent_domain_matches_subdomains = 
+ 5         debug_peer_list smtpd_access_maps
+

+ 6a    # Postfix 2.10 and later support separate relay control and
+ 7a    # spam control.
+ 8a    smtpd_relay_restrictions =
+ 9a        permit_mynetworks reject_unauth_destination
+10a    smtpd_recipient_restrictions = ...spam blocking rules....
+

+ 6b    # Older configurations combine relay control and spam control. To
+ 7b    # use this with Postfix ≥ 2.10 specify "smtpd_relay_restrictions=".
+ 8b    smtpd_recipient_restrictions =
+ 9b        permit_mynetworks reject_unauth_destination
+10b        ...spam blocking rules....
+

+11     relay_recipient_maps = hash:/etc/postfix/relay_recipients
+12     transport_maps = hash:/etc/postfix/transport
+13 
+14 /etc/postfix/relay_recipients:
+15     user1@example.com   x
+16     user2@example.com   x
+17      . . .
+18 
+19 /etc/postfix/transport:
+20     example.com   smtp:[inside-gateway.example.com]
+
+
+ +

Translation:

+ + + +

Specify dbm instead of hash if your system uses +dbm files instead of db files. To find out what lookup +tables Postfix supports, use the command "postconf -m".

+ +

Execute the command "postmap /etc/postfix/relay_recipients" +whenever you change the relay_recipients table.

+ +

Execute the command "postmap /etc/postfix/transport" +whenever you change the transport table.

+ +

In some installations, there may be separate instances of Postfix +processing inbound and outbound mail on a multi-homed firewall. The +inbound Postfix instance has an SMTP server listening on the external +firewall interface, and the outbound Postfix instance has an SMTP server +listening on the internal interface. In such a configuration is it is +tempting to configure $inet_interfaces in each instance with just the +corresponding interface address.

+ +

In most cases, using inet_interfaces in this way will not work, +because as documented in the $inet_interfaces reference manual, the +smtp(8) delivery agent will also use the specified interface address +as the source address for outbound connections and will be unable to +reach hosts on "the other side" of the firewall. The symptoms are that +the firewall is unable to connect to hosts that are in fact up. See the +inet_interfaces parameter documentation for suggested work-arounds.

+ +

Delivering some but not all accounts +locally

+ +

A drawback of sending mail as "user@example.com" (instead of +"user@hostname.example.com") is that mail for "root" and other +system accounts is also sent to the central mailhost. In order to +deliver such accounts locally, you can set up virtual aliases as +follows:

+ +
+
+1 /etc/postfix/main.cf:
+2     virtual_alias_maps = hash:/etc/postfix/virtual
+3 
+4 /etc/postfix/virtual:
+5     root     root@localhost
+6     . . .
+
+
+ +

Translation:

+ + + +

Execute the command "postmap /etc/postfix/virtual" after +editing the file.

+ +

Running Postfix behind a firewall

+ +

The simplest way to set up Postfix on a host behind a firewalled +network is to send all mail to a gateway host, and to let that mail +host take care of internal and external forwarding. Examples of that +are shown in the local area network +section above. A more sophisticated approach is to send only external +mail to the gateway host, and to send intranet mail directly.

+ +

Note: this example requires Postfix version 2.0 and later. To find +out what Postfix version you have, execute the command "postconf +mail_version".

+ +

The following example presents additional configuration. You +need to combine this with basic configuration information as +discussed the first half of this document.

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     transport_maps = hash:/etc/postfix/transport
+ 3     relayhost =
+ 4     # Optional for a machine that isn't "always on"
+ 5     #fallback_relay = [gateway.example.com]
+ 6 
+ 7 /etc/postfix/transport:
+ 8     # Internal delivery.
+ 9     example.com      :
+10     .example.com     :
+11     # External delivery.
+12     *                smtp:[gateway.example.com]
+
+
+ +

Translation:

+ + + +

Specify dbm instead of hash if your system uses +dbm files instead of db files. To find out what lookup +tables Postfix supports, use the command "postconf -m".

+ +

Execute the command "postmap /etc/postfix/transport" whenever +you edit the transport table.

+ +

Configuring Postfix as primary or backup MX host for a remote site

+ +

This section presents additional configuration. You need to +combine this with basic configuration information as discussed the +first half of this document.

+ +

When your system is SECONDARY MX host for a remote site this +is all you need:

+ +
+
+ 1 DNS:
+ 2     the.backed-up.domain.tld        IN      MX 100 your.machine.tld.
+ 3 
+ 4 /etc/postfix/main.cf:
+ 5     relay_domains = . . . the.backed-up.domain.tld
+

+ 6a    # Postfix 2.10 and later support separate relay control and
+ 7a    # spam control.
+ 8a    smtpd_relay_restrictions =
+ 9a        permit_mynetworks reject_unauth_destination
+10a    smtpd_recipient_restrictions = ...spam blocking rules....
+

+ 6b    # Older configurations combine relay control and spam control. To
+ 7b    # use this with Postfix ≥ 2.10 specify "smtpd_relay_restrictions=".
+ 8b    smtpd_recipient_restrictions =
+ 9b        permit_mynetworks reject_unauth_destination
+10b        ...spam blocking rules....
+

+11     # You must specify your NAT/proxy external address.
+12     #proxy_interfaces = 1.2.3.4
+13 
+14     relay_recipient_maps = hash:/etc/postfix/relay_recipients
+15 
+16 /etc/postfix/relay_recipients:
+17     user1@the.backed-up.domain.tld   x
+18     user2@the.backed-up.domain.tld   x
+19      . . .
+
+
+ +

When your system is PRIMARY MX host for a remote site you +need the above, plus:

+ +
+
+20 /etc/postfix/main.cf:
+21     transport_maps = hash:/etc/postfix/transport
+22 
+23 /etc/postfix/transport:
+24     the.backed-up.domain.tld       relay:[their.mail.host.tld]
+
+
+ +

Important notes: + +

+ +

Specify dbm instead of hash if your system uses +dbm files instead of db files. To find out what lookup +tables Postfix supports, use the command "postconf -m".

+ +

Execute the command "postmap /etc/postfix/transport" +whenever you change the transport table.

+ +

NOTE for Postfix < 2.2: Do not use the fallback_relay feature +when relaying mail +for a backup or primary MX domain. Mail would loop between the +Postfix MX host and the fallback_relay host when the final destination +is unavailable.

+ + + +

These are default settings in Postfix version 2.2 and later. +

+ +

Postfix on a dialup machine

+ +

This section applies to dialup connections that are down most +of the time. For dialup connections that are up 24x7, see the local area network section above.

+ +

This section presents additional configuration. You need to +combine this with basic configuration information as discussed the +first half of this document.

+ +

If you do not have your own hostname and IP address (usually +with dialup, cable TV or DSL connections) then you should also +study the section on "Postfix on hosts without +a real Internet hostname".

+ + + +

Postfix on hosts without a real Internet +hostname

+ +

This section is for hosts that don't have their own Internet +hostname. Typically these are systems that get a dynamic IP address +via DHCP or via dialup. Postfix will let you send and receive mail +just fine between accounts on a machine with a fantasy name. However, +you cannot use a fantasy hostname in your email address when sending +mail into the Internet, because no-one would be able to reply to +your mail. In fact, more and more sites refuse mail addresses with +non-existent domain names.

+ +

Note: the following information is Postfix version dependent. +To find out what Postfix version you have, execute the command +"postconf mail_version".

+ +

Solution 1: Postfix version 2.2 and later

+ +

Postfix 2.2 uses the generic(5) address mapping to replace +local fantasy email addresses by valid Internet addresses. This +mapping happens ONLY when mail leaves the machine; not when you +send mail between users on the same machine.

+ +

The following example presents additional configuration. You +need to combine this with basic configuration information as +discussed the first half of this document.

+ +
+
+1 /etc/postfix/main.cf:
+2     smtp_generic_maps = hash:/etc/postfix/generic
+3 
+4 /etc/postfix/generic:
+5     his@localdomain.local             hisaccount@hisisp.example
+6     her@localdomain.local             heraccount@herisp.example
+7     @localdomain.local                hisaccount+local@hisisp.example
+
+
+ +

When mail is sent to a remote host via SMTP:

+ + + +

Specify dbm instead of hash if your system uses +dbm files instead of db files. To find out what lookup +tables Postfix supports, use the command "postconf -m".

+ +

Execute the command "postmap /etc/postfix/generic" +whenever you change the generic table.

+ +

Solution 2: Postfix version 2.1 and earlier

+ +

The solution with older Postfix systems is to use valid +Internet addresses where possible, and to let Postfix map valid +Internet addresses to local fantasy addresses. With this, you can +send mail to the Internet and to local fantasy addresses, including +mail to local fantasy addresses that don't have a valid Internet +address of their own.

+ +

The following example presents additional configuration. You +need to combine this with basic configuration information as +discussed the first half of this document.

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     myhostname = hostname.localdomain
+ 3     mydomain = localdomain
+ 4 
+ 5     canonical_maps = hash:/etc/postfix/canonical
+ 6 
+ 7     virtual_alias_maps = hash:/etc/postfix/virtual
+ 8 
+ 9 /etc/postfix/canonical:
+10     your-login-name    your-account@your-isp.com
+11 
+12 /etc/postfix/virtual:
+13     your-account@your-isp.com       your-login-name
+
+
+ +

Translation:

+ + + +

Specify dbm instead of hash if your system uses +dbm files instead of db files. To find out what lookup +tables Postfix supports, use the command "postconf -m".

+ +

Execute the command "postmap /etc/postfix/canonical" +whenever you change the canonical table.

+ +

Execute the command "postmap /etc/postfix/virtual" +whenever you change the virtual table.

+ + + + diff --git a/proto/STRESS_README.html b/proto/STRESS_README.html new file mode 100644 index 0000000..b5e3ccb --- /dev/null +++ b/proto/STRESS_README.html @@ -0,0 +1,566 @@ + + + + + + +Postfix Stress-Dependent Configuration + + + + + + + +

Postfix +Stress-Dependent Configuration

+ +
+ +

Overview

+ +

This document describes the symptoms of Postfix SMTP server +overload. It presents permanent main.cf changes to avoid overload +during normal operation, and temporary main.cf changes to cope with +an unexpected burst of mail. This document makes specific suggestions +for Postfix 2.5 and later which support stress-adaptive behavior, +and for earlier Postfix versions that don't.

+ +

Topics covered in this document:

+ + + +

Symptoms of Postfix SMTP server overload

+ +

Under normal conditions, the Postfix SMTP server responds +immediately when an SMTP client connects to it; the time to deliver +mail is noticeable only with large messages. Performance degrades +dramatically when the number of SMTP clients exceeds the number of +Postfix SMTP server processes. When an SMTP client connects while +all Postfix SMTP server processes are busy, the client must wait +until a server process becomes available.

+ +

SMTP server overload may be caused by a surge of legitimate +mail (example: a DNS registrar opens a new zone for registrations), +by mistake (mail explosion caused by a forwarding loop) or by malice +(worm outbreak, botnet, or other illegitimate activity).

+ +

Symptoms of Postfix SMTP server overload are:

+ + + +

Legitimate mail that doesn't get through during an episode of +Postfix SMTP server overload is not necessarily lost. It should +still arrive once the situation returns to normal, as long as the +overload condition is temporary.

+ +

Automatic stress-adaptive behavior

+ +

Postfix version 2.5 introduces automatic stress-adaptive behavior. +It works as follows. When a "public" network service such as the +SMTP server runs into an "all server ports are busy" condition, the +Postfix master(8) daemon logs a warning, restarts the service +(without interrupting existing network sessions), and runs the +service with "-o stress=yes" on the server process command line: +

+ +
+
+80821  ??  S      0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes
+
+
+ +

Normally, the Postfix master(8) daemon runs such a service with +"-o stress=" on the command line (i.e. with an empty parameter +value):

+ +
+
+83326  ??  S      0:00.28 smtpd -n smtp -t inet -u -c -o stress=
+
+
+ +

You won't see "-o stress" command-line parameters with services +that have local clients only. These include services internal to +Postfix such as the queue manager, and services that listen on a +loopback interface only, such as after-filter SMTP services.

+ +

The "stress" parameter value is the key to making main.cf +parameter settings stress adaptive. The following settings are the +default with Postfix 2.6 and later.

+ +
+
+1 smtpd_timeout = ${stress?{10}:{300}}s
+2 smtpd_hard_error_limit = ${stress?{1}:{20}}
+3 smtpd_junk_command_limit = ${stress?{1}:{100}}
+4 # Parameters added after Postfix 2.6:
+5 smtpd_per_record_deadline = ${stress?{yes}:{no}}
+6 smtpd_starttls_timeout = ${stress?{10}:{300}}s
+7 address_verify_poll_count = ${stress?{1}:{3}}
+
+
+ +

Postfix versions before 3.0 use the older form ${stress?x}${stress:y} +instead of the newer form ${stress?{x}:{y}}.

+ +

The syntax of ${name?{value}:{value}}, ${name?value} and +${name:value} is explained at the beginning of the postconf(5) +manual page.

+ +

Translation:

+ +

+ +

NOTE: Please keep in mind that the stress-adaptive feature is +a fairly desperate measure to keep some legitimate mail +flowing under overload conditions. If a site is reaching the SMTP +server process limit when there isn't an attack or bot flood +occurring, then either the process limit needs to be raised or more +hardware needs to be added.

+ +

Service more SMTP clients at the same time

+ +

This section and the ones that follow discuss permanent measures +against mail server overload.

+ +

One measure to avoid the "all server processes busy" condition +is to service more SMTP clients simultaneously. For this you need +to increase the number of Postfix SMTP server processes. This will +improve the +responsiveness for remote SMTP clients, as long as the server machine +has enough hardware and software resources to run the additional +processes, and as long as the file system can keep up with the +additional load.

+ + + +

Spend less time per SMTP client

+ +

When increasing the number of SMTP server processes is not +practical, you can improve Postfix server responsiveness by eliminating +delays. When Postfix spends less time per SMTP session, the same +number of SMTP server processes can service more clients in a given +amount of time.

+ + + +

Disconnect suspicious SMTP clients

+ +

Under conditions of overload you can improve Postfix SMTP server +responsiveness by hanging up on suspicious clients, so that other +clients get a chance to talk to Postfix.

+ + + +

More information about automatic stress-adaptive behavior is +in section "Automatic stress-adaptive behavior". +

+ +

Temporary measures for older Postfix releases

+ +

See the section "Automatic stress-adaptive +behavior" if you are running Postfix version 2.5 or later, or +if you have applied the source code patch for stress-adaptive +behavior from the mirrors listed at http://www.postfix.org/download.html. +

+ +

The following measures can be applied temporarily during overload. +They still allow most legitimate clients to connect and send +mail, but may affect some legitimate clients.

+ + + +
+
+1  /etc/postfix/main.cf:
+2      smtpd_timeout = 10
+3      smtpd_hard_error_limit = 1
+4      smtpd_junk_command_limit = 1
+
+
+ +

With these measures, no mail should be lost, as long +as these measures are used only temporarily. The next section of +this document introduces a way to automate this process.

+ +

Detecting support for stress-adaptive behavior

+ +

To find out if your Postfix installation supports stress-adaptive +behavior, use the "ps" command, and look for the smtpd processes. +Postfix has stress-adaptive support when you see "-o stress=" or +"-o stress=yes" command-line options. Remember that Postfix never +enables stress-adaptive behavior on servers that listen on local +addresses only.

+ +

The following example is for FreeBSD or Linux. On Solaris, HP-UX +and other System-V flavors, use "ps -ef" instead of "ps ax".

+ +
+
+$ ps ax|grep smtpd
+83326  ??  S      0:00.28 smtpd -n smtp -t inet -u -c -o stress=
+84345  ??  Ss     0:00.11 /usr/bin/perl /usr/libexec/postfix/smtpd-policy.pl
+
+
+ +

You can't use postconf(1) to detect stress-adaptive support. +The postconf(1) command ignores the existence of the stress parameter +in main.cf, because the parameter has no effect there. Command-line +"-o parameter" settings always take precedence over main.cf parameter +settings.

+ +

If you configure stress-adaptive behavior in main.cf when it +isn't supported, nothing bad will happen. The processes will run +as if the stress parameter always has an empty value.

+ +

Forcing stress-adaptive behavior on or off

+ +

You can manually force stress-adaptive behavior on, by adding +a "-o stress=yes" command-line option in master.cf. This can be +useful for testing overrides on the SMTP service. Issue "postfix +reload" to make the change effective.

+ +

Note: setting the stress parameter in main.cf has no effect for +services that accept remote connections.

+ +
+
+1 /etc/postfix/master.cf:
+2     # =============================================================
+3     # service type  private unpriv  chroot  wakeup  maxproc command
+4     # =============================================================
+5     # 
+6     smtp      inet  n       -       n       -       -       smtpd
+7         -o stress=yes
+8         -o . . .
+
+
+ +

To permanently force stress-adaptive behavior off with a specific +service, specify "-o stress=" on its master.cf command line. This +may be desirable for the "submission" service. Issue "postfix reload" +to make the change effective.

+ +

Note: setting the stress parameter in main.cf has no effect for +services that accept remote connections.

+ +
+
+1 /etc/postfix/master.cf:
+2     # =============================================================
+3     # service type  private unpriv  chroot  wakeup  maxproc command
+4     # =============================================================
+5     # 
+6     submission inet n       -       n       -       -       smtpd
+7         -o stress=
+8         -o . . .
+
+
+ +

Other measures to off-load zombies

+ +

The postscreen(8) daemon, introduced with Postfix 2.8, provides +additional protection against mail server overload. One postscreen(8) +process handles multiple inbound SMTP connections, and decides which +clients may to talk to a Postfix SMTP server process. By keeping +spambots away, postscreen(8) leaves more SMTP server processes +available for legitimate clients, and delays the onset of server +overload conditions.

+ +

Credits

+ + + + diff --git a/proto/TLS_LEGACY_README.html b/proto/TLS_LEGACY_README.html new file mode 100644 index 0000000..1bc80e8 --- /dev/null +++ b/proto/TLS_LEGACY_README.html @@ -0,0 +1,1606 @@ + + + + + + +Postfix legacy TLS Support + + + + + + + +

Postfix legacy TLS Support +

+ +
+ +

NOTE

+ +

This document describes an old TLS user interface that is based +on a third-party TLS patch by Lutz Jänicke. As of Postfix +version 2.3, the old user interface still exists to allow migration +from earlier Postfix releases, but its functionality is frozen.

+ +

What Postfix TLS support does for you

+ +

Transport Layer Security (TLS, formerly called SSL) provides +certificate-based authentication and encrypted sessions. An +encrypted session protects the information that is transmitted with +SMTP mail or with SASL authentication. + +

Postfix version 2.2 introduces support for TLS as described in +RFC 3207. TLS Support for older Postfix versions was available as +an add-on patch. The section "Compatibility with +Postfix < 2.2 TLS support" below discusses the differences +between these implementations.

+ +

Topics covered in this document:

+ + + +

And last but not least, for the impatient:

+ + + +

How Postfix TLS support works

+ +

The diagram below shows the main elements of the Postfix TLS +architecture and their relationships. Colored boxes with numbered +names represent Postfix daemon programs. Other colored boxes +represent storage elements.

+ + + + + + + + + + + + + + +
Network->
smtpd(8)
  		+ + <---seed---

<-session->
tlsmgr(8)
  		---seed--->

<-session-> + +
smtp(8)
+  		->Network
+ + /
/
+		 |
|		 + + +
\
\
+smtpd
session
key cache 		PRNG
state
file 		smtp
session
key cache +
+ +

Building Postfix with TLS support

+ +

To build Postfix with TLS support, first we need to generate +the make(1) files with the necessary definitions. This is +done by invoking the command "make makefiles" in the Postfix +top-level directory and with arguments as shown next.

+ +

NOTE: Do not use Gnu TLS. It will spontaneously terminate +a Postfix daemon process with exit status code 2, instead of allowing +Postfix to 1) report the error to the maillog file, and to 2) provide +plaintext service where this is appropriate.

+ + + +

If you need to apply other customizations (such as Berkeley DB +databases, MySQL, PosgreSQL, LDAP or SASL), see the respective +Postfix README documents, and combine their "make makefiles" +instructions with the instructions above:

+ +
+
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_TLS \
+    (other -D or -I options)" \
+    AUXLIBS="-lssl -lcrypto \
+    (other -l options for libraries in /usr/lib) \
+    (-L/path/name + -l options for other libraries)"
+
+
+ +

To complete the build process, see the Postfix INSTALL +instructions. Postfix has TLS support turned off by default, so +you can start using Postfix as soon as it is installed.

+ +

SMTP Server specific settings

+ +

Topics covered in this section:

+ + + +

Server-side certificate and private +key configuration

+ +

In order to use TLS, the Postfix SMTP server needs a certificate +and a private key. Both must be in "pem" format. The private key +must not be encrypted, meaning: the key must be accessible without +password. Both certificate and private key may be in the same +file.

+ +

Both RSA and DSA certificates are supported. Typically you will +only have RSA certificates issued by a commercial CA. In addition, +the tools supplied with OpenSSL will by default issue RSA certificates. +You can have both at the same time, in which case the cipher used +determines which certificate is presented. For Netscape and OpenSSL +clients without special cipher choices, the RSA certificate is +preferred.

+ +

In order for remote SMTP clients to check the Postfix SMTP +server certificates, the CA certificate (in case of a certificate +chain, all CA certificates) must be available. You should add +these certificates to the server certificate, the server certificate +first, then the issuing CA(s).

+ +

Example: the certificate for "server.dom.ain" was issued by +"intermediate CA" which itself has a certificate issued by "root +CA". Create the server.pem file with:

+ +
+
+% cat server_cert.pem intermediate_CA.pem > server.pem
+
+
+ +

A Postfix SMTP server certificate supplied here must be usable +as SSL server certificate and hence pass the "openssl verify -purpose +sslserver ..." test.

+ +

A client that trusts the root CA has a local copy of the root +CA certificate, so it is not necessary to include the root CA +certificate here. Leaving it out of the "server.pem" file reduces +the overhead of the TLS exchange.

+ +

If you want the Postfix SMTP server to accept remote SMTP client +certificates issued by these CAs, append the root certificate to +$smtpd_tls_CAfile or install it in the $smtpd_tls_CApath directory. When +you configure trust in a root CA, it is not necessary to explicitly trust +intermediary CAs signed by the root CA, unless $smtpd_tls_ccert_verifydepth +is less than the number of CAs in the certificate chain for the clients +of interest. With a verify depth of 1 you can only verify certificates +directly signed by a trusted CA, and all trusted intermediary CAs need to +be configured explicitly. With a verify depth of 2 you can verify clients +signed by a root CA or a direct intermediary CA (so long as the client +is correctly configured to supply its intermediate CA certificate).

+ +

RSA key and certificate examples:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_cert_file = /etc/postfix/server.pem
+    smtpd_tls_key_file = $smtpd_tls_cert_file
+
+
+ +

Their DSA counterparts:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
+    smtpd_tls_dkey_file = $smtpd_tls_dcert_file
+
+
+ +

To verify a remote SMTP client certificate, the Postfix SMTP +server needs to trust the certificates of the issuing Certification +Authorities. These certificates in "pem" format can be stored in a +single $smtpd_tls_CAfile or in multiple files, one CA per file in +the $smtpd_tls_CApath directory. If you use a directory, don't forget +to create the necessary "hash" links with:

+ +
+
+# $OPENSSL_HOME/bin/c_rehash /path/to/directory 
+
+
+ +

The $smtpd_tls_CAfile contains the CA certificates of one or +more trusted CAs. The file is opened (with root privileges) before +Postfix enters the optional chroot jail and so need not be accessible +from inside the chroot jail.

+ +

Additional trusted CAs can be specified via the $smtpd_tls_CApath +directory, in which case the certificates are read (with $mail_owner +privileges) from the files in the directory when the information +is needed. Thus, the $smtpd_tls_CApath directory needs to be +accessible inside the optional chroot jail.

+ +

When you configure Postfix to request client certificates (by +setting $smtpd_tls_ask_ccert = yes), any certificates in +$smtpd_tls_CAfile are sent to the client, in order to allow it to +choose an identity signed by a CA you trust. If no $smtpd_tls_CAfile +is specified, no preferred CA list is sent, and the client is free +to choose an identity signed by any CA. Many clients use a fixed +identity regardless of the preferred CA list and you may be able +to reduce TLS negotiation overhead by installing client CA certificates +mostly or only in $smtpd_tls_CApath. In the latter case you need +not specify a $smtpd_tls_CAfile.

+ +

Note, that unless client certificates are used to allow greater +access to TLS authenticated clients, it is best to not ask for +client certificates at all, as in addition to increased overhead +some clients (notably in some cases qmail) are unable to complete +the TLS handshake when client certificates are requested.

+ +

Example:

+
+
+/etc/postfix/main.cf:
+    smtpd_tls_CAfile = /etc/postfix/CAcert.pem
+    smtpd_tls_CApath = /etc/postfix/certs
+
+
+ +

Server-side TLS activity logging

+ +

To get additional information about Postfix SMTP server TLS +activity you can increase the loglevel from 0..4. Each logging +level also includes the information that is logged at a lower +logging level.

+ +
+ + + + + + + + + + + + + + +
0 Disable logging of TLS activity.
1 Log TLS handshake and certificate information. +
2 Log levels during TLS negotiation.
3 Log hexadecimal and ASCII dump of TLS +negotiation process
4 Log hexadecimal and ASCII dump of complete +transmission after STARTTLS
+ +
+ +

Use loglevel 3 only in case of problems. Use of loglevel 4 is +strongly discouraged.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_loglevel = 0
+
+
+ +

To include information about the protocol and cipher used as +well as the client and issuer CommonName into the "Received:" +message header, set the smtpd_tls_received_header variable to true. +The default is no, as the information is not necessarily authentic. +Only information recorded at the final destination is reliable, +since the headers may be changed by intermediate servers.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_received_header = yes
+
+
+ +

Enabling TLS in the Postfix SMTP server

+ +

By default, TLS is disabled in the Postfix SMTP server, so no +difference to plain Postfix is visible. Explicitly switch it on +using "smtpd_use_tls = yes".

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_use_tls = yes
+
+
+ +

With this, Postfix SMTP server announces STARTTLS support to +SMTP clients, but does not require that clients use TLS encryption. +

+ +

Note: when an unprivileged user invokes "sendmail -bs", STARTTLS +is never offered due to insufficient privileges to access the server +private key. This is intended behavior.

+ +

You can ENFORCE the use of TLS, so that the Postfix SMTP server +announces STARTTLS and accepts no mail without TLS encryption, by +setting "smtpd_enforce_tls = yes". According to RFC 2487 this MUST +NOT be applied in case of a publicly-referenced Postfix SMTP server. +This option is off by default and should only seldom be used.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_enforce_tls = yes
+
+
+ +

TLS is sometimes used in the non-standard "wrapper" mode where +a server always uses TLS, instead of announcing STARTTLS support +and waiting for clients to request TLS service. Some clients, namely +Outlook [Express] prefer the "wrapper" mode. This is true for OE +(Win32 < 5.0 and Win32 >=5.0 when run on a port<>25 +and OE (5.01 Mac on all ports).

+ +

It is strictly discouraged to use this mode from main.cf. If +you want to support this service, enable a special port in master.cf +and specify "-o smtpd_tls_wrappermode = yes" as an smtpd(8) command +line option. Port 465 (smtps) was once chosen for this feature. +

+ +

Example:

+ +
+
+/etc/postfix/master.cf:
+    smtps    inet  n       -       n       -       -       smtpd
+      -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
+
+
+ +

Client certificate verification

+ +

To receive a remote SMTP client certificate, the Postfix SMTP +server must explicitly ask for one (any contents of $smtpd_tls_CAfile +are also sent to the client as a hint for choosing a certificate +from a suitable CA). Unfortunately, Netscape clients will either +complain if no matching client certificate is available or will +offer the user client a list of certificates to choose from. +Additionally some MTAs (notably some versions of qmail) are unable +to complete TLS negotiation when client certificates are requested, +and abort the SMTP session. So this option is "off" by default. +You will however need the certificate if you want to use certificate +based relaying with, for example, the permit_tls_clientcerts +feature.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_ask_ccert = no
+
+
+ +

You may also decide to REQUIRE a remote SMTP client certificate +before allowing TLS connections. This feature is included for +completeness, and implies "smtpd_tls_ask_ccert = yes".

+ +

Please be aware, that this will inhibit TLS connections without +a proper client certificate and that it makes sense only when +non-TLS submission is disabled (smtpd_enforce_tls = yes). Otherwise, +clients could bypass the restriction by simply not using STARTTLS +at all.

+ +

When TLS is not enforced, the connection will be handled as +if only "smtpd_tls_ask_ccert = yes" is specified, and a warning is +logged.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_req_ccert = no
+
+
+ +

A client certificate verification depth of 1 is sufficient if +the certificate is directly issued by a CA listed in the CA file. +The default value (5) should also suffice for longer chains (root +CA issues special CA which then issues the actual certificate...) +

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_ccert_verifydepth = 5
+
+
+ +

Supporting AUTH over TLS only

+ +

Sending AUTH data over an unencrypted channel poses a security +risk. When TLS layer encryption is required (smtpd_enforce_tls = +yes), the Postfix SMTP server will announce and accept AUTH only +after the TLS layer has been activated with STARTTLS. When TLS +layer encryption is optional (smtpd_enforce_tls = no), it may +however still be useful to only offer AUTH when TLS is active. To +maintain compatibility with non-TLS clients, the default is to +accept AUTH without encryption. In order to change this behavior, +set "smtpd_tls_auth_only = yes".

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_auth_only = no
+
+
+ +

Server-side TLS session cache

+ +

The Postfix SMTP server and the remote SMTP client negotiate +a session, which takes some computer time and network bandwidth. +By default, this session information is cached only in the smtpd(8) +process actually using this session and is lost when the process +terminates. To share the session information between multiple +smtpd(8) processes, a persistent session cache can be used. You +can specify any database type that can store objects of several +kbytes and that supports the sequence operator. DBM databases are +not suitable because they can only store small objects. The cache +is maintained by the tlsmgr(8) process, so there is no problem with +concurrent access. Session caching is highly recommended, because +the cost of repeatedly negotiating TLS session keys is high.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache
+
+
+ +

As of version 2.5, Postfix will no longer maintain this file +in a directory with non-Postfix ownership. As a migration aid, +attempts to open such files are redirected to the Postfix-owned +$data_directory, and a warning is logged.

+ +

Cached Postfix SMTP server session information expires after +a certain amount of time. Postfix/TLS does not use the OpenSSL +default of 300s, but a longer time of 3600sec (=1 hour). RFC 2246 +recommends a maximum of 24 hours.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_session_cache_timeout = 3600s
+
+
+ +

Server access control

+ +

Postfix TLS support introduces three additional features for +Postfix SMTP server access control:

+ +
+ +
+ +
permit_tls_clientcerts

Allow the remote SMTP +client SMTP request if the client certificate passes verification, +and if its fingerprint is listed in the list of client certificates +(see relay_clientcerts discussion below).

+ +
permit_tls_all_clientcerts

Allow the remote +client SMTP request if the client certificate passes verification. +

+ +
check_ccert_access type:table
+

If the client certificate passes verification, use its fingerprint +as a key for the specified access(5) table.

+ +
+ +
+ +

The permit_tls_all_clientcerts feature must be used with caution, +because it can result in too many access permissions. Use this +feature only if a special CA issues the client certificates, and +only if this CA is listed as trusted CA. If other CAs are trusted, +any owner of a valid client certificate would be authorized. +The permit_tls_all_clientcerts feature can be practical for a +specially created email relay server.

+ +

It is however recommended to stay with the permit_tls_clientcerts +feature and list all certificates via $relay_clientcerts, as +permit_tls_all_clientcerts does not permit any control when a +certificate must no longer be used (e.g. an employee leaving).

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions = 
+        ... 
+        permit_tls_clientcerts 
+        reject_unauth_destination
+        ...
+
+
+ +

The Postfix list manipulation routines give special treatment +to whitespace and some other characters, making the use of certificate +names impractical. Instead we use the certificate fingerprints as +they are difficult to fake but easy to use for lookup. Postfix +lookup tables are in the form of (key, value) pairs. Since we only +need the key, the value can be chosen freely, e.g. the name of +the user or host.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    relay_clientcerts = hash:/etc/postfix/relay_clientcerts
+
+/etc/postfix/relay_clientcerts:
+    D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
+
+
+ +

Server-side cipher controls

+ +

To influence the Postfix SMTP server cipher selection scheme, +you can give cipherlist string. A detailed description would go +to far here; please refer to the OpenSSL documentation. If you +don't know what to do with it, simply don't touch it and leave the +(openssl-)compiled in default!

+ +

DO NOT USE " to enclose the string, specify just the string!!!

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_cipherlist = DEFAULT
+
+
+ +

If you want to take advantage of ciphers with EDH, DH parameters +are needed. Instead of using the built-in DH parameters for both +1024bit and 512bit, it is better to generate "own" parameters, +since otherwise it would "pay" for a possible attacker to start a +brute force attack against parameters that are used by everybody. +For this reason, the parameters chosen are already different from +those distributed with other TLS packages.

+ +

To generate your own set of DH parameters, use:

+ +
+
+% openssl gendh -out /etc/postfix/dh_1024.pem -2 -rand /var/run/egd-pool 1024
+% openssl gendh -out /etc/postfix/dh_512.pem -2 -rand /var/run/egd-pool 512
+
+
+ +

Examples:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
+    smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
+
+
+ +

Miscellaneous server controls

+ +

The smtpd_starttls_timeout parameter limits the time of Postfix +SMTP server write and read operations during TLS startup and shutdown +handshake procedures.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_starttls_timeout = 300s
+
+
+ +

SMTP Client specific settings

+ +

Topics covered in this section:

+ + + +

Client-side certificate and private +key configuration

+ +

During TLS startup negotiation the Postfix SMTP client may present +a certificate to the remote SMTP server. The Netscape client is +rather clever here and lets the user select between only those +certificates that match CA certificates offered by the remote SMTP +server. As the Postfix SMTP client uses the "SSL_connect()" function +from the OpenSSL package, this is not possible and we have to choose +just one certificate. So for now the default is to use _no_ +certificate and key unless one is explicitly specified here.

+ +

Both RSA and DSA certificates are supported. You can have both +at the same time, in which case the cipher used determines which +certificate is presented.

+ +

It is possible for the Postfix SMTP client to use the same +key/certificate pair as the Postfix SMTP server. If a certificate +is to be presented, it must be in "pem" format. The private key +must not be encrypted, meaning: it must be accessible without +password. Both parts (certificate and private key) may be in the +same file.

+ +

In order for remote SMTP servers to verify the Postfix SMTP +client certificates, the CA certificate (in case of a certificate +chain, all CA certificates) must be available. You should add +these certificates to the client certificate, the client certificate +first, then the issuing CA(s).

+ +

Example: the certificate for "client.example.com" was issued by +"intermediate CA" which itself has a certificate of "root CA". +Create the client.pem file with:

+ +
+
+% cat client_cert.pem intermediate_CA.pem > client.pem 
+
+
+ +

A Postfix SMTP client certificate supplied here must be usable +as SSL client certificate and hence pass the "openssl verify -purpose +sslclient ..." test.

+ +

A server that trusts the root CA has a local copy of the root +CA certificate, so it is not necessary to include the root CA +certificate here. Leaving it out of the "client.pem" file reduces +the overhead of the TLS exchange.

+ +

If you want the Postfix SMTP client to accept remote SMTP server +certificates issued by these CAs, append the root certificate to +$smtp_tls_CAfile or install it in the $smtp_tls_CApath directory. When +you configure trust in a root CA, it is not necessary to explicitly trust +intermediary CAs signed by the root CA, unless $smtp_tls_scert_verifydepth +is less than the number of CAs in the certificate chain for the servers +of interest. With a verify depth of 1 you can only verify certificates +directly signed by a trusted CA, and all trusted intermediary CAs need to +be configured explicitly. With a verify depth of 2 you can verify servers +signed by a root CA or a direct intermediary CA (so long as the server +is correctly configured to supply its intermediate CA certificate).

+ +

RSA key and certificate examples:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_cert_file = /etc/postfix/client.pem
+    smtp_tls_key_file = $smtp_tls_cert_file
+
+
+ +

Their DSA counterparts:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
+    smtp_tls_dkey_file = $smtp_tls_dcert_file
+
+
+ +

To verify a remote SMTP server certificate, the Postfix SMTP +client needs to trust the certificates of the issuing Certification +Authorities. These certificates in "pem" format can be stored in a +single $smtp_tls_CAfile or in multiple files, one CA per file in +the $smtp_tls_CApath directory. If you use a directory, don't forget +to create the necessary "hash" links with:

+ +
+
+# $OPENSSL_HOME/bin/c_rehash /path/to/directory 
+
+
+ +

The $smtp_tls_CAfile contains the CA certificates of one or more +trusted CAs. The file is opened (with root privileges) before Postfix +enters the optional chroot jail and so need not be accessible from inside the +chroot jail.

+ +

Additional trusted CAs can be specified via the $smtp_tls_CApath +directory, in which case the certificates are read (with $mail_owner +privileges) from the files in the directory when the information +is needed. Thus, the $smtp_tls_CApath directory needs to be accessible +inside the optional chroot jail.

+ +

The choice between $smtp_tls_CAfile and $smtp_tls_CApath is +a space/time tradeoff. If there are many trusted CAs, the cost of +preloading them all into memory may not pay off in reduced access time +when the certificate is needed.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_CAfile = /etc/postfix/CAcert.pem
+    smtp_tls_CApath = /etc/postfix/certs
+
+
+ +

Client-side TLS activity logging

+ +

To get additional information about Postfix SMTP client TLS +activity you can increase the loglevel from 0..4. Each logging +level also includes the information that is logged at a lower +logging level.

+ +
+ + + + + + + + + + + + + + +
0 Disable logging of TLS activity.
1 Log TLS handshake and certificate information. +
2 Log levels during TLS negotiation.
3 Log hexadecimal and ASCII dump of TLS +negotiation process
4 Log hexadecimal and ASCII dump of complete +transmission after STARTTLS
+ +
+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_loglevel = 0
+
+
+ +

Client-side TLS session cache

+ +

The remote SMTP server and the Postfix SMTP client negotiate a +session, which takes some computer time and network bandwidth. By +default, this session information is cached only in the smtp(8) +process actually using this session and is lost when the process +terminates. To share the session information between multiple +smtp(8) processes, a persistent session cache can be used. You +can specify any database type that can store objects of several +kbytes and that supports the sequence operator. DBM databases are +not suitable because they can only store small objects. The cache +is maintained by the tlsmgr(8) process, so there is no problem with +concurrent access. Session caching is highly recommended, because +the cost of repeatedly negotiating TLS session keys is high. Future +Postfix SMTP servers may limit the number of sessions that a client +is allowed to negotiate per unit time.

+ + +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
+
+
+ +

As of version 2.5, Postfix will no longer maintain this file +in a directory with non-Postfix ownership. As a migration aid, +attempts to open such files are redirected to the Postfix-owned +$data_directory, and a warning is logged.

+ +

Cached Postfix SMTP client session information expires after +a certain amount of time. Postfix/TLS does not use the OpenSSL +default of 300s, but a longer time of 3600s (=1 hour). RFC 2246 +recommends a maximum of 24 hours.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_session_cache_timeout = 3600s
+
+
+ +

Enabling TLS in the Postfix SMTP +client

+ +

By default, TLS is disabled in the Postfix SMTP client, so no +difference to plain Postfix is visible. If you enable TLS, the +Postfix SMTP client will send STARTTLS when TLS support is announced +by the remote SMTP server.

+ +

When the server accepts the STARTTLS command, but the subsequent +TLS handshake fails, and no other server is available, the Postfix SMTP +client defers the delivery attempt, and the mail stays in the queue. After +a handshake failure, the communications channel is in an indeterminate +state and cannot be used for non-TLS deliveries.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_use_tls = yes
+
+
+ +

Requiring TLS encryption +

+ +

You can ENFORCE the use of TLS, so that the Postfix SMTP client +will not deliver mail over unencrypted connections. In this mode, +the remote SMTP server hostname must match the information in the +remote server certificate, and the server certificate must be issued +by a CA that is trusted by the Postfix SMTP client. If the remote +server certificate doesn't verify or the remote SMTP server hostname +doesn't match, and no other server is available, the delivery +attempt is deferred and the mail stays in the queue.

+ +

The remote SMTP server hostname is verified against all names +provided as dNSNames +in the SubjectAlternativeName. If no dNSNames are specified, the +CommonName is checked. Verification may be turned off with the +smtp_tls_enforce_peername option which is discussed below.

+ +

Enforcing the use of TLS is useful if you know that you will +only +connect to servers that support RFC 2487 _and_ that present server +certificates that meet the above requirements. An example would +be a client only sends email to one specific mailhub that offers +the necessary STARTTLS support.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_enforce_tls = yes
+
+
+ +

Disabling server certificate +verification

+ +

As of RFC 2487 the requirements for hostname checking for MTA +clients are not set. When TLS is required (smtp_enforce_tls = yes), +the option smtp_tls_enforce_peername can be set to "no" to disable +strict remote SMTP server hostname checking. In this case, the mail +delivery will proceed regardless of the CommonName etc. listed in +the certificate.

+ +

Despite the potential for eliminating "man-in-the-middle" and +other attacks, mandatory certificate/peername verification is not +viable as a default Internet mail delivery policy at this time. A +significant fraction of TLS enabled MTAs uses self-signed certificates, +or certificates that are signed by a private Certification Authority. +On a machine that delivers mail to the Internet, if you set +smtp_enforce_tls = yes, you should probably also set +smtp_tls_enforce_peername = no. You can use the per-site TLS +policies (see below) to enable full peer verification for specific +destinations that are known to have verifiable TLS server certificates. +

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_enforce_tls = yes
+    smtp_tls_enforce_peername = no
+
+
+ +

Per-site TLS policies

+ +

A small fraction of servers offer STARTTLS but the negotiation +consistently fails, leading to mail aging out of the queue and +bouncing back to the sender. In such cases, you can use the per-site +policies to disable TLS for the problem sites. Alternatively, you +can enable TLS for just a few specific sites and not enable it for +all sites.

+ + + +

The smtp_tls_per_site table is searched for a policy that matches +the following information:

+ +
+ +
+ +
remote SMTP server hostname
This is simply the DNS +name of the server that the Postfix SMTP client connects to; this +name may be obtained from other DNS lookups, such as MX lookups or +CNAME lookups.
+ +
next-hop destination
This is normally the domain +portion of the recipient address, but it may be overruled by +information from the transport(5) table, from the relayhost parameter +setting, or from the relay_transport setting. When it's not the +recipient domain, the next-hop destination can have the Postfix-specific +form "[name]", [name]:port", "name" or +"name:port".
+ +
+ +
+ +

When both the hostname lookup and the next-hop lookup succeed, +the host policy does not automatically override the next-hop policy. +Instead, precedence is given to either the more specific or the +more secure per-site policy as described below.

+ +

The smtp_tls_per_site table uses a simple "name whitespace +value" format. Specify host names or next-hop destinations on +the left-hand side; no wildcards are allowed. On the right hand +side specify one of the following keywords:

+ +
+ +
+ +
NONE
Don't use TLS at all. This overrides a less +specific MAY lookup result from the alternate host or next-hop +lookup key, and overrides the global smtp_use_tls, smtp_enforce_tls, +and smtp_tls_enforce_peername settings.
+ +
MAY
Try to use TLS if the server announces support, +otherwise use the unencrypted connection. This has less precedence +than a more specific result (including NONE) from the alternate +host or next-hop lookup key, and has less precedence than the more +specific global "smtp_enforce_tls = yes" or "smtp_tls_enforce_peername += yes".
+ +
MUST_NOPEERMATCH
Require TLS encryption, but do not +require that the remote SMTP server hostname matches the information +in the remote SMTP server certificate, or that the server certificate +was issued by a trusted CA. This overrides a less secure NONE +or a less specific MAY lookup result from the alternate host +or next-hop lookup key, and overrides the global smtp_use_tls, +smtp_enforce_tls and smtp_tls_enforce_peername settings.
+ +
MUST
Require TLS encryption, require that the remote +SMTP server hostname matches the information in the remote SMTP +server certificate, and require that the remote SMTP server certificate +was issued by a trusted CA. This overrides a less secure NONE +and MUST_NOPEERMATCH or a less specific MAY lookup +result from the alternate host or next-hop lookup key, and overrides +the global smtp_use_tls, smtp_enforce_tls and smtp_tls_enforce_peername +settings.
+ +
+ +
+ +

The precedences between global (main.cf) and per-site TLS +policies can be summarized as follows:

+ + + +

Closing a DNS loophole with + per-site TLS policies

+ +

As long as no secure DNS lookup mechanism is available, false +hostnames in MX or CNAME responses can change the server hostname +that Postfix uses for TLS policy lookup and server certificate +verification. Even with a perfect match between the server hostname +and the server certificate, there is no guarantee that Postfix is +connected to the right server. To avoid this loophole take the +following steps:

+ + + +

Example:

+ +
+/etc/postfix/main.cf:
+    smtp_tls_per_site = hash:/etc/postfix/tls_per_site
+    relayhost = [msa.example.net]:587
+
+/etc/postfix/tls_per_site:
+    # relayhost exact nexthop match
+    [msa.example.net]:587       MUST
+
+    # TLS should not be used with the example.org MX hosts.
+    example.org                 NONE
+
+    # TLS should not be used with the host smtp.example.com.
+    smtp.example.com             NONE
+
+
+ +

Discovering servers that support +TLS

+ +

As we decide on a "per site" basis whether or not to use TLS, +it would be good to have a list of sites that offered "STARTTLS". +We can collect it ourselves with this option.

+ +

If the smtp_tls_note_starttls_offer feature is enabled and a +server offers STARTTLS while TLS is not already enabled for that +server, the Postfix SMTP client logs a line as follows:

+ +
+
+postfix/smtp[pid]: Host offered STARTTLS: [hostname.example.com]
+
+
+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_note_starttls_offer = yes
+
+
+ +

Server certificate verification depth

+ +

When verifying a remote SMTP server certificate, a verification +depth of 1 is sufficient if the certificate is directly issued by +a CA specified with smtp_tls_CAfile or smtp_tls_CApath. The default +value of 5 should also suffice for longer chains (root CA issues +special CA which then issues the actual certificate...)

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_scert_verifydepth = 5
+
+
+ +

Client-side cipher controls

+ +

To influence the Postfix SMTP client cipher selection scheme, +you can give cipherlist string. A detailed description would go +to far here; please refer to the OpenSSL documentation. If you +don't know what to do with it, simply don't touch it and leave the +(openssl-)compiled in default!

+ +

DO NOT USE " to enclose the string, specify just the string!!!

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_cipherlist = DEFAULT
+
+
+ +

Miscellaneous client controls

+ +

The smtp_starttls_timeout parameter limits the time of Postfix +SMTP client write and read operations during TLS startup and shutdown +handshake procedures. In case of problems the Postfix SMTP client +tries the next network address on the mail exchanger list, and +defers delivery if no alternative server is available.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_starttls_timeout = 300s
+
+
+ +

TLS manager specific settings

+ +

The security of cryptographic software such as TLS depends +critically on the ability to generate unpredictable numbers for +keys and other information. To this end, the tlsmgr(8) process +maintains a Pseudo Random Number Generator (PRNG) pool. This is +queried by the smtp(8) and smtpd(8) processes when they initialize. +By default, these daemons request 32 bytes, the equivalent to 256 +bits. This is more than sufficient to generate a 128bit (or 168bit) +session key.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_daemon_random_bytes = 32
+
+
+ +

In order to feed its in-memory PRNG pool, the tlsmgr(8) reads +entropy from an external source, both at startup and during run-time. +Specify a good entropy source, like EGD or /dev/urandom; be sure +to only use non-blocking sources (on OpenBSD, use /dev/arandom +when tlsmgr(8) complains about /dev/urandom timeout errors). +If the entropy source is not a +regular file, you must prepend the source type to the source name: +"dev:" for a device special file, or "egd:" for a source with EGD +compatible socket interface.

+ +

Examples (specify only one in main.cf):

+ +
+
+/etc/postfix/main.cf:
+    tls_random_source = dev:/dev/urandom
+    tls_random_source = egd:/var/run/egd-pool
+
+
+ +

By default, tlsmgr(8) reads 32 bytes from the external entropy +source at each seeding event. This amount (256bits) is more than +sufficient for generating a 128bit symmetric key. With EGD and +device entropy sources, the tlsmgr(8) limits the amount of data +read at each step to 255 bytes. If you specify a regular file as +entropy source, a larger amount of data can be read.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_random_bytes = 32
+
+
+ +

In order to update its in-memory PRNG pool, the tlsmgr(8) +queries the external entropy source again after a pseudo-random +amount of time. The time is calculated using the PRNG, and is +between 0 and the maximal time specified with tls_random_reseed_period. +The default maximal time interval is 1 hour.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_random_reseed_period = 3600s
+
+
+ +

The tlsmgr(8) process saves the PRNG state to a persistent +exchange file at regular times and when the process terminates, so +that it can recover the PRNG state the next time it starts up. +This file is created when it does not exist. Its default location +is under the Postfix configuration directory, which is not the +proper place for information that is modified by Postfix. Instead, +the file location should probably be on the /var partition (but +not inside the chroot jail).

+ +

Examples:

+ +
+
+/etc/postfix/main.cf:
+    tls_random_exchange_name = /etc/postfix/prng_exch
+    tls_random_prng_update_period = 3600s
+
+
+ +

Getting started, quick and dirty

+ +

The following steps will get you started quickly. Because you +sign your own Postfix public key certificate, you get TLS encryption +but no TLS authentication. This is sufficient for testing, and +for exchanging email with sites that you have no trust relationship +with. For real authentication, your Postfix public key certificate +needs to be signed by a recognized Certification Authority, and +Postfix needs to be configured with a list of public key certificates +of Certification Authorities, so that Postfix can verify the public key +certificates of remote hosts.

+ +

In the examples below, user input is shown in bold +font, and a "#" prompt indicates a super-user shell.

+ + + + +

Reporting problems

+ +

When reporting a problem, please be thorough in the report. +Patches, when possible, are greatly appreciated too.

+ +

Please differentiate when possible between:

+ + + +

Compatibility with Postfix <2.2 TLS support

+ +

Postfix version 2.2 TLS support is based on the Postfix/TLS +patch by Lutz Jänicke, but differs in a few minor ways.

+ + + +

The smtp_tls_per_site limitations were removed by the end of +the Postfix 2.2 support cycle.

+ +

Credits

+ + + + + + diff --git a/proto/TLS_README.html b/proto/TLS_README.html new file mode 100644 index 0000000..040fdfd --- /dev/null +++ b/proto/TLS_README.html @@ -0,0 +1,3259 @@ + + + + + + +Postfix TLS Support + + + + + + + +

Postfix TLS Support +

+ +
+ +

What Postfix TLS support does for you

+ +

Transport Layer Security (TLS, formerly called SSL) provides +certificate-based authentication and encrypted sessions. An +encrypted session protects the information that is transmitted with +SMTP mail or with SASL authentication.

+ +

NOTE: By turning on TLS support in Postfix, you not only get +the ability to encrypt mail and to authenticate remote SMTP clients +or servers. You also turn on hundreds of thousands of lines of +OpenSSL library code. Assuming that OpenSSL is written as carefully +as Wietse's own code, every 1000 lines introduce one additional bug +into Postfix.

+ +

Topics covered in this document:

+ + + +

And last but not least, for the impatient:

+ + + +

How Postfix TLS support works

+ +

The diagram below shows the main elements of the Postfix TLS +architecture and their relationships. Colored boxes with numbered +names represent Postfix daemon programs. Other colored boxes +represent storage elements.

+ + + +

Not shown in the figure are the tlsproxy(8) server and the +postscreen(8) server. These use TLS in the same manner as smtpd(8). +

+ + + + + + + + + + + + +
Network->
smtpd(8)
  		+ + <---seed----

<-key/cert->
tlsmgr(8)
  		----seed--->

<-key/cert-> + +
smtp(8)
+  		->Network
+ + /
/
+		 |
|		 + + +
\
\
+smtpd
session
key cache 		PRNG
state
file 		smtp
session
key cache +
+ +

SMTP Server specific settings

+ +

Topics covered in this section:

+ + + +

Server-side certificate and private +key configuration

+ +

In order to use TLS, the Postfix SMTP server generally needs +a certificate and a private key. Both must be in "PEM" format. The +private key must not be encrypted, meaning: the key must be accessible +without a password. The certificate and private key may be in the same +file, in which case the certificate file should be owned by "root" and +not be readable by any other user. If the key is stored separately, +this access restriction applies to the key file only, and the +certificate file may be "world-readable".

+ +

Public Internet MX hosts without certificates signed by a +well-known public CA must still generate, and be prepared to present +to most clients, a self-signed or private-CA signed certificate. +The remote SMTP client will generally not be able to verify the +self-signed certificate, but unless the client is running Postfix +or similar software, it will only negotiate TLS ciphersuites that +require a server certificate.

+ +

For servers that are not public Internet MX hosts, Postfix +supports configurations with no certificates. This entails the use of +just the anonymous TLS ciphers, which are not supported by typical SMTP +clients. Since some clients may not fall back to plain text after a TLS +handshake failure, a certificate-less Postfix SMTP server will be unable +to receive email from some TLS-enabled clients. To avoid accidental +configurations with no certificates, Postfix enables certificate-less +operation only when the administrator explicitly sets +"smtpd_tls_cert_file = none". This ensures that new Postfix SMTP server +configurations will not accidentally enable TLS without certificates.

+ +

Note that server certificates are not optional in TLS 1.3. To +run without certificates you'd have to disable the TLS 1.3 protocol by +including '!TLSv1.3' in "smtpd_tls_protocols" and perhaps also +"smtpd_tls_mandatory_protocols". It is simpler instead to just +configure a certificate chain. Certificate-less operation is not +recommended.

+ +

RSA, DSA and ECDSA (Postfix ≥ 2.6) certificates are supported. +Most sites only have RSA certificates. You can configure all three +at the same time, in which case the ciphersuite negotiated with the +remote SMTP client determines which certificate is used. If your +DNS zone is signed, and you want to publish DANE TLSA (RFC 6698, +RFC 7671, RFC 7672) records, these must match all of the configured +certificate chains. Since the best practice is to publish "3 1 1" +certificate associations, create a separate TLSA record to match +each public-key certificate digest.

+ +

Creating the server certificate file

+ +

To verify the Postfix SMTP server certificate, the remote SMTP +client must receive the issuing CA certificates via the TLS handshake +or via public-key infrastructure. This means that the Postfix server +public-key certificate file must include the server certificate +first, then the issuing CA(s) (bottom-up order). The Postfix SMTP +server certificate must be usable as SSL server certificate and +hence pass the "openssl verify -purpose sslserver ..." test. +

+ +

The examples that follow show how to create a server certificate +file. We assume that the certificate for "server.example.com" was +issued by "intermediate CA" which itself has a certificate issued +by "root CA".

+ + + +

For instructions on how to compute the digest of a certificate +or its public key for use in TLSA records, see the documentation of +the smtpd_tls_fingerprint_digest main.cf parameter.

+ +

When a new key or certificate is generated, an additional TLSA +record with the new digest must be published in advance of the +actual deployment of the new key or certificate on the server. You +must allow sufficient time for any TLSA RRsets with only the old +digest to expire from DNS caches. The safest practice is to wait +until the DNSSEC signature on the previous TLSA RRset expires, and +only then switch the server to use new keys published in the updated +TLSA RRset. Once the new certificate trust chain and private key +are in effect, the DNS should be updated once again to remove the +old digest from the TLSA RRset.

+ +

If you want the Postfix SMTP server to accept remote SMTP client +certificates issued by one or more root CAs, append the root +certificate to $smtpd_tls_CAfile or install it in the $smtpd_tls_CApath +directory.

+ +

Configuring the server certificate and key files

+ +

Example: Postfix ≥ 3.4 all-in-one chain file(s). One or more +chain files that start with a key that is immediately followed by the +corresponding certificate and any additional issuer certificates. A +single file can hold multiple (key, cert, [chain]) sequences, one +per algorithm. It is typically simpler to keep the chain for each +algorithm in its own file. Most users are likely to deploy just a +single RSA chain, but with OpenSSL 1.1.1, it is possible to deploy up to +five chains, one each for RSA, ECDSA, ED25519, ED448 and even the +obsolete DSA.

+ +
+
+    # Postfix ≥ 3.4.  Preferred configuration interface.  Each file
+    # starts with the private key, followed by the corresponding
+    # certificate, and any intermediate issuer certificates. The root CA
+    # cert may also be needed when published as a DANE trust anchor.
+    #
+    smtpd_tls_chain_files =
+        /etc/postfix/rsa.pem,
+        /etc/postfix/ecdsa.pem,
+        /etc/postfix/ed25519.pem,
+        /etc/postfix/ed448.pem
+
+
+ +

You can also store the keys separately from their certificates, again +provided each is listed before the corresponding certificate chain. Storing a +key and its associated certificate chain in separate files is not recommended, +because this is prone to race conditions during key rollover, as there is no +way to update multiple files atomically.

+ +
+
+    # Postfix ≥ 3.4.
+    # Storing keys separately from the associated certificates is not
+    # recommended.
+    smtpd_tls_chain_files =
+        /etc/postfix/rsakey.pem,
+        /etc/postfix/rsacerts.pem,
+        /etc/postfix/ecdsakey.pem,
+        /etc/postfix/ecdsacerts.pem
+
+
+ +

The below examples show the legacy algorithm-specific configurations +for Postfix 3.3 and older. With Postfix ≤ 3.3, even if the key is +stored in the same file as the certificate, the file is read twice and a +(brief) race condition still exists during key rollover. While Postfix +≥ 3.4 avoids the race when the key and certificate are in the same +file, you should use the new "smtpd_tls_chain_files" interface shown +above.

+ +

RSA key and certificate examples:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_cert_file = /etc/postfix/server.pem
+    smtpd_tls_key_file = $smtpd_tls_cert_file
+
+
+ +

Their DSA counterparts:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
+    smtpd_tls_dkey_file = $smtpd_tls_dcert_file
+
+
+ +

Their ECDSA counterparts (Postfix ≥ 2.6 + OpenSSL ≥ 1.0.0):

+ +
+
+/etc/postfix/main.cf:
+    # Some clients will not be ECDSA capable, so you will likely still need
+    # an RSA certificate and private key.
+    #
+    smtpd_tls_eccert_file = /etc/postfix/server-ecdsa.pem
+    smtpd_tls_eckey_file = $smtpd_tls_eccert_file
+
+
+ +

TLS without certificates for servers serving exclusively +anonymous-cipher capable clients:

+ +
+
+/etc/postfix/main.cf:
+    # Not recommended: breaks TLS 1.3 and clients that don't support
+    # anonymous cipher suites.
+    smtpd_tls_cert_file = none
+
+
+ +

To verify a remote SMTP client certificate, the Postfix SMTP +server needs to trust the certificates of the issuing Certification +Authorities. These certificates in "PEM" format can be stored in a +single $smtpd_tls_CAfile or in multiple files, one CA per file in +the $smtpd_tls_CApath directory. If you use a directory, don't forget +to create the necessary "hash" links with:

+ +
+
+# $OPENSSL_HOME/bin/c_rehash /path/to/directory 
+
+
+ +

The $smtpd_tls_CAfile contains the CA certificates of one or +more trusted CAs. The file is opened (with root privileges) before +Postfix enters the optional chroot jail and so need not be accessible +from inside the chroot jail.

+ +

Additional trusted CAs can be specified via the $smtpd_tls_CApath +directory, in which case the certificates are read (with $mail_owner +privileges) from the files in the directory when the information +is needed. Thus, the $smtpd_tls_CApath directory needs to be +accessible inside the optional chroot jail.

+ +

When you configure the Postfix SMTP server to request client certificates, the DNs of Certification +Authorities in $smtpd_tls_CAfile are sent to the client, in order to allow +it to choose an identity signed by a CA you trust. If no $smtpd_tls_CAfile +is specified, no preferred CA list is sent, and the client is free to +choose an identity signed by any CA. Many clients use a fixed identity +regardless of the preferred CA list and you may be able to reduce TLS +negotiation overhead by installing client CA certificates mostly or +only in $smtpd_tls_CApath. In the latter case you need not specify a +$smtpd_tls_CAfile.

+ +

Note, that unless client certificates are used to allow greater +access to TLS authenticated clients, it is best to not ask for +client certificates at all, as in addition to increased overhead +some clients (notably in some cases qmail) are unable to complete +the TLS handshake when client certificates are requested.

+ +

Example:

+
+
+/etc/postfix/main.cf:
+    smtpd_tls_CAfile = /etc/postfix/CAcert.pem
+    smtpd_tls_CApath = /etc/postfix/certs
+
+
+ +

Server-side forward-secrecy configuration

+ +

If you want to take maximal advantage of ciphers that offer forward secrecy see +the Getting +started section of FORWARD_SECRECY_README. The +full document conveniently presents all information about Postfix +forward secrecy support in one place: what forward secrecy is, how +to tweak settings, and what you can expect to see when Postfix uses +ciphers with forward secrecy.

+ +

Server-side TLS activity logging

+ +

To get additional information about Postfix SMTP server TLS +activity you can increase the log level from 0..4. Each logging +level also includes the information that is logged at a lower +logging level.

+ +
+ + + + + + + + + + + + + + + + +
Level Postfix 2.9 and later Earlier +releases.
0 Disable +logging of TLS activity.
1 Log only a summary +message on TLS handshake completion — no logging of client +certificate trust-chain verification errors if client certificate +verification is not required. Log the summary +message, peer certificate summary information and unconditionally log +trust-chain verification errors.
2 Also +log levels during TLS negotiation.
3 Also +log hexadecimal and ASCII dump of TLS negotiation process.
4 Also +log hexadecimal and ASCII dump of complete transmission after +STARTTLS.
+ +
+ +

Use log level 3 only in case of problems. Use of log level 4 is +strongly discouraged.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_loglevel = 0
+
+
+ +

To include information about the protocol and cipher used as +well as the client and issuer CommonName into the "Received:" +message header, set the smtpd_tls_received_header variable to true. +The default is no, as the information is not necessarily authentic. +Only information recorded at the final destination is reliable, +since the headers may be changed by intermediate servers.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_received_header = yes
+
+
+ +

Enabling TLS in the Postfix SMTP server

+ +

By default, TLS is disabled in the Postfix SMTP server, so no +difference to plain Postfix is visible. Explicitly switch it on +with "smtpd_tls_security_level = may".

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_security_level = may
+
+
+ +

With this, the Postfix SMTP server announces STARTTLS support to +remote SMTP clients, but does not require that clients use TLS encryption. +

+ +

Note: when an unprivileged user invokes "sendmail -bs", STARTTLS +is never offered due to insufficient privileges to access the Postfix +SMTP server +private key. This is intended behavior.

+ +

You can ENFORCE the use of TLS, +so that the Postfix SMTP server announces STARTTLS and accepts no +mail without TLS encryption, by setting +"smtpd_tls_security_level = encrypt". According to RFC 2487 this +MUST NOT be applied in case +of a publicly-referenced Postfix SMTP server. This option is off +by default and should only seldom be used.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_security_level = encrypt
+
+
+ +

TLS is sometimes used in the non-standard "wrapper" mode where +a server always uses TLS, instead of announcing STARTTLS support +and waiting for remote SMTP clients to request TLS service. Some +clients, namely +Outlook [Express] prefer the "wrapper" mode. This is true for OE +(Win32 < 5.0 and Win32 >=5.0 when run on a port<>25 +and OE (5.01 Mac on all ports).

+ +

It is strictly discouraged to use this mode from main.cf. If +you want to support this service, enable a special port in master.cf +and specify "-o smtpd_tls_wrappermode=yes" (note: no space around +the "=") as an smtpd(8) command line option. Port 465 (smtps) was +once chosen for this feature. +

+ +

Example:

+ +
+
+/etc/postfix/master.cf:
+    smtps    inet  n       -       n       -       -       smtpd
+      -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
+
+
+ +

Client certificate verification

+ +

To receive a remote SMTP client certificate, the Postfix SMTP +server must explicitly ask for one (any contents of $smtpd_tls_CAfile +are also sent to the client as a hint for choosing a certificate from +a suitable CA). Unfortunately, Netscape clients will either complain +if no matching client certificate is available or will offer the user +client a list of certificates to choose from. Additionally some MTAs +(notably some versions of qmail) are unable to complete TLS negotiation +when client certificates are requested, and abort the SMTP session. So +this option is "off" by default. You will however need the certificate +if you want to use certificate based relaying with, for example, the +permit_tls_clientcerts feature. A server that wants client certificates +must first present its own certificate. While Postfix by default +offers anonymous ciphers to remote SMTP clients, these are automatically +suppressed +when the Postfix SMTP server is configured to ask for client +certificates.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_ask_ccert = yes
+    smtpd_tls_security_level = may
+
+
+ +

When TLS is enforced you may also decide +to REQUIRE a remote SMTP client certificate for all TLS connections, +by setting "smtpd_tls_req_ccert = yes". This feature implies +"smtpd_tls_ask_ccert = yes". When TLS is not enforced, +"smtpd_tls_req_ccert = yes" is ignored and a warning is +logged.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_req_ccert = yes
+    smtpd_tls_security_level = encrypt
+
+
+ +

The client certificate verification depth is specified with the +main.cf smtpd_tls_ccert_verifydepth parameter. The default verification +depth is 9 (the OpenSSL default), for compatibility with Postfix +versions before 2.5 where smtpd_tls_ccert_verifydepth was ignored. +When you configure trust in a +root CA, it is not necessary to explicitly trust intermediary CAs signed +by the root CA, unless $smtpd_tls_ccert_verifydepth is less than the +number of CAs in the certificate chain for the clients of interest. With +a verify depth of 1 you can only verify certificates directly signed +by a trusted CA, and all trusted intermediary CAs need to be configured +explicitly. With a verify depth of 2 you can verify clients signed by a +root CA or a direct intermediary CA (so long as the client is correctly +configured to supply its intermediate CA certificate).

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_ccert_verifydepth = 2
+
+
+ +

Supporting AUTH over TLS only

+ +

Sending AUTH data over an unencrypted channel poses a security +risk. When TLS layer encryption is required +("smtpd_tls_security_level = encrypt"), the Postfix SMTP server will +announce and accept AUTH only after the TLS layer has been activated +with STARTTLS. When TLS layer encryption is optional +("smtpd_tls_security_level = may"), it may however still be useful +to only offer AUTH when TLS is active. To maintain compatibility +with non-TLS clients, the default is to accept AUTH without encryption. +In order to change this behavior, set +"smtpd_tls_auth_only = yes".

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_auth_only = no
+
+
+ +

Server-side TLS session cache

+ +

The Postfix SMTP server and the remote SMTP client negotiate a +session, which takes some computer time and network bandwidth. SSL +protocol versions other than SSLv2 support resumption of cached +sessions. Not only is this more CPU and bandwidth efficient, it +also reduces latency as only one network round-trip is used to +resume a session while it takes two round-trips to create a session +from scratch.

+ +

Since Postfix uses multiple smtpd(8) service processes, an +in-memory cache is not sufficient for session re-use. Clients store +at most one cached session per server and are very unlikely to +repeatedly connect to the same server process. Thus session caching +in the Postfix SMTP server generally requires a shared cache (an +alternative available with Postfix ≥ 2.11 is described below). +

+ +

To share the session information between multiple +smtpd(8) processes, a session cache database is used. You +can specify any database type that can store objects of several +kbytes and that supports the sequence operator. DBM databases are +not suitable because they can only store small objects. The cache +is maintained by the tlsmgr(8) process, so there is no problem with +concurrent access. Session caching is highly recommended, because +the cost of repeatedly negotiating TLS session keys is high.

+ +

Starting with Postfix 2.11, linked with a compatible OpenSSL +library (at least 0.9.8h, preferably 1.0.0 or later) the Postfix +SMTP server supports RFC 5077 TLS session resumption without +server-side state when the remote SMTP client also supports RFC +5077. The session is encrypted by the server in a session +ticket returned to client for storage. When a client sends a +valid session ticket, the server decrypts it and resumes the session, +provided neither the ticket nor the session have expired. This +makes it possible to resume cached sessions without allocating space +for a shared database on the server. Consequently, for Postfix +≥ 2.11 the smtpd_tls_session_cache_database parameter should +generally be left empty. Session caching can be disabled by setting +the session cache timeout to zero, otherwise the timeout must be +at least 2 minutes and at most 100 days.

+ +

Note, session tickets can only be negotiated if the client +disables SSLv2 and does not use the legacy SSLv2 compatible HELLO +message. This is true by default with the Postfix ≥ 2.6 SMTP +client.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
+
+
+ +

Note: as of version 2.5, Postfix no longer uses root privileges +when opening this file. The file should now be stored under the +Postfix-owned data_directory. As a migration aid, an attempt to +open the file under a non-Postfix directory is redirected to the +Postfix-owned data_directory, and a warning is logged.

+ +

Cached Postfix SMTP server session information expires after +a certain amount of time. Postfix/TLS does not use the OpenSSL +default of 300s, but a longer time of 3600sec (=1 hour). RFC 2246 +recommends a maximum of 24 hours.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_session_cache_timeout = 3600s
+
+
+ +

As of Postfix 2.11 this setting cannot exceed 100 days. If set +≤ 0, session caching is disabled. If set to a positive value +less than 2 minutes, the minimum value of 2 minutes is used instead.

+ +

When the Postfix SMTP server does not save TLS sessions to an +external cache database, client-side session caching is unlikely +to be useful. To reduce waste of client resources, the Postfix SMTP server can +be configured to not issue TLS session ids. By default the Postfix +SMTP server always issues TLS session ids. This works around known +interoperability issues with some MUAs, and prevents possible +interoperability issues with other MTAs.

+ +

Example:

+ +
+
+    smtpd_tls_always_issue_session_ids = no
+
+
+ +

Server access control

+ +

Postfix TLS support introduces three additional features for +Postfix SMTP server access control:

+ +
+ +
+ +
permit_tls_clientcerts

Allow the remote SMTP +client request if the client certificate fingerprint or certificate +public key fingerprint (Postfix 2.9 and later) is listed in the +client certificate table (see relay_clientcerts discussion below). +

+ +
permit_tls_all_clientcerts

Allow the remote SMTP +client request if the client certificate passes trust chain verification. +Useful with private-label CAs that only issue certificates to trusted +clients (and not otherwise).

+ +
check_ccert_access type:table

Use the remote +SMTP client certificate fingerprint or public key fingerprint +(Postfix 2.9 and later) as the lookup key for the specified access(5) +table.

+ +
+ +
+ +

The digest algorithm used to compute the client certificate +fingerprints is specified with the main.cf smtpd_tls_fingerprint_digest +parameter. The default is "md5", for compatibility with Postfix +versions < 2.5.

+ +

The permit_tls_all_clientcerts feature must be used with caution, +because it can result in too many access permissions. Use this +feature only if a special CA issues the client certificates, and +only if this CA is listed as trusted CA. If other CAs are trusted, +any owner of a valid client certificate would be authorized. +The permit_tls_all_clientcerts feature can be practical for a +specially created email relay server.

+ +

It is however recommended to stay with the permit_tls_clientcerts +feature and list all certificates via $relay_clientcerts, as +permit_tls_all_clientcerts does not permit any control when a +certificate must no longer be used (e.g. an employee leaving).

+ +

Example:

+ +
+
+# With Postfix 2.10 and later, the mail relay policy is
+# preferably specified under smtpd_relay_restrictions.
+/etc/postfix/main.cf:
+    smtpd_relay_restrictions = 
+        permit_mynetworks
+        permit_tls_clientcerts 
+        reject_unauth_destination
+
+ +
+# Older configurations combine relay control and spam control under
+# smtpd_recipient_restrictions. To use this example with Postfix ≥
+# 2.10 specify "smtpd_relay_restrictions=".
+/etc/postfix/main.cf:
+    smtpd_recipient_restrictions = 
+        permit_mynetworks
+        permit_tls_clientcerts 
+        reject_unauth_destination
+        ...other rules...
+
+
+ +

Example: Postfix lookup tables are in the form of (key, value) +pairs. Since we only need the key, the value can be chosen freely, e.g. +the name of the user or host:

+ +
+
+/etc/postfix/main.cf:
+    relay_clientcerts = hash:/etc/postfix/relay_clientcerts
+
+/etc/postfix/relay_clientcerts:
+    D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
+
+
+ +

To extract the public key fingerprint from an X.509 certificate, +you need to extract the public key from the certificate and compute +the appropriate digest of its DER (ASN.1) encoding. With OpenSSL +the "-pubkey" option of the "x509" command extracts the public +key always in "PEM" format. We pipe the result to another OpenSSL +command that converts the key to DER and then to the "dgst" command +to compute the fingerprint.

+ +

The actual command to transform the key to DER format depends +on the version of OpenSSL used. With OpenSSL 1.0.0 and later, the +"pkey" command supports all key types. With OpenSSL 0.9.8 and +earlier, the key type is always RSA (nobody uses DSA, and EC +keys are not fully supported by 0.9.8), so the "rsa" command is +used.

+
+
+# OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl pkey -pubin -outform DER |
+    openssl dgst -sha1 -c
+(stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
+
+# OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl rsa -pubin -outform DER |
+    openssl dgst -md5 -c
+(stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
+
+
+

Note: Postfix 2.9.0–2.9.5 computed the public key +fingerprint incorrectly. To use public-key fingerprints, upgrade +to Postfix 2.9.6 or later.

+ +

Server-side cipher controls

+ +

The Postfix SMTP server supports 5 distinct cipher grades as +specified by the smtpd_tls_mandatory_ciphers configuration parameter, +which determines the minimum cipher grade with mandatory TLS +encryption. The default minimum cipher grade for mandatory TLS is +"medium" which is essentially 128-bit encryption or better. The +smtpd_tls_ciphers parameter (Postfix ≥ 2.6) controls the minimum +cipher grade used with opportunistic TLS. Here, the default minimum +cipher grade is "medium" for Postfix releases after the middle of +2015, "export" for older Postfix releases. With Postfix < 2.6, +the minimum opportunistic TLS cipher grade is always "export".

+ +

By default anonymous ciphers are enabled. They are automatically +disabled when remote SMTP client certificates are requested. If +clients are expected to always verify the Postfix SMTP +server certificate you may want to disable anonymous ciphers +by setting "smtpd_tls_mandatory_exclude_ciphers = aNULL" or +"smtpd_tls_exclude_ciphers = aNULL", as appropriate. One can't force +a remote SMTP client to check the server certificate, so excluding +anonymous ciphers is generally unnecessary.

+ +

With mandatory and opportunistic TLS encryption, the Postfix +SMTP server by default disables SSLv2 and SSLv3 with Postfix releases +after the middle of 2015; older releases only disable SSLv2 for +mandatory TLS. The mandatory TLS protocol list is specified via the +smtpd_tls_mandatory_protocols configuration parameter. The +smtpd_tls_protocols parameter (Postfix ≥ 2.6) +controls the SSL/TLS protocols used with opportunistic TLS.

+ +

Note that the OpenSSL library only supports protocol exclusion +(not inclusion). For this reason, Postfix can exclude only protocols +that are known at the time the Postfix software is written. If new +protocols are added to the OpenSSL library, they cannot be excluded +without corresponding changes to the Postfix source code.

+ +

For a server that is not a public Internet MX host, Postfix +supports configurations with no server +certificates that use only the anonymous ciphers. This is +enabled by explicitly setting "smtpd_tls_cert_file = none" +and not specifying an smtpd_tls_dcert_file or smtpd_tls_eccert_file. +Such configurations may not interoperate with some clients, and require +that TLSv1.3 be explicitly disabled. Therefore, they are not +recommended, it is better and simpler to just configure a suitable +certificate.

+ +

Example, MSA that requires TLSv1 or higher, not SSLv2 or SSLv3, +with high grade ciphers:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_cert_file = /etc/postfix/cert.pem
+    smtpd_tls_key_file = /etc/postfix/key.pem
+    smtpd_tls_mandatory_ciphers = high
+    smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
+    smtpd_tls_security_level = encrypt
+    # Preferred syntax with Postfix ≥ 2.5:
+    smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
+    # Legacy syntax:
+    smtpd_tls_mandatory_protocols = TLSv1
+
+
+ +

With Postfix ≥ 3.4, specify instead a single file that holds the +key followed by the corresponding certificate and any associated issuing +certificates, leaving the "smtpd_tls_cert_file" and "smtpd_tls_key_file" +and related DSA and ECDSA parameters empty.

+ +
+
+/etc/postfix/main.cf:
+    smtpd_tls_chain_files = /etc/postfix/rsachain.pem
+    smtpd_tls_cert_file =
+    smtpd_tls_key_file =
+    ...
+
+
+ +

If you want to take maximal advantage of ciphers that offer forward secrecy see +the Getting +started section of FORWARD_SECRECY_README. The +full document conveniently presents all information about Postfix +forward secrecy support in one place: what forward secrecy is, how +to tweak settings, and what you can expect to see when Postfix uses +ciphers with forward secrecy.

+ +

Postfix 2.8 and later, in combination with OpenSSL 0.9.7 and later +allows TLS servers to preempt the TLS client's cipher-suite preference list. +This is possible only with SSLv3 and later, as in SSLv2 the client +chooses the cipher-suite from a list supplied by the server.

+ +

By default, the OpenSSL server selects the client's most preferred +cipher-suite that the server supports. With SSLv3 and later, the server +may choose its own most preferred cipher-suite that is supported (offered) +by the client. Setting "tls_preempt_cipherlist = yes" enables server +cipher-suite preferences. The default OpenSSL behavior applies with +"tls_preempt_cipherlist = no".

+ +

While server cipher-suite selection may in some cases lead to +a more secure or performant cipher-suite choice, there is some risk +of interoperability issues. In the past, some SSL clients have +listed lower priority ciphers that they did not implement correctly. +If the server chooses a cipher that the client prefers less, it may +select a cipher whose client implementation is flawed. Most notably +Windows 2003 Microsoft Exchange servers have flawed implementations +of DES-CBC3-SHA, which OpenSSL considers stronger than RC4-SHA. +Enabling server cipher-suite selection may create interoperability +issues with Windows 2003 Microsoft Exchange clients.

+ +

Miscellaneous server controls

+ +

The smtpd_starttls_timeout parameter limits the time of Postfix +SMTP server write and read operations during TLS startup and shutdown +handshake procedures.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtpd_starttls_timeout = 300s
+
+
+ +

With Postfix 2.8 and later, the tls_disable_workarounds parameter +specifies a list or bit-mask of default-enabled OpenSSL bug +work-arounds to disable. This may be necessary if one of the +work-arounds enabled by default in OpenSSL proves to pose a security +risk, or introduces an unexpected interoperability issue. The list +of enabled bug work-arounds is OpenSSL-release-specific. See the +tls_disable_workarounds parameter documentation for the list of +supported values.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_disable_workarounds = 0xFFFFFFFF
+    tls_disable_workarounds = CVE-2010-4180
+
+
+ +

With Postfix ≥ 2.11, the tls_ssl_options parameter specifies +a list or bit-mask of OpenSSL options to enable. Specify one or +more of the named options below, or a hexadecimal bitmask of options +found in the ssl.h file corresponding to the run-time OpenSSL +library. While it may be reasonable to turn off all bug workarounds +(see above), it is not a good idea to attempt to turn on all features. +See the tls_ssl_options parameter documentation for the list of +supported values.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_ssl_options = no_ticket, no_compression
+
+
+ +

You should only enable features via the hexadecimal mask when +the need to control the feature is critical (to deal with a new +vulnerability or a serious interoperability problem). Postfix DOES +NOT promise backwards compatible behavior with respect to the mask +bits. A feature enabled via the mask in one release may be enabled +by other means in a later release, and the mask bit will then be +ignored. Therefore, use of the hexadecimal mask is only a temporary +measure until a new Postfix or OpenSSL release provides a better +solution.

+ +

SMTP Client specific settings

+ +

Topics covered in this section:

+ + + +

Configuring TLS in the SMTP/LMTP client +

+ +

Similar to the Postfix SMTP server, the Postfix SMTP/LMTP client +implements multiple TLS security levels. These levels are described +in more detail in the sections that follow.

+ +
+
none
+
No TLS.
+
may
+
Opportunistic TLS.
+
encrypt
+
Mandatory TLS encryption. +
dane
+
Opportunistic DANE TLS. +
dane-only
+
Mandatory DANE TLS. +
fingerprint
+
Certificate fingerprint verification. +
verify
+
Mandatory server certificate verification. +
secure
+
Secure-channel TLS. +
+ +

TLS support in the LMTP delivery agent

+ +

The smtp(8) and lmtp(8) delivery agents are implemented by a +single dual-purpose program. Specifically, all the TLS features +described below apply +equally to SMTP and LMTP, after replacing the "smtp_" prefix of the each +parameter name with "lmtp_". + +

The Postfix LMTP delivery agent can communicate with LMTP servers +listening +on UNIX-domain sockets. When server certificate verification is enabled +and the server is listening on a UNIX-domain socket, the $myhostname +parameter is used to set the TLS verification nexthop and +hostname.

+ +

NOTE: Opportunistic encryption of LMTP traffic over UNIX-domain +sockets or loopback TCP connections is futile. TLS is only useful +in this context when +it is mandatory, typically to allow at least one of the server or the +client to authenticate the other. The "null" cipher grade may be +appropriate in this context, when available on both client and server. +The "null" ciphers provide authentication without encryption.

+ +

No TLS encryption

+ +

At the "none" TLS security level, TLS encryption is +disabled. This is the default security level, and +can be configured explicitly by setting "smtp_tls_security_level = none". +For LMTP, use the corresponding "lmtp_" parameter.

+ +

Per-destination settings may override this default setting, in which case +TLS is used selectively, only with destinations explicitly configured +for TLS.

+ +

You can disable TLS for a subset of destinations, while leaving +it enabled for the rest. With the Postfix TLS policy table, specify the "none" +security level. + +

Opportunistic TLS

+ +

At the "may" TLS security level, TLS encryption is opportunistic. +The SMTP transaction is encrypted if the STARTTLS ESMTP feature +is supported by the server. Otherwise, messages are sent in the clear. +Opportunistic TLS can be configured by setting "smtp_tls_security_level = may". +For LMTP, use the corresponding "lmtp_" parameter.

+ +

The "smtp_tls_ciphers" and "smtp_tls_protocols" configuration +parameters (Postfix ≥ 2.6) provide control over the cipher grade +and protocols used with opportunistic TLS. With earlier Postfix +releases, opportunistic TLS always uses the cipher grade "export" +and enables all protocols.

+ +

With opportunistic TLS, mail delivery continues even if the +server certificate is untrusted or bears the wrong name. +When the TLS handshake fails for an opportunistic +TLS session, rather than give up on mail delivery, the Postfix SMTP +client retries the transaction +with TLS disabled. Trying an unencrypted connection makes +it possible to deliver mail to sites with non-interoperable server +TLS implementations.

+ +

Opportunistic encryption is never used for LMTP over UNIX-domain +sockets. The communications channel is already confidential without +TLS, so the only potential benefit of TLS is authentication. Do not +configure opportunistic TLS for LMTP deliveries over UNIX-domain sockets. +Only configure TLS for LMTP over UNIX-domain sockets at the +encrypt security level or higher. +Attempts to configure opportunistic encryption of LMTP sessions will +be ignored with a warning written to the mail logs.

+ +

You can enable opportunistic TLS just for selected destinations. With +the Postfix TLS policy table, +specify the "may" security level.

+ +

This is the most common security level for TLS protected SMTP +sessions, stronger security is not generally available and, if needed, +is typically only configured on a per-destination basis. See the section +on TLS limitations above.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_security_level = may
+
+
+ +

Mandatory TLS encryption

+ +

At the "encrypt" TLS security level, messages are sent only +over TLS encrypted sessions. The SMTP transaction is aborted unless +the STARTTLS ESMTP feature is supported by the remote SMTP server. +If no suitable +servers are found, the message will be deferred. +Mandatory TLS encryption can be configured by setting +"smtp_tls_security_level = encrypt". Even though TLS +encryption is always used, mail delivery continues even if the server +certificate is untrusted or bears the wrong name. +For LMTP, use the corresponding "lmtp_" parameter.

+ +

At this security level and higher, the smtp_tls_mandatory_protocols +and smtp_tls_mandatory_ciphers configuration parameters determine +the list of sufficiently secure SSL protocol versions and the minimum +cipher strength. If the protocol or cipher requirements are not +met, the mail transaction is aborted. The documentation for these +parameters includes useful interoperability and security guidelines. +

+ +

Despite the potential for eliminating passive eavesdropping attacks, +mandatory TLS encryption is not viable as a default security level for +mail delivery to the public Internet. Some MX hosts do not support TLS at +all, and some of those that do have broken implementations. On a host +that delivers mail to the Internet, you should not configure mandatory +TLS encryption as the default security level.

+ +

You can enable mandatory TLS encryption just for specific destinations. +With the Postfix TLS policy +table, specify the "encrypt" security level. +

+ +

Examples:

+ +

In the example below, traffic to example.com and its sub-domains +via the corresponding MX hosts always uses TLS. The SSLv2 protocol +will be disabled (the default setting of smtp_tls_mandatory_protocols +excludes SSLv2+3). Only high- or medium-strength (i.e. 128 bit or +better) ciphers will be used by default for all "encrypt" security +level sessions.

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+/etc/postfix/tls_policy:
+    example.com       encrypt
+    .example.com      encrypt
+
+
+ +

In the next example, secure message submission is configured +via the MSA "[example.net]:587". TLS sessions are encrypted +without authentication, because this MSA does not possess an acceptable +certificate. This MSA is known to be capable of "TLSv1" and "high" grade +ciphers, so these are selected via the policy +table.

+ +

Note: the policy table lookup key is the verbatim next-hop +specification from the recipient domain, transport(5) table or relayhost +parameter, with any enclosing square brackets and optional port. Take +care to be consistent: the suffixes ":smtp" or ":25" or no port suffix +result in different policy table lookup keys, even though they are +functionally equivalent nexthop specifications. Use at most one of these +forms for all destinations. Below, the policy table has multiple keys, +just in case the transport table entries are not specified consistently.

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+/etc/services:
+    submission      587/tcp         msa             # mail message submission
+
+/etc/postfix/tls_policy:
+    [example.net]:587 encrypt protocols=TLSv1 ciphers=high
+    [example.net]:msa encrypt protocols=TLSv1 ciphers=high
+    [example.net]:submission encrypt protocols=TLSv1 ciphers=high
+
+
+ +

DANE TLS authentication.

+ +

The Postfix SMTP client supports two TLS security levels based +on DANE TLSA (RFC 6698, RFC 7671, RFC 7672) records. The opportunistic +"dane" level and the mandatory "dane-only" level.

+ +

The "dane" level is a stronger form of opportunistic TLS that is resistant to +man in the middle and downgrade attacks when the destination domain +uses DNSSEC to publish DANE TLSA records for its MX hosts. If a +remote SMTP server has "usable" (see section 3 of RFC 7672) DANE +TLSA records, the server connection will be authenticated. When +DANE authentication fails, there is no fallback to unauthenticated +or plaintext delivery.

+ +

If TLSA records are published for a given remote SMTP server +(implying TLS support), but are all "unusable" due to unsupported +parameters or malformed data, the Postfix SMTP client will use mandatory unauthenticated TLS. +Otherwise, when no TLSA records are published, the Postfix SMTP +client behavior is the same as with may.

+ +

TLSA records must be published in DNSSEC validated DNS zones. +Any TLSA records in DNS zones not protected via DNSSEC are ignored. +The Postfix SMTP client will not look for TLSA records associated +with MX hosts whose "A" or "AAAA" records lie in an "insecure" DNS +zone. Such lookups have been observed to cause interoperability +issues with poorly implemented DNS servers, and are in any case not +expected to ever yield "secure" results, since that would require +a very unlikely DLV DNS trust anchor configured between the host +record and the associated "_25._tcp" child TLSA record.

+ +

The "dane-only" level is a form of secure-channel TLS based on the DANE PKI. +If "usable" TLSA records are present these are used to authenticate the +remote SMTP server. Otherwise, or when server certificate verification +fails, delivery via the server in question tempfails.

+ +

At both security levels, the TLS policy for the destination is +obtained via TLSA records validated with DNSSEC. For TLSA policy +to be in effect, the destination domain's containing DNS zone must +be signed and the Postfix SMTP client's operating system must be +configured to send its DNS queries to a recursive DNS nameserver +that is able to validate the signed records. Each MX host's DNS +zone needs to also be signed, and needs to publish DANE TLSA (see +section 3 of RFC 7672) records that specify how that MX host's TLS +certificate is to be verified.

+ +

TLSA records do not preempt the normal SMTP MX host +selection algorithm, if some MX hosts support TLSA and others do +not, TLS security will vary from delivery to delivery. It is up +to the domain owner to configure their MX hosts and their DNS +sensibly. To configure the Postfix SMTP client for DNSSEC lookups +see the documentation for the smtp_dns_support_level main.cf +parameter. The tls_dane_digests parameter controls the list of +supported digests.

+ +

As explained in section 3 of RFC 7672, certificate usages "0" +and "1", which are intended to "constrain" existing Web-PKI trust, +are not supported with MTA-to-MTA SMTP. Rather, TLSA records with +usages "0" and "1" are treated as "unusable".

+ +

The Postfix SMTP client supports only certificate usages "2" +and "3". Experimental support for silently mapping certificate +usage "1" to "3" has been withdrawn starting with Postfix 3.2.

+ +

When usable TLSA records are obtained for the remote SMTP server +the Postfix SMTP client sends the SNI TLS extension in its SSL +client hello message. This may help the remote SMTP server live +up to its promise to provide a certificate that matches its TLSA +records.

+ +

For purposes of protocol and cipher selection, the "dane" +security level is treated like a "mandatory" TLS security level, +and weak ciphers and protocols are disabled. Since DANE authenticates +server certificates the "aNULL" cipher-suites are transparently +excluded at this level, no need to configure this manually. RFC +7672 (DANE) TLS authentication is available with Postfix 2.11 and +later.

+ +

When a DANE TLSA record specifies a trust-anchor (TA) certificate +(that is an issuing CA), the strategy used to verify the peername +of the server certificate is unconditionally "nexthop, hostname". +Both the nexthop domain and the hostname obtained from the +DNSSEC-validated MX lookup are safe from forgery and the server +certificate must contain at least one of these names.

+ +

When a DANE TLSA record specifies an end-entity (EE) certificate, +(that is the actual server certificate), as with the fingerprint +security level below, no name checks or certificate expiration checks +are applied. The server certificate (or its public key) either matches +the DANE record or not. Server administrators should publish such +EE records in preference to all other types.

+ +

The pre-requisites for DANE support in the Postfix SMTP client are:

+ +

The above client pre-requisites do not apply to the Postfix SMTP server. +It will support DANE provided it supports TLSv1 and its TLSA records are +published in a DNSSEC signed zone. To receive DANE secured mail for multiple +domains, use the same hostname to add the server to each domain's MX +records. There are no plans to implement SNI in the Postfix SMTP server.

+ +

Note: The Postfix SMTP client's internal stub DNS resolver is +DNSSEC-aware, but it does not itself validate DNSSEC records, rather +it delegates DNSSEC validation to the operating system's configured +recursive DNS nameserver. The Postfix DNS client relies on a secure +channel to the resolver's cache for DNSSEC integrity, but does not +support TSIG to protect the transmission channel between itself and +the nameserver. Therefore, it is strongly recommended (DANE security +guarantee void otherwise) that each MTA run a local DNSSEC-validating +recursive resolver ("unbound" from nlnetlabs.nl is a reasonable +choice) listening on the loopback interface, and that the system +be configured to use only this local nameserver. The local +nameserver may forward queries to an upstream recursive resolver +on another host if desired.

+ +

Note: When the operating system's recursive nameserver is not +local, enabling EDNS0 expanded DNS packet sizes and turning on the +DNSSEC "DO" bit in the DNS request and/or the new DNSSEC-specific +records returned in the nameserver's replies may cause problems +with older or buggy firewall and DNS server implementations. +Therefore, Postfix does not enable DNSSEC by default. Since MX +lookups happen before the security level is determined, DANE support +is disabled for all destinations unless you set "smtp_dns_support_level += dnssec". To enable DNSSEC lookups selectively, define a new +dedicated transport with a "-o smtp_dns_support_level=dnssec" +override in master.cf and route selected domains to that transport. +If DNSSEC proves to be sufficiently reliable for these domains, you +can enable it for all destinations by changing the global +smtp_dns_support_level in main.cf.

+ +

Example: "dane" security for selected destinations, with +opportunistic TLS by default. This is the recommended configuration +for early adopters.

+

+ +
+
+main.cf:
+    indexed = ${default_database_type}:${config_directory}/
+    #
+    # default: Opportunistic TLS with no DNSSEC lookups.
+    #
+    smtp_tls_security_level = may
+    smtp_dns_support_level = enabled
+    #
+    # Per-destination TLS policy
+    #
+    smtp_tls_policy_maps = ${indexed}tls_policy
+    #
+    # default_transport = smtp, but some destinations are special:
+    #
+    transport_maps = ${indexed}transport
+
+
+ +
+
+transport:
+    example.com dane
+    example.org dane
+
+
+ +
+
+tls_policy:
+    example.com dane-only
+
+
+ +
+
+master.cf:
+    dane       unix  -       -       n       -       -       smtp
+      -o smtp_dns_support_level=dnssec
+      -o smtp_tls_security_level=dane
+
+
+ +

Certificate fingerprint verification

+ +

At the fingerprint security level, no trusted Certification +Authorities are used or required. The certificate trust chain, +expiration date, etc., are not checked. Instead, the +smtp_tls_fingerprint_cert_match parameter or the "match" attribute +in the policy table lists the +remote SMTP server certificate fingerprint or public key fingerprint. +Certificate fingerprint verification is available with Postfix 2.5 +and later, public-key fingerprint support is available with Postfix +2.9 and later.

+ +

If certificate fingerprints are exchanged securely, this is the +strongest, and least scalable security level. The administrator needs +to securely collect the fingerprints of the X.509 certificates of each +peer server, store them into a local file, and update this local file +whenever the peer server's public certificate changes. If public key +fingerprints are used in place of fingerprints of the entire certificate, +the fingerprints remain valid even after the certificate is renewed, +provided that the same public/private keys are used to obtain +the new certificate.

+ +

Fingerprint verification may be feasible for an SMTP "VPN" connecting +a small number of branch offices over the Internet, or for secure +connections to a central mail hub. It works poorly if the remote SMTP +server is managed by a third party, and its public certificate changes +periodically without prior coordination with the verifying site.

+ +

The digest algorithm used to calculate the fingerprint is +selected by the smtp_tls_fingerprint_digest parameter. In the policy table multiple fingerprints can be +combined with a "|" delimiter in a single match attribute, or multiple +match attributes can be employed. The ":" character is not used as a +delimiter as it occurs between each pair of fingerprint (hexadecimal) +digits.

+ +

Example: fingerprint TLS security with an internal mailhub. +Two matching fingerprints are listed. The relayhost may be multiple +physical hosts behind a load-balancer, each with its own private/public +key and self-signed certificate. Alternatively, a single relayhost may +be in the process of switching from one set of private/public keys to +another, and both keys are trusted just prior to the transition.

+ +
+
+    relayhost = [mailhub.example.com]
+    smtp_tls_security_level = fingerprint
+    smtp_tls_fingerprint_digest = md5
+    smtp_tls_fingerprint_cert_match =
+        3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+        EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
+
+ +

Example: Certificate fingerprint verification with selected destinations. +As in the example above, we show two matching fingerprints:

+
+
+/etc/postfix/main.cf:
+    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+    smtp_tls_fingerprint_digest = md5
+
+
+
+
+/etc/postfix/tls_policy:
+    example.com	fingerprint
+        match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+        match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
+
+ +

To extract the public key fingerprint from an X.509 certificate, +you need to extract the public key from the certificate and compute +the appropriate digest of its DER (ASN.1) encoding. With OpenSSL +the "-pubkey" option of the "x509" command extracts the public +key always in "PEM" format. We pipe the result to another OpenSSL +command that converts the key to DER and then to the "dgst" command +to compute the fingerprint.

+ +

The actual command to transform the key to DER format depends +on the version of OpenSSL used. With OpenSSL 1.0.0 and later, the +"pkey" command supports all key types. With OpenSSL 0.9.8 and +earlier, the key type is always RSA (nobody uses DSA, and EC +keys are not fully supported by 0.9.8), so the "rsa" command is +used.

+
+
+# OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl pkey -pubin -outform DER |
+    openssl dgst -sha1 -c
+(stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
+
+# OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl rsa -pubin -outform DER |
+    openssl dgst -md5 -c
+(stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
+
+
+

Note: Postfix 2.9.0–2.9.5 computed the public key +fingerprint incorrectly. To use public-key fingerprints, upgrade +to Postfix 2.9.6 or later.

+ +

Mandatory server certificate verification

+ +

At the verify TLS security level, messages are sent only over +TLS encrypted sessions if the remote SMTP server certificate is +valid (not +expired or revoked, and signed by a trusted Certification Authority) +and where the server certificate name matches a known pattern. +Mandatory +server certificate verification can be configured by setting +"smtp_tls_security_level = verify". The +smtp_tls_verify_cert_match parameter can override the default +"hostname" certificate name matching strategy. Fine-tuning the +matching strategy is generally only appropriate for secure-channel destinations. +For LMTP use the corresponding "lmtp_" parameters.

+ +

If the server certificate chain is trusted (see smtp_tls_CAfile +and smtp_tls_CApath), any DNS names in the SubjectAlternativeName +certificate extension are used to verify the remote SMTP server name. +If no +DNS names are specified, the certificate CommonName is checked. +If you want mandatory encryption without server certificate +verification, see above.

+ +

With Postfix ≥ 2.11 the "smtp_tls_trust_anchor_file" parameter +or more typically the corresponding per-destination "tafile" attribute +optionally modifies trust chain verification. If the parameter is +not empty the root CAs in CAfile and CApath are no longer trusted. +Rather, the Postfix SMTP client will only trust certificate-chains +signed by one of the trust-anchors contained in the chosen files. +The specified trust-anchor certificates and public keys are not +subject to expiration, and need not be (self-signed) root CAs. They +may, if desired, be intermediate certificates. Therefore, these +certificates also may be found "in the middle" of the trust chain +presented by the remote SMTP server, and any untrusted issuing +parent certificates will be ignored.

+ +

Despite the potential for eliminating "man-in-the-middle" and other +attacks, mandatory certificate trust chain and subject name verification +is not viable as a default Internet mail delivery policy. Some MX hosts +do not support TLS at all, and a significant portion of TLS-enabled +MTAs use self-signed certificates, or certificates that are signed by +a private Certification Authority. On a machine that delivers mail to +the Internet, you should not configure mandatory server certificate +verification as a default policy.

+ +

Mandatory server certificate verification as a default security +level may be appropriate if you know that you will only connect to +servers that support RFC 2487 and that present verifiable +server certificates. An example would be a client that sends all +email to a central mailhub that offers the necessary STARTTLS +support. In such cases, you can often use a secure-channel configuration instead. +

+ +

You can enable mandatory server certificate verification just +for specific destinations. With the Postfix TLS policy table, specify the "verify" +security level.

+ +

Example:

+ +

In this example, the Postfix SMTP client encrypts all traffic to the +example.com domain. The peer hostname is verified, but +verification is vulnerable to DNS response forgery. Mail transmission +to example.com recipients uses "high" grade ciphers.

+ +
+
+/etc/postfix/main.cf:
+    indexed = ${default_database_type}:${config_directory}/
+    smtp_tls_CAfile = ${config_directory}/CAfile.pem
+    smtp_tls_policy_maps = ${indexed}tls_policy
+
+/etc/postfix/tls_policy:
+    example.com       verify ciphers=high
+
+
+ +

Secure server certificate verification

+ +

At the secure TLS security level, messages are sent only over +secure-channel TLS sessions where DNS forgery resistant server +certificate verification succeeds. If no suitable servers are found, the +message will be deferred. Postfix secure-channels +can be configured by setting "smtp_tls_security_level = secure". +The smtp_tls_secure_cert_match parameter can override the default +"nexthop, dot-nexthop" certificate match strategy. +For LMTP, use the corresponding "lmtp_" parameters.

+ +

If the server certificate chain is trusted (see smtp_tls_CAfile and +smtp_tls_CApath), any DNS names in the SubjectAlternativeName certificate +extension are used to verify the remote SMTP server name. If no DNS names +are +specified, the CommonName is checked. If you want mandatory encryption +without server certificate verification, see above.

+ +

With Postfix ≥ 2.11 the "smtp_tls_trust_anchor_file" parameter +or more typically the corresponding per-destination "tafile" attribute +optionally modifies trust chain verification. If the parameter is +not empty the root CAs in CAfile and CApath are no longer trusted. +Rather, the Postfix SMTP client will only trust certificate-chains +signed by one of the trust-anchors contained in the chosen files. +The specified trust-anchor certificates and public keys are not +subject to expiration, and need not be (self-signed) root CAs. They +may, if desired, be intermediate certificates. Therefore, these +certificates also may be found "in the middle" of the trust chain +presented by the remote SMTP server, and any untrusted issuing +parent certificates will be ignored.

+ +

Despite the potential for eliminating "man-in-the-middle" and other +attacks, mandatory secure server certificate verification is not +viable as a default Internet mail delivery policy. Some MX hosts +do not support TLS at all, and a significant portion of TLS-enabled +MTAs use self-signed certificates, or certificates that are signed +by a private Certification Authority. On a machine that delivers mail +to the Internet, you should not configure secure TLS verification +as a default policy.

+ +

Mandatory secure server certificate verification as a default +security level may be appropriate if you know that you will only +connect to servers that support RFC 2487 and that present +verifiable server certificates. An example would be a client that +sends all email to a central mailhub that offers the necessary +STARTTLS support.

+ +

You can enable secure TLS verification just for specific destinations. +With the Postfix TLS policy table, +specify the "secure" security level.

+ +

Examples:

+ + + +

Client-side TLS activity logging

+ +

To get additional information about Postfix SMTP client TLS +activity you can increase the loglevel from 0..4. Each logging +level also includes the information that is logged at a lower +logging level.

+ +
+ + + + + + + + + + + + + + + + +
Level Postfix 2.9 and later Earlier +releases.
0 Disable +logging of TLS activity.
1 Log only a summary +message on TLS handshake completion — no logging of remote SMTP +server certificate trust-chain verification errors if server certificate +verification is not required. Log the summary +message and unconditionally log trust-chain verification errors. +
2 Also +log levels during TLS negotiation.
3 Also +log hexadecimal and ASCII dump of TLS negotiation process.
4 Also +log hexadecimal and ASCII dump of complete transmission after +STARTTLS.
+ +
+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_loglevel = 0
+
+
+ +

Client-side certificate and private +key configuration

+ +

Do not configure Postfix SMTP client certificates unless you must +present +client TLS certificates to one or more servers. Client certificates are +not usually needed, and can cause problems in configurations that work +well without them. The recommended setting is to let the defaults stand:

+ +
+
+    smtp_tls_cert_file =
+    smtp_tls_dcert_file =
+    smtp_tls_key_file =
+    smtp_tls_dkey_file =
+    # Postfix ≥ 2.6
+    smtp_tls_eccert_file =
+    smtp_tls_eckey_file =
+    # Postfix ≥ 3.4
+    smtp_tls_chain_files =
+
+
+ +

The best way to use the default settings is to comment out the above +parameters in main.cf if present.

+ +

During TLS startup negotiation the Postfix SMTP client may present a +certificate to the remote SMTP server. Browsers typically let the user +select among the certificates that match the CA names indicated by the +remote SMTP server. The Postfix SMTP client does not yet have a mechanism +to select from multiple candidate certificates on the fly, and supports a +single set of certificates (at most one per public key algorithm).

+ +

RSA, DSA and ECDSA (Postfix ≥ 2.6) certificates are supported. +You can configure all three at the same time, in which case the +cipher used determines which certificate is presented.

+ +

It is possible for the Postfix SMTP client to use the same +key/certificate pair as the Postfix SMTP server. If a certificate +is to be presented, it must be in "PEM" format. The private key +must not be encrypted, meaning: it must be accessible without +password. Both parts (certificate and private key) may be in the +same file.

+ +

With OpenSSL 1.1.1 and Postfix ≥ 3.4 it is also possible to +configure Ed25519 and Ed448 certificates. Rather than add two more +pairs of key and certificate parameters, Postfix 3.4 introduces a new +"smtp_tls_chain_files" parameter which specifies all the configured +certificates at once, and handles files that hold both the key and the +associated certificates in one pass, thereby avoiding potential race +conditions during key rollover.

+ +

To enable remote SMTP servers to verify the Postfix SMTP client +certificate, the issuing CA certificates must be made available to the +server. You should include the required certificates in the client +certificate file, the client certificate first, then the issuing +CA(s) (bottom-up order).

+ +

Example: the certificate for "client.example.com" was issued by +"intermediate CA" which itself has a certificate issued by "root CA". +As the "root" super-user create the client.pem file with:

+ +
+
+# umask 077
+# cat client_key.pem client_cert.pem intermediate_CA.pem > chain.pem 
+
+
+ +

A Postfix SMTP client certificate supplied here must be usable +as SSL client certificate and hence pass the "openssl verify -purpose +sslclient ..." test.

+ +

A server that trusts the root CA has a local copy of the root +CA certificate, so it is not necessary to include the root CA +certificate here. Leaving it out of the "chain.pem" file reduces +the overhead of the TLS exchange.

+ +

If you want the Postfix SMTP client to accept remote SMTP server +certificates issued by these CAs, append the root certificate to +$smtp_tls_CAfile or install it in the $smtp_tls_CApath directory.

+ +

Example: Postfix ≥ 3.4 all-in-one chain file(s). One or more +chain files that start with a key that is immediately followed by the +corresponding certificate and any additional issuer certificates. A +single file can hold multiple (key, cert, [chain]) sequences, one +per algorithm. It is typically simpler to keep the chain for each +algorithm in its own file. Most users are likely to deploy at most a +single RSA chain, but with OpenSSL 1.1.1, it is possible to deploy up +five chains, one each for RSA, ECDSA, ED25519, ED448 and even the +obsolete DSA.

+ +
+
+    # Postfix ≥ 3.4.  Preferred configuration interface.  Each file
+    # starts with the private key, followed by the corresponding
+    # certificate, and any intermediate issuer certificates.
+    #
+    smtp_tls_chain_files =
+        /etc/postfix/rsa.pem,
+        /etc/postfix/ecdsa.pem,
+        /etc/postfix/ed25519.pem,
+        /etc/postfix/ed448.pem
+
+
+ +

You can also store the keys separately from their certificates, again +provided each is listed before the corresponding certificate chain. Storing a +key and its associated certificate chain in separate files is not recommended, +because this is prone to race conditions during key rollover, as there is no +way to update multiple files atomically.

+ +
+
+    # Postfix ≥ 3.4.
+    # Storing keys separately from the associated certificates is not
+    # recommended.
+    smtp_tls_chain_files =
+        /etc/postfix/rsakey.pem,
+        /etc/postfix/rsacerts.pem,
+        /etc/postfix/ecdsakey.pem,
+        /etc/postfix/ecdsacerts.pem
+
+
+ +

The below examples show the legacy algorithm-specific configurations +for Postfix 3.3 and older. With Postfix ≤ 3.3, even if the key is +stored in the same file as the certificate, the file is read twice and a +(brief) race condition still exists during key rollover. While Postfix +≥ 3.4 avoids the race when the key and certificate are in the same +file, you should use the new "smtp_tls_chain_files" interface shown +above.

+ +

RSA key and certificate examples:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_cert_file = /etc/postfix/client.pem
+    smtp_tls_key_file = $smtp_tls_cert_file
+
+
+ +

Their DSA counterparts:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
+    smtp_tls_dkey_file = $smtp_tls_dcert_file
+
+
+ +

Their ECDSA counterparts (Postfix ≥ 2.6 + OpenSSL ≥ 1.0.0):

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_eccert_file = /etc/postfix/client-ecdsa.pem
+    smtp_tls_eckey_file = $smtp_tls_eccert_file
+
+
+ +

To verify a remote SMTP server certificate, the Postfix SMTP +client needs to trust the certificates of the issuing Certification +Authorities. These certificates in "pem" format can be stored in a +single $smtp_tls_CAfile or in multiple files, one CA per file in +the $smtp_tls_CApath directory. If you use a directory, don't forget +to create the necessary "hash" links with:

+ +
+
+# $OPENSSL_HOME/bin/c_rehash /path/to/directory 
+
+
+ +

The $smtp_tls_CAfile contains the CA certificates of one or more +trusted CAs. The file is opened (with root privileges) before Postfix +enters the optional chroot jail and so need not be accessible from inside the +chroot jail.

+ +

Additional trusted CAs can be specified via the $smtp_tls_CApath +directory, in which case the certificates are read (with $mail_owner +privileges) from the files in the directory when the information +is needed. Thus, the $smtp_tls_CApath directory needs to be accessible +inside the optional chroot jail.

+ +

The choice between $smtp_tls_CAfile and $smtp_tls_CApath is +a space/time tradeoff. If there are many trusted CAs, the cost of +preloading them all into memory may not pay off in reduced access time +when the certificate is needed.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_CAfile = /etc/postfix/CAcert.pem
+    smtp_tls_CApath = /etc/postfix/certs
+
+
+ +

Client-side TLS connection reuse

+ +

Historically, the Postfix SMTP client has supported multiple +deliveries per plaintext connection. Postfix 3.4 introduces support +for multiple deliveries per TLS-encrypted connection. Multiple +deliveries per connection improve mail delivery performance, +especially for destinations that throttle clients that don't combine +deliveries.

+ +

To enable multiple deliveries per TLS connection, specify:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_connection_reuse = yes
+
+
+ +

Alternatively, specify the attribute "connection_reuse=yes" in +an smtp_tls_policy_maps entry.

+ +

The implementation of TLS connection reuse relies on the same +scache(8) service as used for delivering plaintext SMTP mail, the +same tlsproxy(8) daemon as used by the postscreen(8) service, and +relies on the same hints from the qmgr(8) daemon. + +See "Postfix Connection +Cache" for a description of the underlying connection reuse +infrastructure.

+ +

Initial SMTP handshake:

+
    smtp(8) -> remote SMTP server
+ +

Reused SMTP/TLS connection, or new SMTP/TLS connection:

+
    smtp(8) -> tlsproxy(8) -> remote SMTP server
+ +

Cached SMTP/TLS connection:

+
    scache(8) -> tlsproxy(8) -> remote SMTP server
+ +

As of Postfix 3.4, TLS connection reuse is disabled by default. +This may change once the impact on over-all performance is understood. +

+ +

Client-side TLS session cache

+ +

The remote SMTP server and the Postfix SMTP client negotiate a +session, which takes some computer time and network bandwidth. By +default, this session information is cached only in the smtp(8) +process actually using this session and is lost when the process +terminates. To share the session information between multiple +smtp(8) processes, a persistent session cache can be used. You +can specify any database type that can store objects of several +kbytes and that supports the sequence operator. DBM databases are +not suitable because they can only store small objects. The cache +is maintained by the tlsmgr(8) process, so there is no problem with +concurrent access. Session caching is highly recommended, because +the cost of repeatedly negotiating TLS session keys is high. Future +Postfix SMTP servers may limit the number of sessions that a client +is allowed to negotiate per unit time.

+ + +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
+
+
+ +

Note: as of version 2.5, Postfix no longer uses root privileges +when opening this file. The file should now be stored under the +Postfix-owned data_directory. As a migration aid, an attempt to +open the file under a non-Postfix directory is redirected to the +Postfix-owned data_directory, and a warning is logged.

+ +

Cached Postfix SMTP client session information expires after +a certain amount of time. Postfix/TLS does not use the OpenSSL +default of 300s, but a longer time of 3600s (=1 hour). RFC 2246 +recommends a maximum of 24 hours.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_session_cache_timeout = 3600s
+
+
+ +

As of Postfix 2.11 this setting cannot exceed 100 days. If set +≤ 0, session caching is disabled. If set to a positive value +less than 2 minutes, the minimum value of 2 minutes is used instead.

+ +

Client TLS limitations +

+ +

The security properties of TLS communication channels are +application specific. While the TLS protocol can provide a confidential, +tamper-resistant, mutually authenticated channel between client +and server, not all of these security features are applicable to every +communication.

+ +

For example, while mutual TLS authentication between browsers and web +servers is possible, it is not practical, or even useful, for web-servers +that serve the public to verify the identity of every potential user. In +practice, most HTTPS transactions are asymmetric: the browser verifies +the HTTPS server's identity, but the user remains anonymous. Much of +the security policy is up to the client. If the client chooses to not +verify the server's name, the server is not aware of this. There are many +interesting browser security topics, but we shall not dwell +on them here. Rather, our goal is to understand the security features +of TLS in conjunction with SMTP.

+ +

An important SMTP-specific observation is that a public MX host is +even more at the mercy of the SMTP client than is an HTTPS server. Not only +can it not enforce due care in the client's use of TLS, but it cannot even +enforce the use of TLS, because TLS support in SMTP clients is still the +exception rather than the rule. One cannot, in practice, limit access to +one's MX hosts to just TLS-enabled clients. Such a policy would result +in a vast reduction in one's ability to communicate by email with the +world at large.

+ +

One may be tempted to try enforcing TLS for mail from specific +sending organizations, but this, too, runs into obstacles. One such +obstacle is that we don't know who is (allegedly) sending mail until +we see the "MAIL FROM:" SMTP command, and at that point, if TLS +is not already in use, a potentially sensitive sender address (and +with SMTP PIPELINING one or more of the recipients) has (have) already been +leaked in the clear. Another obstacle is that mail from the sender to +the recipient may be forwarded, and the forwarding organization may not +have any security arrangements with the final destination. Bounces also +need to be protected. These can only be identified by the IP address and +HELO name of the connecting client, and it is difficult to keep track +of all the potential IP addresses or HELO names of the outbound email +servers of the sending organization.

+ +

Consequently, TLS security for mail delivery to public MX hosts is +almost entirely the client's responsibility. The server is largely a +passive enabler of TLS security, the rest is up to the client. While the +server has a greater opportunity to mandate client security policy when +it is a dedicated MSA that only handles outbound mail from trusted clients, +below we focus on the client security policy.

+ +

On the SMTP client, there are further complications. When +delivering mail to a given domain, in contrast to HTTPS, one rarely +uses the domain name directly as the target host of the SMTP session. +More typically, one uses MX lookups — these are usually +unauthenticated — to obtain the domain's SMTP server hostname(s). +When, as is current practice, the client verifies the insecurely +obtained MX hostname, it is subject to a DNS man-in-the-middle +attack.

+ +

Adoption of DNSSEC and RFC6698 (DANE) may gradually (as domains +implement DNSSEC and publish TLSA records for their MX hosts) address +the DNS man-in-the-middle risk and provide scalable key management +for SMTP with TLS. Postfix ≥ 2.11 supports the new dane and dane-only +security levels that take advantage of these standards.

+ +

If clients instead attempted to verify the recipient domain name, +an SMTP server for multiple domains would need to +list all its email domain names in its certificate, and generate a +new certificate each time a new domain were added. At least some CAs set +fairly low limits (20 for one prominent CA) on the number of names that +server certificates can contain. This approach is not consistent with +current practice and does not scale.

+ +

It is regrettably the case that TLS secure-channels +(fully authenticated and immune to man-in-the-middle attacks) impose +constraints on the sending and receiving sites that preclude ubiquitous +deployment. One needs to manually configure this type of security for +each destination domain, and in many cases implement non-default TLS +policy table entries for additional +domains hosted at a common secured destination. For these reasons +secure-channel configurations +will never be the norm. For the generic domain with which you +have made no specific security arrangements, this security level is not +a good fit.

+ +

Given that strong authentication is not generally possible, and that +verifiable certificates cost time and money, many servers that implement +TLS use self-signed certificates or private CAs. This further limits +the applicability of verified TLS on the public Internet.

+ +

Historical note: while the documentation of these issues and many of the +related features were new with Postfix 2.3, the issue was well +understood before Postfix 1.0, when Lutz Jänicke was designing +the first unofficial Postfix TLS patch. See his original post http://www.imc.org/ietf-apps-tls/mail-archive/msg00304.html +and the first response http://www.imc.org/ietf-apps-tls/mail-archive/msg00305.html. +The problem is not even unique to SMTP or even TLS, similar issues exist +for secure connections via aliases for HTTPS and Kerberos. SMTP merely +uses indirect naming (via MX records) more frequently.

+ +

TLS policy table +

+ +

A small fraction of servers offer STARTTLS but the negotiation +consistently fails. As long as encryption is not mandatory, the +Postfix SMTP client retries the delivery immediately with TLS +disabled, without any need to explicitly disable TLS for the problem +destinations.

+ +

The policy table is specified via the smtp_tls_policy_maps +parameter. This lists optional lookup tables with the Postfix SMTP client +TLS security policy by next-hop destination.

+ +

The TLS policy table is indexed by the full next-hop destination, +which is either the recipient domain, or the verbatim next-hop +specified in the transport table, $local_transport, $virtual_transport, +$relay_transport or $default_transport. This includes any enclosing +square brackets and any non-default destination server port suffix. The +LMTP socket type prefix (inet: or unix:) +is not included in the lookup key.

+ +

Only the next-hop domain, or $myhostname with LMTP over UNIX-domain +sockets, is used as the nexthop name for certificate verification. The +port and any enclosing square brackets are used in the table lookup key, +but are not used for server name verification.

+ +

When the lookup key is a domain name without enclosing square brackets +or any :port suffix (typically the recipient domain), and the full +domain is not found in the table, just as with the transport(5) table, +the parent domain starting with a leading "." is matched recursively. This +allows one to specify a security policy for a recipient domain and all +its sub-domains.

+ +

The lookup result is a security level, followed by an optional +list of whitespace and/or comma separated name=value attributes +that override related main.cf settings. The TLS security levels are described above. Below, we +describe the corresponding table syntax:

+ +
+ +
none
No TLS. No +additional attributes are supported at this level.
+ +
may
Opportunistic TLS. +The optional "ciphers", "exclude" and "protocols" attributes +(available for opportunistic TLS with Postfix ≥ 2.6) override the +"smtp_tls_ciphers", "smtp_tls_exclude_ciphers" and "smtp_tls_protocols" +configuration parameters. At this level and higher, the optional +"servername" attribute (available with Postfix ≥ 3.4) overrides the +global "smtp_tls_servername" parameter, enabling per-destination +configuration of the SNI extension sent to the remote SMTP server.
+ +
encrypt
Mandatory encryption. +Mail is delivered only if the remote SMTP server offers STARTTLS +and the TLS handshake succeeds. At this level and higher, the optional +"protocols" attribute overrides the main.cf smtp_tls_mandatory_protocols +parameter, the optional "ciphers" attribute overrides the +main.cf smtp_tls_mandatory_ciphers parameter, and the optional +"exclude" attribute (Postfix ≥ 2.6) overrides the main.cf +smtp_tls_mandatory_exclude_ciphers parameter.
+ +
dane
Opportunistic DANE TLS. +The TLS policy for the destination is obtained via TLSA records in +DNSSEC. If no TLSA records are found, the effective security level +used is may. If TLSA records are +found, but none are usable, the effective security level is encrypt. When usable TLSA records +are obtained for the remote SMTP server, SSLv2+3 are automatically +disabled (see smtp_tls_mandatory_protocols), and the server certificate +must match the TLSA records. RFC 7672 (DANE) TLS authentication +and DNSSEC support is available with Postfix 2.11 and later.
+ +
dane-only
Mandatory DANE TLS. +The TLS policy for the destination is obtained via TLSA records in +DNSSEC. If no TLSA records are found, or none are usable, no +connection is made to the server. When usable TLSA records are +obtained for the remote SMTP server, SSLv2+3 are automatically disabled +(see smtp_tls_mandatory_protocols), and the server certificate must +match the TLSA records. RFC 7672 (DANE) TLS authentication and +DNSSEC support is available with Postfix 2.11 and later.
+ +
fingerprint
Certificate +fingerprint verification. Available with Postfix 2.5 and +later. At this security level, there are no trusted Certification +Authorities. The certificate trust chain, expiration date, ... are +not checked. Instead, the optional match attribute, or else +the main.cf smtp_tls_fingerprint_cert_match parameter, lists +the server certificate fingerprints or public key fingerprints +(Postfix 2.9 and later). The +digest algorithm used to calculate fingerprints is selected by the +smtp_tls_fingerprint_digest parameter. Multiple fingerprints can +be combined with a "|" delimiter in a single match attribute, or multiple +match attributes can be employed. The ":" character is not used as a +delimiter as it occurs between each pair of fingerprint (hexadecimal) +digits.
+ +
verify
Mandatory +server certificate verification. Mail is delivered only if the +TLS handshake succeeds, if the remote SMTP server certificate can +be validated (not expired or revoked, and signed by a trusted +Certification Authority), and if the server certificate name matches +the optional "match" attribute (or the main.cf smtp_tls_verify_cert_match +parameter value when no optional "match" attribute is specified). +With Postfix ≥ 2.11 the "tafile" attribute optionally modifies +trust chain verification in the same manner as the +"smtp_tls_trust_anchor_file" parameter. The "tafile" attribute +may be specified multiple times to load multiple trust-anchor +files.
+ +
secure
Secure certificate +verification. Mail is delivered only if the TLS handshake succeeds, +if the remote SMTP server certificate can be validated (not expired +or revoked, and signed by a trusted Certification Authority), and if the +server certificate name matches the optional "match" attribute (or the +main.cf smtp_tls_secure_cert_match parameter value when no optional +"match" attribute is specified). With Postfix ≥ 2.11 the "tafile" +attribute optionally modifies trust chain verification in the same manner +as the "smtp_tls_trust_anchor_file" parameter. The "tafile" attribute +may be specified multiple times to load multiple trust-anchor +files.
+ +
+ +

Notes:

+ + + +

+Example: +

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+    # Postfix 2.5 and later
+    smtp_tls_fingerprint_digest = md5
+/etc/postfix/tls_policy:
+    example.edu             none
+    example.mil             may
+    example.gov             encrypt ciphers=high
+    example.com             verify match=hostname:dot-nexthop ciphers=high
+    example.net             secure
+    .example.net            secure match=.example.net:example.net
+    [mail.example.org]:587  secure match=nexthop
+    # Postfix 2.5 and later
+    [thumb.example.org]         fingerprint
+    	match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+	match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+    # Postfix 2.6 and later
+    example.info            may protocols=!SSLv2 ciphers=medium exclude=3DES
+
+
+ +

Note: The "hostname" strategy if listed in a non-default setting +of smtp_tls_secure_cert_match or in the "match" attribute in the policy +table can render the "secure" level vulnerable to DNS forgery. Do not use +the "hostname" strategy for secure-channel +configurations in environments where DNS security is not assured.

+ +

Discovering servers that support +TLS

+ +

As we decide on a "per site" basis whether or not to use TLS, +it would be good to have a list of sites that offered "STARTTLS". +We can collect it ourselves with this option.

+ +

If the smtp_tls_note_starttls_offer feature is enabled and a +server offers STARTTLS while TLS is not already enabled for that +server, the Postfix SMTP client logs a line as follows:

+ +
+
+postfix/smtp[pid]: Host offered STARTTLS: [hostname.example.com]
+
+
+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_note_starttls_offer = yes
+
+
+ +

Server certificate verification depth

+ +

The server certificate verification depth is specified with the +main.cf smtp_tls_scert_verifydepth parameter. The default verification +depth is 9 (the OpenSSL default), for compatibility with Postfix +versions before 2.5 where smtp_tls_scert_verifydepth was ignored. +When you configure trust +in a root CA, it is not necessary to explicitly trust intermediary CAs +signed by the root CA, unless $smtp_tls_scert_verifydepth is less than the +number of CAs in the certificate chain for the servers of interest. With +a verify depth of 1 you can only verify certificates directly signed +by a trusted CA, and all trusted intermediary CAs need to be configured +explicitly. With a verify depth of 2 you can verify servers signed by a +root CA or a direct intermediary CA (so long as the server is correctly +configured to supply its intermediate CA certificate).

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_scert_verifydepth = 2
+
+
+ +

Client-side cipher controls

+ +

The Postfix SMTP client supports 5 distinct cipher grades +as specified by the smtp_tls_mandatory_ciphers configuration +parameter. This setting controls the minimum acceptable SMTP client +TLS cipher grade for use with mandatory TLS encryption. The default +value "medium" is suitable for most destinations with which you may +want to enforce TLS, and is beyond the reach of today's cryptanalytic +methods. See smtp_tls_policy_maps for information on how to configure +ciphers on a per-destination basis.

+ +

By default anonymous ciphers are allowed, and automatically +disabled when remote SMTP server certificates are verified. If you +want to +disable anonymous ciphers even at the "encrypt" security level, set +"smtp_tls_mandatory_exclude_ciphers = aNULL"; and to +disable anonymous ciphers even with opportunistic TLS, set +"smtp_tls_exclude_ciphers = aNULL". There is generally +no need to take these measures. Anonymous ciphers save bandwidth +and TLS session cache space, if certificates are ignored, there is +little point in requesting them.

+ +

The "smtp_tls_ciphers" configuration parameter (Postfix ≥ 2.6) +provides control over the minimum cipher grade for opportunistic TLS. +The default minimum cipher grade for opportunistic TLS is "medium" +for Postfix releases after the middle of 2015, and "export" for +older releases. With Postfix < 2.6, the minimum opportunistic +TLS cipher grade is always "export".

+ +

With mandatory and opportunistic TLS encryption, the Postfix +SMTP client will by default disable SSLv2 and SSLv3. The mandatory +TLS protocol list is specified via the +smtp_tls_mandatory_protocols configuration parameter. The corresponding +smtp_tls_protocols parameter (Postfix ≥ 2.6) controls +the SSL/TLS protocols used with opportunistic TLS.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_tls_mandatory_ciphers = medium
+    smtp_tls_mandatory_exclude_ciphers = RC4, MD5
+    smtp_tls_exclude_ciphers = aNULL
+    # Preferred form with Postfix ≥ 2.5:
+    smtp_tls_mandatory_protocols = !SSLv2
+    # Legacy form for Postfix < 2.5:
+    smtp_tls_mandatory_protocols = SSLv3, TLSv1
+    # Also available with Postfix ≥ 2.6:
+    smtp_tls_ciphers = medium
+    smtp_tls_protocols = !SSLv2
+
+
+ +

Client-side SMTPS support

+ +

These sections show how to send mail to a server that does not +support STARTTLS, but that provides the deprecated SMTPS service +on TCP port 465. Depending on the Postfix version, some additional +tooling may be required.

+ +

Postfix ≥ 3.0

+ +

The Postfix SMTP client has SMTPS support built-in as of version +3.0. Use one of the following examples, to send all remote mail, +or to send only some remote mail, to an SMTPS server.

+ +
Postfix ≥ 3.0: Sending all remote mail to an SMTPS server
+ +

The first example will send all remote mail over SMTPS through +a provider's server called "mail.example.com":

+ +
+
+/etc/postfix/main.cf:
+    # Client-side SMTPS requires "encrypt" or stronger.
+    smtp_tls_security_level = encrypt
+    smtp_tls_wrappermode = yes
+    # The [] suppress MX lookups.
+    relayhost = [mail.example.com]:465
+
+
+ +

Use "postfix reload" to make the change effective.

+ +

See SOHO_README for additional information about SASL authentication. +

+ +
Postfix ≥ 3.0: Sending only mail for a specific destination +via SMTPS
+ +

The second example will send only mail for "example.com" via +SMTPS. This time, Postfix uses a transport map to deliver only +mail for "example.com" via SMTPS:

+ +
+
+/etc/postfix/main.cf:
+    transport_maps = hash:/etc/postfix/transport
+
+/etc/postfix/transport:
+    example.com  relay-smtps:example.com:465
+
+/etc/postfix/master.cf:
+    relay-smtps  unix  -       -       n       -       -       smtp
+	# Client-side SMTPS requires "encrypt" or stronger.
+	-o smtp_tls_security_level=encrypt
+	-o smtp_tls_wrappermode=yes
+
+
+ +

Use "postmap hash:/etc/postfix/transport" and "postfix reload" +to make the change effective.

+ +

See SOHO_README for additional information about SASL +authentication.

+ +

Postfix < 3.0

+ +

Although older Postfix SMTP client versions do not support TLS +wrapper mode, it is relatively easy to forward a connection through +the stunnel program if Postfix needs to deliver mail to some legacy +system that doesn't support STARTTLS.

+ +
Postfix < 3.0: Sending all remote mail to an SMTPS server
+ +

The first example uses SMTPS to send all remote mail to a +provider's mail server called "mail.example.com".

+ +

A minimal stunnel.conf file is sufficient to set up a tunnel +from local port 11125 to the remote destination "mail.example.com" +and port "smtps". Postfix will later use this tunnel to connect to +the remote server.

+ +
+
+/path/to/stunnel.conf:
+    [smtp-tls-wrapper]
+    accept = 11125
+    client = yes
+    connect = mail.example.com:smtps
+
+
+ +

To test this tunnel, use:

+ +
+
+$ telnet localhost 11125
+
+
+ +

This should produce the greeting from the remote SMTP server +at mail.example.com.

+ +

On the Postfix side, the relayhost feature sends all remote +mail through the local stunnel listener on port 11125:

+ +
+
+/etc/postfix/main.cf:
+    relayhost = [127.0.0.1]:11125
+
+
+ +

Use "postfix reload" to make the change effective.

+ +

See SOHO_README for additional information about SASL +authentication.

+ +

Postfix < 3.0: Sending only mail for a specific destination via SMTPS

+ +

The second example will use SMTPS to send only mail for +"example.com" via SMTPS. It uses the same stunnel configuration +file as the first example, so it won't be repeated here.

+ +

This time, the Postfix side uses a transport map to direct only +mail for "example.com" through the tunnel:

+ +
+
+/etc/postfix/main.cf:
+    transport_maps = hash:/etc/postfix/transport
+
+/etc/postfix/transport:
+    example.com  relay:[127.0.0.1]:11125
+
+
+ +

Use "postmap hash:/etc/postfix/transport" and "postfix reload" +to make the change effective.

+ +

See SOHO_README for additional information about SASL authentication. +

+ +

Miscellaneous client controls

+ +

The smtp_starttls_timeout parameter limits the time of Postfix +SMTP client write and read operations during TLS startup and shutdown +handshake procedures. In case of problems the Postfix SMTP client +tries the next network address on the mail exchanger list, and +defers delivery if no alternative server is available.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    smtp_starttls_timeout = 300s
+
+
+ +

With Postfix 2.8 and later, the tls_disable_workarounds parameter +specifies a list or bit-mask of OpenSSL bug work-arounds to disable. This +may be necessary if one of the work-arounds enabled by default in +OpenSSL proves to pose a security risk, or introduces an unexpected +interoperability issue. Some bug work-arounds known to be problematic +are disabled in the default value of the parameter when linked with +an OpenSSL library that could be vulnerable.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_disable_workarounds = 0xFFFFFFFF
+    tls_disable_workarounds = CVE-2010-4180, LEGACY_SERVER_CONNECT
+
+
+ +

Note: Disabling LEGACY_SERVER_CONNECT is not wise at this +time, lots of servers are still unpatched and Postfix is not +significantly vulnerable to the renegotiation issue in the TLS +protocol.

+ +

With Postfix ≥ 2.11, the tls_ssl_options parameter specifies +a list or bit-mask of OpenSSL options to enable. Specify one or +more of the named options below, or a hexadecimal bitmask of options +found in the ssl.h file corresponding to the run-time OpenSSL +library. While it may be reasonable to turn off all bug workarounds +(see above), it is not a good idea to attempt to turn on all features. +

+ +

A future version of OpenSSL may by default no longer allow +connections to servers that don't support secure renegotiation. +Since the exposure for SMTP is minimal, and some SMTP servers may +remain unpatched, you can add LEGACY_SERVER_CONNECT to the +options to restore the more permissive default of current OpenSSL +releases.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_ssl_options = NO_TICKET, NO_COMPRESSION, LEGACY_SERVER_CONNECT
+
+
+ +

You should only enable features via the hexadecimal mask when +the need to control the feature is critical (to deal with a new +vulnerability or a serious interoperability problem). Postfix DOES +NOT promise backwards compatible behavior with respect to the mask +bits. A feature enabled via the mask in one release may be enabled +by other means in a later release, and the mask bit will then be +ignored. Therefore, use of the hexadecimal mask is only a temporary +measure until a new Postfix or OpenSSL release provides a better +solution.

+ +

TLS manager specific settings

+ +

The security of cryptographic software such as TLS depends +critically on the ability to generate unpredictable numbers for +keys and other information. To this end, the tlsmgr(8) process +maintains a Pseudo Random Number Generator (PRNG) pool. This is +queried by the smtp(8) and smtpd(8) processes when they initialize. +By default, these daemons request 32 bytes, the equivalent to 256 +bits. This is more than sufficient to generate a 128bit (or 168bit) +session key.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_daemon_random_bytes = 32
+
+
+ +

In order to feed its in-memory PRNG pool, the tlsmgr(8) reads +entropy from an external source, both at startup and during run-time. +Specify a good entropy source, like EGD or /dev/urandom; be sure +to only use non-blocking sources (on OpenBSD, use /dev/arandom +when tlsmgr(8) complains about /dev/urandom timeout errors). +If the entropy source is not a +regular file, you must prepend the source type to the source name: +"dev:" for a device special file, or "egd:" for a source with EGD +compatible socket interface.

+ +

Examples (specify only one in main.cf):

+ +
+
+/etc/postfix/main.cf:
+    tls_random_source = dev:/dev/urandom
+    tls_random_source = egd:/var/run/egd-pool
+
+
+ +

By default, tlsmgr(8) reads 32 bytes from the external entropy +source at each seeding event. This amount (256bits) is more than +sufficient for generating a 128bit symmetric key. With EGD and +device entropy sources, the tlsmgr(8) limits the amount of data +read at each step to 255 bytes. If you specify a regular file as +entropy source, a larger amount of data can be read.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_random_bytes = 32
+
+
+ +

In order to update its in-memory PRNG pool, the tlsmgr(8) +queries the external entropy source again after a pseudo-random +amount of time. The time is calculated using the PRNG, and is +between 0 and the maximal time specified with tls_random_reseed_period. +The default maximal time interval is 1 hour.

+ +

Example:

+ +
+
+/etc/postfix/main.cf:
+    tls_random_reseed_period = 3600s
+
+
+ +

The tlsmgr(8) process saves the PRNG state to a persistent +exchange file at regular times and when the process terminates, so +that it can recover the PRNG state the next time it starts up. +This file is created when it does not exist.

+ +

Examples:

+ +
+
+/etc/postfix/main.cf:
+    tls_random_exchange_name = /var/lib/postfix/prng_exch
+    tls_random_prng_update_period = 3600s
+
+
+ +

As of version 2.5, Postfix no longer uses root privileges when +opening this file. The file should now be stored under the Postfix-owned +data_directory. As a migration aid, an attempt to open the file +under a non-Postfix directory is redirected to the Postfix-owned +data_directory, and a warning is logged. If you wish to continue +using a pre-existing PRNG state file, move it to the data_directory +and change the ownership to the account specified with the mail_owner +parameter.

+ +

With earlier Postfix versions the default file location +is under the Postfix configuration directory, which is not the +proper place for information that is modified by Postfix.

+ +

Getting started, quick and dirty

+ +

The following steps will get you started quickly. Because you +sign your own Postfix public key certificate, you get TLS encryption +but no TLS authentication. This is sufficient for testing, and +for exchanging email with sites that you have no trust relationship +with. For real authentication you need also enable DNSSEC record +signing for your domain and publish TLSA records and/or your Postfix +public key certificate needs to be signed by a recognized Certification +Authority. To authenticate the certificates of remote host you +need a DNSSEC-validating local resolver and to enable DANE authentication and/or configure +the Postfix SMTP client with a list of public key certificates of +Certification Authorities, but make sure to read about the limitations of the latter approach. +

+ +

In the examples below, user input is shown in bold +font, and a "#" prompt indicates a super-user shell.

+ + + +

Quick-start TLS with Postfix ≥ 3.1

+ +

Postfix 3.1 provides built-in support for enabling TLS in the +SMTP client and server and for ongoing certificate and DANE TLSA +record management. + +

+ +

Quick-start TLS in the Postfix ≥ 3.1 SMTP client.

+ +

If you are using Postfix 3.1 or later, and your SMTP client TLS +settings are in their default state, you can enable opportunistic TLS in the SMTP client as +follows:

+ +
+
+# postfix tls enable-client
+# postfix reload
+
+
+ +

If some of the Postfix SMTP client TLS settings are not in their +default state, this will not make any changes, but will instead +suggest the minimal required settings for SMTP client TLS. The +"postfix reload" command is optional, it is only needed if you want +the settings to take effect right away. Note, this does not enable +trust in any public certification authorities, and does not configure +client TLS certificates as these are largely pointless with opportunistic TLS.

+ +

There is not yet a turn-key command for enabling DANE authentication. This is because +DANE requires changes to your resolv.conf file and a +corresponding DNSSEC-validating resolver local to the Postfix host, +these changes are difficult to automate in a portable way.

+ +

If you're willing to revert your settings to the defaults and +switch to a "stock" opportunistic TLS configuration, then you can: +erase all the SMTP client TLS settings and then enable client TLS:

+ +
+
+# postconf -X `postconf -nH | egrep '^smtp(_|_enforce_|_use_)tls'`
+# postfix tls enable-client
+# postfix reload
+
+
+ +

Quick-start TLS in the Postfix ≥ 3.1 SMTP server.

+ +

If you are using Postfix 3.1 or later, and your SMTP server TLS +settings are in their default state, you can enable +opportunistic TLS in the SMTP server as follows:

+ +
+
+# postfix tls enable-server
+# postfix reload
+
+
+ +

If some of the Postfix SMTP client TLS settings are not in their +default state, this will not make any changes, but will instead +suggest the minimal required settings for SMTP client TLS. The +"postfix reload" command is optional, it is only needed if you want +the settings to take effect right away. This will generate a +self-signed private key and certificate and enable TLS in the Postfix +SMTP server.

+ +

If you're willing to revert your settings to the defaults and +switch to a "stock" server TLS configuration, then you can: erase +all the SMTP server TLS settings and then enable server TLS:

+ +
+
+# postconf -X `postconf -nH | egrep '^smtpd(_|_enforce_|_use_)tls'`
+# postfix tls enable-server
+# postfix reload
+
+
+ +

Postfix ≥ 3.1 provides additional built-in support for ongoing +management of TLS in the SMTP server, via additional "postfix tls" +sub-commands. These make it easy to generate certificate signing +requests, create and deploy new keys and certificates, and generate +DANE TLSA records. See the postfix-tls(1) documentation for details. +

+ +

Self-signed server certificate

+ +

The following commands (credits: Viktor Dukhovni) generate and +install a 2048-bit RSA private key and 10-year self-signed certificate +for the local Postfix system. This requires super-user privileges. +(By using date-specific filenames for the certificate and key files, +and updating main.cf with new filenames, a potential race condition +in which the key and certificate might not match is avoided). +

+ +
+
+# dir="$(postconf -h config_directory)"
+# fqdn=$(postconf -h myhostname)
+# case $fqdn in /*) fqdn=$(cat "$fqdn");; esac
+# ymd=$(date +%Y-%m-%d)
+# key="${dir}/key-${ymd}.pem"; rm -f "${key}"
+# cert="${dir}/cert-${ymd}.pem"; rm -f "${cert}"
+# (umask 077; openssl genrsa -out "${key}" 2048) &&
+  openssl req -new -key "${key}" \
+    -x509 -subj "/CN=${fqdn}" -days 3650 -out "${cert}" &&
+  postconf -e \
+    "smtpd_tls_cert_file = ${cert}" \
+    "smtpd_tls_key_file = ${key}" \
+    'smtpd_tls_security_level = may' \
+    'smtpd_tls_received_header = yes' \
+    'smtpd_tls_loglevel = 1' \
+    'smtp_tls_security_level = may' \
+    'smtp_tls_loglevel = 1' \
+    'smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache' \
+    'tls_random_source = dev:/dev/urandom'
+
+
+ +

Note: the last command requires both single (') and double (") +quotes.

+ +

The postconf(1) command above enables opportunistic TLS for +receiving and sending mail. It also enables logging of TLS connections +and recording of TLS use in the "Received" header. TLS session +caching is also enabled in the Postfix SMTP client. With Postfix +≥ 2.10, the SMTP server does not need an explicit session cache +since session reuse is better handled via RFC 5077 TLS session +tickets.

+ +

Private Certification Authority

+ + + + +

Building Postfix with TLS support

+ +

These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

+ +

To build Postfix with TLS support, first we need to generate +the make(1) files with the necessary definitions. This is +done by invoking the command "make makefiles" in the Postfix +top-level directory and with arguments as shown next.

+ +

NOTE: Do not use Gnu TLS. It will spontaneously terminate +a Postfix daemon process with exit status code 2, instead of allowing +Postfix to 1) report the error to the maillog file, and to 2) provide +plaintext service where this is appropriate.

+ + + +

If you need to apply other customizations (such as Berkeley DB +databases, MySQL, PostgreSQL, LDAP or SASL), see the respective +Postfix README documents, and combine their "make makefiles" +instructions with the instructions above:

+ +
+
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_TLS \
+    (other -D or -I options)" \
+    AUXLIBS="-lssl -lcrypto \
+    (other -l options for libraries in /usr/lib) \
+    (-L/path/name + -l options for other libraries)"
+
+
+ +

To complete the build process, see the Postfix INSTALL +instructions. Postfix has TLS support turned off by default, so +you can start using Postfix as soon as it is installed.

+ +

Reporting problems

+ +

Problems are preferably reported via <postfix-users@postfix.org>. +See http://www.postfix.org/lists.html for subscription information. +When reporting a problem, please be thorough in the report. Patches, +when possible, are greatly appreciated too.

+ +

Credits

+ + + + + + diff --git a/proto/TUNING_README.html b/proto/TUNING_README.html new file mode 100644 index 0000000..c5641f2 --- /dev/null +++ b/proto/TUNING_README.html @@ -0,0 +1,704 @@ + + + + + + +Postfix Performance Tuning + + + + + + + +

+Postfix Performance Tuning

+ +
+ +

Purpose of Postfix performance tuning

+ +

The hints and tips in this document help you improve the +performance of Postfix systems that already work. If your Postfix +system is unable to receive or deliver mail, then you need to solve +those problems first, using the DEBUG_README document as guidance. + +

For tuning external content filter performance, first read the +respective information in the FILTER_README and SMTPD_PROXY_README +documents. Then make sure to avoid latency in the content filter +code. As much as possible avoid performing queries against external +data sources with a high or highly variable delay. Your content +filter will run with a small concurrency to avoid CPU/memory +starvation, and if any latency creeps in, content filter throughput +will suffer. High volume environments should avoid RBL lookups, +complex database queries and so on.

+ +

Topics on mail receiving performance:

+ + + +

Topics on mail delivery performance:

+ + + +

Other Postfix performance tuning topics:

+ + + +

The following tools can be used to measure mail system performance +under artificial loads. They are normally not installed with Postfix. +

+ + + +

General mail receiving performance +tips

+ + + +

When Postfix responds slowly to SMTP clients:

+ + + +

Doing more work with your SMTP server +processes

+ +

With Postfix versions 2.0 and earlier, the smtpd(8) server +pauses before reporting an error to an SMTP client. The idea is +called tar pitting. However, these delays also slow down Postfix. +When the smtpd(8) server replies slowly, sessions take more time, +so that more smtpd(8) server processes are needed to handle the +load. When your Postfix smtpd(8) server process limit is reached, +new clients must wait until a server process becomes available. +This means that all clients experience poor performance.

+ +

You can speed up the handling of smtpd(8) server error replies +by turning off the delay:

+ +
+
+/etc/postfix/main.cf:
+    # Not needed with Postfix 2.1
+    smtpd_error_sleep_time = 0
+
+
+ +

With the above setting, Postfix 2.0 and earlier can serve more +SMTP clients with the same number SMTP server processes. The next +section describes how Postfix deals with clients that make a large +number of errors.

+ +

Slowing down SMTP clients that make many errors

+ +

The Postfix smtpd(8) server maintains a per-session error count. +The error count is reset when a message is transferred successfully, +and is incremented when a client request is unrecognized or +unimplemented, when a client request violates access restrictions, or when +some other error happens.

+ +

As the per-session error count increases, the smtpd(8) server +changes behavior and begins to insert delays into the responses. +The idea is to slow down a run-away client in order to limit resource +usage. The behavior is Postfix version dependent.

+ +

IMPORTANT: These delays slow down Postfix, too. When too much +delay is configured, the number of simultaneous SMTP sessions will +increase until it reaches the smtpd(8) server process limit, and new +SMTP clients must wait until an smtpd(8) server process becomes available. +

+ +

Postfix version 2.1 and later:

+ + + +

Postfix version 2.0 and earlier:

+ + + +

Measures against clients that make too many connections

+ +

Note: these features use the Postfix anvil(8) service, introduced +with Postfix version 2.2.

+ +

The Postfix smtpd(8) server can limit the number of simultaneous +connections from the same SMTP client, as well as the connection +rate and the rate of certain SMTP commands from the same client. +These statistics are maintained by the anvil(8) server (translation: +if anvil(8) breaks, then connection limits stop working).

+ +

IMPORTANT: These limits must not be used to regulate legitimate +traffic: mail will suffer grotesque delays if you do so. The limits +are designed to protect the smtpd(8) server against abuse by +out-of-control clients.

+ +
+ +
+ +
smtpd_client_connection_count_limit (default: 50)
+The maximum number of connections that an SMTP client may make +simultaneously.
+ +
smtpd_client_connection_rate_limit (default: no limit)
+
The maximum number of connections that an SMTP client may make +in the time interval specified with anvil_rate_time_unit (default: +60s).
+ +
smtpd_client_message_rate_limit (default: no limit)
+The maximum number of message delivery requests that an SMTP client +may make in the time interval specified with anvil_rate_time_unit +(default: 60s).
+ +
smtpd_client_recipient_rate_limit (default: no limit)
+
The maximum number of recipient addresses that an SMTP client +may specify in the time interval specified with anvil_rate_time_unit +(default: 60s).
+ +
smtpd_client_new_tls_session_rate_limit (default: no limit) +
The maximum number of new TLS sessions (without using +the TLS session cache) that an SMTP client may negotiate in the +time interval specified with anvil_rate_time_unit (default: 60s). +
+ +
smtpd_client_auth_rate_limit (default: no limit)
+The maximum number of AUTH commands that an SMTP client may send +in the time interval specified with anvil_rate_time_unit (default: +60s). Available in Postfix 3.1 and later.
+ +
smtpd_client_event_limit_exceptions (default: $mynetworks) +
SMTP clients that are excluded from connection and rate +limits specified above.
+ +
+ +
+ +

General mail delivery performance tips

+ + + +

Tuning the number of simultaneous deliveries

+ +

Although Postfix can be configured to run 1000 SMTP client +processes at the same time, it is rarely desirable that it makes +1000 simultaneous connections to the same remote system. For this +reason, Postfix has safety mechanisms in place to avoid this +so-called "thundering herd" problem.

+ +

The Postfix queue manager implements the analog of the TCP slow +start flow control strategy: when delivering to a site, send a +small number of messages first, then increase the concurrency as +long as all goes well; reduce concurrency in the face of congestion. +

+ + + +

Examples of transport specific concurrency limits are:

+ + + +

The above default values of the concurrency limits work well +in a broad range of situations. Knee-jerk changes to these parameters +in the face of congestion can actually make problems worse. +Specifically, large destination concurrencies should never be the +default. They should be used only for transports that deliver mail +to a small number of high volume domains.

+ +

A common situation where high concurrency is called for is on +gateways relaying a high volume of mail between the Internet +and an intranet mail environment. Approximately half the mail +(assuming equal volumes inbound and outbound) will be destined +for the internal mail hubs. Since the internal mail hubs will be +receiving all external mail exclusively from the gateway, it is +reasonable to configure the gateway to make greater demands on the +capacity of the internal SMTP servers.

+ +

The tuning of the inbound concurrency limits need not be trial +and error. A high volume capable mailhub should be able to easily +handle 50 or 100 (rather than the default 20) simultaneous connections, +especially if the gateway forwards to multiple MX hosts. When all +MX hosts are up and accepting connections in a timely fashion, +throughput will be high. If any MX host is down and completely +unresponsive, the average connection latency rises to at least 1/N +* $smtp_connection_timeout, if there are N MX hosts. This limits +throughput to at most the destination concurrency * N / +$smtp_connection_timeout.

+ +

For example, with a destination concurrency of 100 and 2 MX +hosts, each host will handle up to 50 simultaneous connections. If +one MX host is down and the default SMTP connection timeout is 30s, +the throughput limit is 100 * 2 / 30 ~= 6 messages per second. This +suggests that high volume destinations with good connectivity and +multiple MX hosts need a lower connection timeout, values as low +as 5s or even 1s can be used to prevent congestion when one or +more, but not all MX hosts are down.

+ +

If necessary, set a higher transport_destination_concurrency_limit +(in main.cf since this is a queue manager parameter) and a lower +smtp_connection_timeout (with a "-o" override in master.cf since +this parameter has no per-transport name) for the relay transport +and any transports dedicated for specific high volume destinations. +

+ +

Tuning the number of recipients per delivery

+ +

The default_destination_recipient_limit parameter (default: +50) controls how many recipients a Postfix delivery agent will send +with each copy of an email message. You can override this setting +for specific Postfix delivery agents. For example, +"uucp_destination_recipient_limit = 100" would limit the number of +recipients per UUCP delivery to 100.

+ +

If an email message exceeds the recipient limit for some +destination, the Postfix queue manager breaks up the list of +recipients into smaller lists. Postfix will attempt to send multiple +copies of the message in parallel.

+ +

IMPORTANT: Be careful when increasing the recipient limit per +message delivery; some SMTP servers abort the connection when they +run out of memory or when a hard recipient limit is reached, so +that the message will never be delivered.

+ +

The smtpd_recipient_limit parameter (default: 1000) controls +how many recipients the Postfix smtpd(8) server will take per +delivery. The default limit is more than any reasonable SMTP client +would send. The limit exists to protect the local mail system +against a run-away client.

+ +

Tuning the frequency of deferred mail delivery attempts

+ +

When a Postfix delivery agent (smtp(8), local(8), etc.) is +unable to deliver a message it may blame the message itself, or it +may blame the receiving party.

+ + + +

This process is governed by a bunch of little parameters.

+ +
+ +
+ +
queue_run_delay (default: 300 seconds; before Postfix 2.4: +1000s)
How often +the queue manager scans the queue for deferred mail.
+ +
minimal_backoff_time (default: 300 seconds; before Postfix +2.4: 1000s)
The +minimal amount of time a message won't be looked at, and the minimal +amount of time to stay away from a "dead" destination.
+ +
maximal_backoff_time (default: 4000 seconds)
The +maximal amount of time a message won't be looked at after a delivery +failure.
+ +
maximal_queue_lifetime (default: 5 days)
How long +a message stays in the queue before it is sent back as undeliverable. +Specify 0 for mail that should be returned immediately after the +first unsuccessful delivery attempt.
+ +
bounce_queue_lifetime (default: 5 days, available with Postfix +version 2.1 and later)
How long a MAILER-DAEMON message +stays in the queue before it is considered undeliverable. Specify +0 for mail that should be tried only once.
+ +
qmgr_message_recipient_limit (default: 20000)
The +size of many in-memory queue manager data structures. Among others, +this parameter limits the size of the short-term, in-memory list +of "dead" destinations. Destinations that don't fit the list are +not added.
+ +
transport_destination_concurrency_failed_cohort_limit +
Controls when a destination is considered "dead". This +parameter is critical with a non-zero +transport_destination_rate_delay, with a reduced +transport_destination_concurrency_limit, or with +a reduced initial_destination_concurrency.
+ +
+ +
+ +

IMPORTANT: If you increase the frequency of deferred mail +delivery attempts, or if you flush the deferred mail queue frequently, +then you may find that Postfix mail delivery performance actually +becomes worse. The symptoms are as follows:

+ + + +

When mail is being deferred frequently, fixing the problem is +always better than increasing the frequency of delivery attempts. +However, if you can control only the delivery attempt frequency, +consider using a dedicated fallback_relay "graveyard" machine for +bad destinations, so that these destinations do not ruin the +performance of normal +mail deliveries.

+ +

Tuning the number of Postfix processes

+ +

The default_process_limit configuration parameter gives direct +control over how many daemon processes Postfix will run. As of +Postfix 2.0 the default limit is 100 SMTP client processes, 100 +SMTP server processes, and so on. This may overwhelm systems with +little memory, as well as networks with low bandwidth.

+ +

You can change the global process limit by specifying a +non-default default_process_limit in the main.cf file. For example, +to run up to 10 SMTP client processes, 10 SMTP server processes, +and so on:

+ +
+
+/etc/postfix/main.cf:
+    default_process_limit = 10
+
+
+ +

You need to execute "postfix reload" to make the change effective. +This limit is enforced by the Postfix master(8) daemon which does +not automatically read main.cf when it changes.

+ +

You can override the process limit for specific Postfix daemons +by editing the master.cf file. For example, if you do not wish to +receive 100 SMTP messages at the same time, but do not want to +change the process limits for other Postfix daemons, you could +specify:

+ +
+
+/etc/postfix/master.cf:
+    # ====================================================================
+    # service type  private unpriv  chroot  wakeup  maxproc command + args
+    #               (yes)   (yes)   (yes)   (never) (100)
+    # ====================================================================
+    . . .
+    smtp      inet  n       -       -       -       10      smtpd
+    . . .
+
+
+ +

Tuning the number of processes on the system

+ + + +

Tuning the number of open files or sockets

+ +

When Postfix opens too many files or sockets, processes will +abort with fatal errors, and the system may log "file table full" +errors.

+ + + + + + diff --git a/proto/UUCP_README.html b/proto/UUCP_README.html new file mode 100644 index 0000000..c614cee --- /dev/null +++ b/proto/UUCP_README.html @@ -0,0 +1,200 @@ + + + + + + +Postfix and UUCP + + + + + + + +

Postfix and UUCP

+ +
+ +

Using UUCP over TCP

+ +

Despite a serious lack of sex-appeal, email via UUCP over TCP +is a practical option for sites without permanent Internet connections, +and for sites without a fixed IP address. For first-hand information, +see the following guides:

+ + + +Here's a graphical description of what this document is about: + +
+ + + + + + + + + + + + + +
Local network <---> LAN to
+UUCP
Gateway		 <--- UUCP ---> Internet
+to UUCP
Gateway		 <---> Internet
+ +
+ +

And here's the table of contents of this document:

+ + + +

Setting up a Postfix Internet to UUCP +gateway

+ +

Here is how to set up a machine that sits on the Internet and +that forwards mail to a LAN that is connected via UUCP. See +the LAN to UUCP gateway section for +the other side of the story.

+ + + +

Setting up a Postfix LAN to UUCP +gateway

+ +

Here is how to relay mail from a LAN via UUCP to the +Internet. See the Internet to UUCP +gateway section for the other side of the story.

+ + + + + + diff --git a/proto/VERP_README.html b/proto/VERP_README.html new file mode 100644 index 0000000..a4b1b38 --- /dev/null +++ b/proto/VERP_README.html @@ -0,0 +1,289 @@ + + + + + + +Postfix VERP Howto + + + + + + + +

Postfix VERP Howto

+ +
+ +

Postfix VERP support

+ +

Postfix versions 1.1 and later support variable envelope return +path addresses on request. When VERP style delivery is requested, +each recipient of a message receives a customized copy of the +message, with his/her own recipient address encoded in the envelope +sender address.

+ +

For example, when VERP style delivery is requested, Postfix +delivers mail from "owner-listname@origin" for a recipient +"user@domain", with a sender address that encodes the +recipient as follows:

+ +
+
+owner-listname+user=domain@origin
+
+
+ +

Thus, undeliverable mail can reveal the undeliverable recipient +address without requiring the list owner to parse bounce messages. +

+ +

The VERP concept was popularized by the qmail MTA and by the ezmlm +mailing list manager. See http://cr.yp.to/proto/verp.txt for the +ideas behind this concept.

+ +

Topics covered in this document:

+ + + +

Postfix VERP configuration parameters

+ +With Postfix, the whole process is controlled by four configuration +parameters. + +
+ +
default_verp_delimiters (default value: +=) + +

What VERP delimiter characters Postfix uses when VERP + style delivery is requested but no explicit delimiters are + specified.

+ +
verp_delimiter_filter (default: -+=) + +

What characters Postfix accepts as VERP delimiter + characters on the sendmail command line and in SMTP commands. + Many characters must not be used as VERP delimiter characters, + either because they already have a special meaning in email + addresses (such as the @ or the %), because they are used as + part of a username or domain name (such as alphanumerics), or + because they are non-ASCII or control characters. And who + knows, some characters may tickle bugs in vulnerable software, + and we would not want that to happen.

+ +
smtpd_authorized_verp_clients (default value: none) + +

What SMTP clients are allowed to request VERP style + delivery. The Postfix QMQP server uses its own access control + mechanism, and local submission (via /usr/sbin/sendmail etc.) + is always authorized. To authorize a host, list its name, IP + address, subnet (net/mask) or parent .domain.

+ +

With Postfix versions 1.1 and 2.0, this parameter is called + authorized_verp_clients (default: $mynetworks).

+ +
disable_verp_bounces (default: no) + +

Send one bounce report for multi-recipient VERP mail, + instead of one bounce report per recipient. The default, + one per recipient, is what ezmlm needs.

+ +
+ +

Using VERP with majordomo etc. mailing lists

+ +

In order to make VERP useful with majordomo etc. mailing lists, +you would configure the list manager to submit mail according +to one of the following two forms:

+ +

Postfix 2.3 and later:

+ +
+
+% sendmail -XV -f owner-listname other-arguments...
+
+% sendmail -XV+= -f owner-listname other-arguments...
+
+
+ +

Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax +for backwards compatibility, but will log a warning that reminds +you of the new syntax):

+ +
+
+% sendmail -V -f owner-listname other-arguments...
+
+% sendmail -V+= -f owner-listname other-arguments...
+
+
+ +

The first form uses the default main.cf VERP delimiter characters. +The second form allows you to explicitly specify the VERP delimiter +characters. The example shows the recommended values.

+ +

This text assumes that you have set up an owner-listname alias +that routes undeliverable mail to a real person:

+ +
+
+/etc/aliases:
+    owner-listname: yourname+listname
+
+
+ +

In order to process bounces we are going to make extensive use +of address extension tricks.

+ +

You need to tell Postfix that + is the separator between an +address and its optional address extension, that address extensions +are appended to .forward file names, and that address extensions +are to be discarded when doing alias expansions:

+ +
+
+/etc/postfix/main.cf:
+    recipient_delimiter = +
+    forward_path = $home/.forward${recipient_delimiter}${extension},
+        $home/.forward
+    propagate_unmatched_extensions = canonical, virtual
+
+
+ +

(the last two parameter settings are default settings).

+ +

You need to set up a file named .forward+listname with the +commands that process all the mail that is sent to the owner-listname +address:

+ +
+
+~/.forward+listname:
+    "|/some/where/command ..."
+
+
+ +

With this set up, undeliverable mail for user@domain will be returned +to the following address:

+ +
+
+owner-listname+user=domain@your.domain
+
+
+ +

which is processed by the command in your .forward+listname file. +The message should contain, among others, a To: header with the +encapsulated recipient sender address:

+ +
+
+To: owner-listname+user=domain@your.domain
+
+
+ +

It is left as an exercise for the reader to parse the To: header +line and to pull out the user=domain part from the recipient address. +

+ +

VERP support in the Postfix SMTP server

+ +

The Postfix SMTP server implements a command XVERP to enable +VERP style delivery. The syntax allows two forms:

+ +
+
+MAIL FROM:<sender@domain> XVERP
+
+MAIL FROM:<sender@domain> XVERP=+=
+
+
+ +

The first form uses the default main.cf VERP delimiters, the +second form overrides them explicitly. The values shown are the +recommended ones.

+ +

You can use the smtpd_command_filter feature to append XVERP +to SMTP commands from legacy software. This requires Postfix 2.7 +or later.

+ +
+
+/etc/postfix/main.cf:
+    smtpd_command_filter = pcre:/etc/postfix/append_verp.pcre
+    smtpd_authorized_verp_clients = $mynetworks
+
+/etc/postfix/append_verp.pcre:
+    /^(MAIL FROM:<listname@example\.com>.*)/ $1 XVERP
+
+
+ +

VERP support in the Postfix sendmail command

+ +

The Postfix sendmail command has a -V flag to request VERP style +delivery. Specify one of the following two forms:

+ +

Postfix 2.3 and later:

+
+
+% sendmail -XV -f owner-listname ....
+
+% sendmail -XV+= -f owner-listname ....
+
+
+ +

Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax +for backwards compatibility, but will log a warning that reminds +you of the new syntax):

+ +
+
+% sendmail -V -f owner-listname ....
+
+% sendmail -V+= -f owner-listname ....
+
+
+ +

The first form uses the default main.cf VERP delimiters, the +second form overrides them explicitly. The values shown are the +recommended ones.

+ +

VERP support in the Postfix QMQP server

+ +

When the Postfix QMQP server receives mail with an envelope +sender address of the form:

+ +
+
+listname-@your.domain-@[]
+
+
+ +

Postfix generates sender addresses +"listname-user=domain@your.domain", using "-=" as the VERP +delimiters because qmail/ezmlm expect this.

+ +

More generally, a sender address of "prefix@origin-@[]" +requests VERP style delivery with sender addresses of the form +"prefixuser=domain@origin". However, Postfix allows only +VERP delimiters that are specified with the verp_delimiter_filter +parameter. In particular, the "=" delimiter is required for qmail +compatibility (see the qmail addresses(5) manual page for details). + + + + diff --git a/proto/VIRTUAL_README.html b/proto/VIRTUAL_README.html new file mode 100644 index 0000000..ac11f19 --- /dev/null +++ b/proto/VIRTUAL_README.html @@ -0,0 +1,648 @@ + + + + + + +Postfix Virtual Domain Hosting Howto + + + + + + + +

Postfix +Virtual Domain Hosting Howto

+ +
+ +

Purpose of this document

+ +

This document requires Postfix version 2.0 or later.

+ +

This document gives an overview of how Postfix can be used for +hosting multiple Internet domains, both for final delivery on the +machine itself and for the purpose of forwarding to destinations +elsewhere.

+ +

The text not only describes delivery mechanisms that are built +into Postfix, but also gives pointers for using non-Postfix mail +delivery software.

+ +

The following topics are covered:

+ + + +

Canonical versus hosted versus +other domains

+ +

Most Postfix systems are final destination for only a +few domain names. These include the hostnames and [the IP addresses] +of the machine that Postfix runs on, and sometimes also include +the parent domain of the hostname. The remainder of this document +will refer to these domains as the canonical domains. They are +usually implemented with the Postfix local domain address class, +as defined in the ADDRESS_CLASS_README file.

+ +

Besides the canonical domains, Postfix can be configured to be +final destination for any number of additional domains. +These domains are called hosted, because they are not directly +associated with the name of the machine itself. Hosted domains are +usually implemented with the virtual alias domain address class +and/or with the virtual mailbox domain address class, as defined +in the ADDRESS_CLASS_README file.

+ +

But wait! There is more. Postfix can be configured as a backup +MX host for other domains. In this case Postfix is not the final +destination for those domains. It merely queues the mail when +the primary MX host is down, and forwards the mail when the primary +MX host becomes available. This function is implemented with the +relay domain address class, as defined in the ADDRESS_CLASS_README +file.

+ +

Finally, Postfix can be configured as a transit host for sending +mail across the internet. Obviously, Postfix is not final destination +for such mail. This function is available only for authorized +clients and/or users, and is implemented by the default domain +address class, as defined in the ADDRESS_CLASS_README file.

+ +

Local files versus network databases

+ +

The examples in this text use table lookups from local files +such as DBM or Berkeley DB. These are easy to debug with the +postmap command:

+ +
+Example: postmap -q info@example.com hash:/etc/postfix/virtual +
+ +

See the documentation in LDAP_README, MYSQL_README and PGSQL_README +for how to replace local files by databases. The reader is strongly +advised to make the system work with local files before migrating +to network databases, and to use the postmap command to verify +that network database lookups produce the exact same results as +local file lookup.

+ +
+Example: postmap -q info@example.com ldap:/etc/postfix/virtual.cf +
+ +

As simple as can be: shared domains, UNIX system +accounts

+ +

The simplest method to host an additional domain is to add the +domain name to the domains listed in the Postfix mydestination +configuration parameter, and to add the user names to the UNIX +password file.

+ +

This approach makes no distinction between canonical and hosted +domains. Each username can receive mail in every domain.

+ +

In the examples we will use "example.com" as the domain that is +being hosted on the local Postfix machine.

+ +
+
+/etc/postfix/main.cf:
+    mydestination = $myhostname localhost.$mydomain ... example.com
+
+
+ +

The limitations of this approach are:

+ + + +

The examples that follow provide solutions for both limitations. +

+ +

Postfix virtual ALIAS example: +separate domains, UNIX system accounts

+ +

With the approach described in this section, every hosted domain +can have its own info etc. email address. However, it still uses +UNIX system accounts for local mailbox deliveries.

+ +

With virtual alias domains, each hosted address is aliased to +a local UNIX system account or to a remote address. The example +below shows how to use this mechanism for the example.com domain. +

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     virtual_alias_domains = example.com ...other hosted domains...
+ 3     virtual_alias_maps = hash:/etc/postfix/virtual
+ 4 
+ 5 /etc/postfix/virtual:
+ 6     postmaster@example.com postmaster
+ 7     info@example.com       joe
+ 8     sales@example.com      jane
+ 9     # Uncomment entry below to implement a catch-all address
+10     # @example.com         jim
+11     ...virtual aliases for more domains...
+
+
+ +

Notes:

+ + + +

Execute the command "postmap /etc/postfix/virtual" after +changing the virtual file, and execute the command "postfix +reload" after changing the main.cf file.

+ +

Note: virtual aliases can resolve to a local address or to a +remote address, or both. They don't have to resolve to UNIX system +accounts on your machine.

+ +

More details about the virtual alias file are given in the +virtual(5) manual page, including multiple addresses on the right-hand +side.

+ +

Virtual aliasing solves one problem: it allows each domain to +have its own info mail address. But there still is one drawback: +each virtual address is aliased to a UNIX system account. As you +add more virtual addresses you also add more UNIX system accounts. +The next section eliminates this problem.

+ +

Postfix virtual MAILBOX example: +separate domains, non-UNIX accounts

+ +

As a system hosts more and more domains and users, it becomes less +desirable to give every user their own UNIX system account.

+ +

With the Postfix virtual(8) mailbox delivery agent, every +recipient address can have its own virtual mailbox. Unlike virtual +alias domains, virtual mailbox domains do not need the clumsy +translation from each recipient addresses into a different address, +and owners of a virtual mailbox address do not need to have a UNIX +system account.

+ +

The Postfix virtual(8) mailbox delivery agent looks up the user +mailbox pathname, uid and gid via separate tables that are searched +with the recipient's mail address. Maildir style delivery is turned +on by terminating the mailbox pathname with "/".

+ +

If you find the idea of multiple tables bothersome, remember +that you can migrate the information (once it works), to an SQL +database. If you take that route, be sure to review the "local files versus databases" +section at the top of this document.

+ +

Here is an example of a virtual mailbox domain "example.com": +

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     virtual_mailbox_domains = example.com ...more domains...
+ 3     virtual_mailbox_base = /var/mail/vhosts
+ 4     virtual_mailbox_maps = hash:/etc/postfix/vmailbox
+ 5     virtual_minimum_uid = 100
+ 6     virtual_uid_maps = static:5000
+ 7     virtual_gid_maps = static:5000
+ 8     virtual_alias_maps = hash:/etc/postfix/virtual
+ 9 
+10 /etc/postfix/vmailbox:
+11     info@example.com    example.com/info
+12     sales@example.com   example.com/sales/
+13     # Comment out the entry below to implement a catch-all.
+14     # @example.com      example.com/catchall
+15     ...virtual mailboxes for more domains...
+16 
+17 /etc/postfix/virtual:
+18     postmaster@example.com postmaster
+
+
+ +

Notes:

+ + + +

Execute the command "postmap /etc/postfix/virtual" after +changing the virtual file, execute "postmap /etc/postfix/vmailbox" +after changing the vmailbox file, and execute the command "postfix +reload" after changing the main.cf file.

+ +

Note: mail delivery happens with the recipient's UID/GID +privileges specified with virtual_uid_maps and virtual_gid_maps. +Postfix 2.0 and earlier will not create mailDIRs in world-writable +parent directories; you must create them in advance before you can +use them. Postfix may be able to create mailBOX files by itself, +depending on parent directory write permissions, but it is safer +to create mailBOX files ahead of time.

+ +

More details about the virtual mailbox delivery agent are given +in the virtual(8) manual page.

+ +

Non-Postfix mailbox store: separate +domains, non-UNIX accounts

+ +

This is a variation on the Postfix virtual mailbox example. +Again, every hosted address can have its own mailbox. However, most +parameters that control the virtual(8) delivery agent are no longer +applicable: only virtual_mailbox_domains and virtual_mailbox_maps +stay in effect. These parameters are needed to reject mail for +unknown recipients.

+ +

While non-Postfix software is being used for final delivery, +some Postfix concepts are still needed in order to glue everything +together. For additional background on this glue you may want to +take a look at the virtual mailbox domain class as defined in the +ADDRESS_CLASS_README file.

+ +

The text in this section describes what things should look like +from Postfix's point of view. See CYRUS_README or MAILDROP_README +for specific information about Cyrus or about Courier maildrop. +

+ +

Here is an example for a hosted domain example.com that delivers +to a non-Postfix delivery agent:

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     virtual_transport = ...see below...
+ 3     virtual_mailbox_domains = example.com ...more domains...
+ 4     virtual_mailbox_maps = hash:/etc/postfix/vmailbox
+ 5     virtual_alias_maps = hash:/etc/postfix/virtual
+ 6 
+ 7 /etc/postfix/vmailbox:
+ 8     info@example.com    whatever
+ 9     sales@example.com   whatever
+10     # Comment out the entry below to implement a catch-all.
+11     # Configure the mailbox store to accept all addresses.
+12     # @example.com      whatever
+13     ...virtual mailboxes for more domains...
+14 
+15 /etc/postfix/virtual:
+16     postmaster@example.com postmaster
+
+
+ +

Notes:

+ + + +

Execute the command "postmap /etc/postfix/virtual" after +changing the virtual file, execute "postmap /etc/postfix/vmailbox" +after changing the vmailbox file, and execute the command "postfix +reload" after changing the main.cf file.

+ +

Mail forwarding domains

+ +

Some providers host domains that have no (or only a few) local +mailboxes. The main purpose of these domains is to forward mail +elsewhere. The following example shows how to set up example.com +as a mail forwarding domain:

+ +
+
+ 1 /etc/postfix/main.cf:
+ 2     virtual_alias_domains = example.com ...other hosted domains...
+ 3     virtual_alias_maps = hash:/etc/postfix/virtual
+ 4 
+ 5 /etc/postfix/virtual:
+ 6     postmaster@example.com postmaster
+ 7     joe@example.com        joe@somewhere
+ 8     jane@example.com       jane@somewhere-else
+ 9     # Uncomment entry below to implement a catch-all address
+10     # @example.com         jim@yet-another-site
+11     ...virtual aliases for more domains...
+
+
+ +

Notes:

+ + + +

Execute the command "postmap /etc/postfix/virtual" after +changing the virtual file, and execute the command "postfix +reload" after changing the main.cf file.

+ +

More details about the virtual alias file are given in the +virtual(5) manual page, including multiple addresses on the right-hand +side.

+ +

Mailing lists

+ +

The examples that were given above already show how to direct +mail for virtual postmaster addresses to a local postmaster. You +can use the same method to direct mail for any address to a local +or remote address.

+ +

There is one major limitation: virtual aliases and virtual +mailboxes can't directly deliver to mailing list managers such as +majordomo. The solution is to set up virtual aliases that direct +virtual addresses to the local delivery agent:

+ +
+
+/etc/postfix/main.cf:
+    virtual_alias_maps = hash:/etc/postfix/virtual
+
+/etc/postfix/virtual:
+    listname-request@example.com listname-request
+    listname@example.com         listname
+    owner-listname@example.com   owner-listname
+
+/etc/aliases:
+    listname: "|/some/where/majordomo/wrapper ..."
+    owner-listname: ...
+    listname-request: ...
+
+
+ +

This example assumes that in main.cf, $myorigin is listed under +the mydestination parameter setting. If that is not the case, +specify an explicit domain name on the right-hand side of the +virtual alias table entries or else mail will go to the wrong +domain.

+ +

More information about the Postfix local delivery agent can be +found in the local(8) manual page.

+ +

Why does this example use a clumsy virtual alias instead of a +more elegant transport mapping? The reason is that mail for the +virtual mailing list would be rejected with "User unknown". In +order to make the transport mapping work one would still need a +bunch of virtual alias or virtual mailbox table entries.

+ + + +

Autoreplies

+ +

In order to set up an autoreply for virtual recipients while +still delivering mail as normal, set up a rule in a virtual alias +table:

+ +
+
+/etc/postfix/main.cf:
+    virtual_alias_maps = hash:/etc/postfix/virtual
+
+/etc/postfix/virtual:
+    user@domain.tld user@domain.tld, user@domain.tld@autoreply.mydomain.tld
+
+
+ +

This delivers mail to the recipient, and sends a copy of the +mail to the address that produces automatic replies. The address +can be serviced on a different machine, or it can be serviced +locally by setting up a transport map entry that pipes all mail +for autoreply.mydomain.tld into some script that sends an automatic +reply back to the sender.

+ +

DO NOT list autoreply.mydomain.tld in mydestination!

+ +
+
+/etc/postfix/main.cf:
+    transport_maps = hash:/etc/postfix/transport
+
+/etc/postfix/transport:
+    autoreply.mydomain.tld  autoreply:
+
+/etc/postfix/master.cf:
+    # =============================================================
+    # service type  private unpriv  chroot  wakeup  maxproc command
+    #               (yes)   (yes)   (yes)   (never) (100)
+    # =============================================================
+    autoreply unix  -       n       n       -       -       pipe
+        flags= user=nobody argv=/path/to/autoreply $sender $mailbox
+
+
+ +

This invokes /path/to/autoreply with the sender address and +the user@domain.tld recipient address on the command line.

+ +

For more information, see the pipe(8) manual page, and the +comments in the Postfix master.cf file.

+ + + + diff --git a/proto/XCLIENT_README.html b/proto/XCLIENT_README.html new file mode 100644 index 0000000..e4e2f0a --- /dev/null +++ b/proto/XCLIENT_README.html @@ -0,0 +1,267 @@ + + + + + + +Postfix XCLIENT Howto + + + + + + + +

Postfix XCLIENT Howto

+ +
+ +

Purpose of the XCLIENT extension to SMTP

+ +

When an SMTP server announces support for the XCLIENT command, +an SMTP client may send information that overrides one or more +client-related session attributes. The XCLIENT command targets the +following problems:

+ +
    + +

  1. Access control tests. SMTP server access rules are + difficult to verify when decisions can be triggered only by + remote clients. In order to facilitate access rule testing, + an authorized SMTP client test program needs the ability to + override the SMTP server's idea of the SMTP client hostname, + network address, and other client information, for the entire + duration of an SMTP session.

    + +

  2. Client software that downloads mail from an up-stream + mail server and injects it into a local MTA via SMTP. In order + to take advantage of the local MTA's SMTP server access rules, + the client software needs the ability to override the SMTP + server's idea of the remote client name, client address and + other information. Such information can typically be extracted + from the up-stream mail server's Received: message header.

    + +

  3. Post-filter access control and logging. With + Internet->filter->MTA style content filter applications, + the filter can be simplified if it can delegate decisions + concerning mail relay and other access control to the MTA. This + is especially useful when the filter acts as a transparent + proxy for SMTP commands. This requires that the filter can + override the MTA's idea of the SMTP client hostname, network + address, and other information.

    + +
+ +

XCLIENT Command syntax

+ +

An example client-server conversation is given at the end +of this document.

+ +

In SMTP server EHLO replies, the keyword associated with this +extension is XCLIENT. It is followed by the names of the attributes +that the XCLIENT implementation supports.

+ +

The XCLIENT command may be sent at any time, except in the +middle of a mail delivery transaction (i.e. between MAIL and DOT, +or MAIL and RSET). The XCLIENT command may be pipelined when the +server supports ESMTP command pipelining. To avoid triggering +spamware detectors, the command should be sent at the end of a +command group.

+ +

The syntax of XCLIENT requests is described below. Upper case +and quoted strings specify terminals, lowercase strings specify +meta terminals, and SP is whitespace. Although command and attribute +names are shown in upper case, they are in fact case insensitive. +

+ +
+

+ xclient-command = XCLIENT 1*( SP attribute-name"="attribute-value ) +

+

+ attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | LOGIN | DESTADDR | DESTPORT ) +

+

+ attribute-value = xtext +

+
+ + + +

Note 1: syntactically valid NAME and HELO attribute-value +elements can be up to 255 characters long. The client must not send +XCLIENT commands that exceed the 512 character limit for SMTP +commands. To avoid exceeding the limit the client should send the +information in multiple XCLIENT commands; for example, send NAME +and ADDR last, after HELO and PROTO. Once ADDR is sent, the client +is usually no longer authorized to send XCLIENT commands.

+ +

Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6: may be specified +in upper case, lower case or mixed case.

+ +

Note 3: Postfix implementations prior to version 2.3 do not +xtext encode attribute values. Servers that wish to interoperate +with these older implementations should be prepared to receive +unencoded information.

+ +

Note 4: Some Postfix implementations do not implement the PORT +or LOGIN attributes.

+ +

XCLIENT Server response

+ +

Upon receipt of a correctly formatted XCLIENT command, the +server resets state to the initial SMTP greeting protocol stage. +Depending on the outcome of optional access decisions, the server +responds with 220 or with a suitable rejection code. + +

For practical reasons it is not always possible to reset the +complete server state to the initial SMTP greeting protocol stage: +

+ + + +

NOTE: Postfix implementations prior to version 2.3 do not jump +back to the initial SMTP greeting protocol stage. These older +implementations will not correctly simulate connection-level access +decisions under some conditions.

+ +

XCLIENT server reply codes

+ +
+ + + + + + + + + + + + + + + + + +
Code Meaning
220 success
421 unable to proceed, disconnecting
501 bad command parameter syntax
503 mail transaction in progress
550 insufficient authorization
other connection rejected by connection-level +access decision
+ +
+ +

XCLIENT Example

+ +

In the example, the client impersonates a mail originating +system by passing all SMTP client information via the XCLIENT +command. Information sent by the client is shown in bold font. +

+ +
+
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-VRFY
+250-ETRN
+250-XCLIENT NAME ADDR PROTO HELO
+250 8BITMIME
+XCLIENT NAME=spike.porcupine.org ADDR=168.100.189.2
+220 server.example.com ESMTP Postfix
+EHLO spike.porcupine.org
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-VRFY
+250-ETRN
+250-XCLIENT NAME ADDR PROTO HELO
+250 8BITMIME
+MAIL FROM:<wietse@porcupine.org>
+250 Ok
+RCPT TO:<user@example.com>
+250 Ok
+DATA
+354 End data with <CR><LF>.<CR><LF>
+. . .message content. . .
+.
+250 Ok: queued as 763402AAE6
+QUIT
+221 Bye
+
+
+ +

Security

+ +

The XCLIENT command changes audit trails and/or SMTP client +access permissions. Use of this command must be restricted to +authorized SMTP clients.

+ +

SMTP connection caching

+ +

XCLIENT attributes persist until the end of an SMTP session. +If one session is used to deliver mail on behalf of different SMTP +clients, the XCLIENT attributes need to be reset as appropriate +before each MAIL FROM command.

+ +

References

+ +

Moore, K, "SMTP Service Extension for Delivery Status Notifications", +RFC 1891, January 1996.

+ + + + diff --git a/proto/XFORWARD_README.html b/proto/XFORWARD_README.html new file mode 100644 index 0000000..18cef6c --- /dev/null +++ b/proto/XFORWARD_README.html @@ -0,0 +1,241 @@ + + + + + + +Postfix XFORWARD Howto + + + + + + + +

Postfix XFORWARD Howto

+ +
+ +

Purpose of the XFORWARD extension to SMTP

+ +

When an SMTP server announces support for the XFORWARD command, +an SMTP client may send information that overrides one or more +client-related logging attributes. The XFORWARD command targets +the following problem:

+ + + +

This extension is implemented as a separate ESMTP command, and +can be used to transmit client or message attributes incrementally. +It is not implemented by passing additional parameters via the MAIL +FROM command, because doing so would require extending the MAIL +FROM command length limit by another 600 or more characters beyond +the space that is already needed to support other extensions such +as AUTH and DSN.

+ +

XFORWARD Command syntax

+ +

An example of a client-server conversation is given at the end +of this document.

+ +

In SMTP server EHLO replies, the keyword associated with this +extension is XFORWARD. The keyword is followed by the names of the +attributes that the XFORWARD implementation supports.

+ +

After receiving the server's announcement for XFORWARD support, +the client may send XFORWARD requests at any time except in +the middle of a mail delivery transaction (i.e. between MAIL and +RSET or DOT). The command may be pipelined when the server supports +ESMTP command pipelining.

+ +

The syntax of XFORWARD requests is described below. Upper case +and quoted strings specify terminals, lowercase strings specify +meta terminals, and SP is whitespace. Although command and attribute +names are shown in upper case, they are in fact case insensitive. +

+ +
+

+ xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value ) +

+

+ attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | IDENT | SOURCE ) +

+

+ attribute-value = xtext +

+
+ + + +

Note 1: an attribute-value element must not be longer than +255 characters (specific attributes may impose shorter lengths). +After xtext decoding, attribute values must not contain control +characters, non-ASCII characters, whitespace, or other characters +that are special in message headers.

+ +

Note 2: DNS hostnames can be up to 255 characters long. The +XFORWARD client implementation must not send XFORWARD commands that +exceed the 512 character limit for SMTP commands.

+ +

Note 3: [UNAVAILABLE] may be specified in upper case, lower +case or mixed case.

+ +

Note 4: Postfix implementations prior to version 2.3 do not +xtext encode attribute values. Servers that wish to interoperate +with these older implementations should be prepared to receive +unencoded information.

+ +

XFORWARD Server operation

+ +

The server maintains a set of XFORWARD attributes with forwarded +information, in addition the current SMTP session attributes. +Normally, all XFORWARD attributes are in the undefined state, and +the server uses the current SMTP session attributes for logging +purposes.

+ +

Upon receipt of an initial XFORWARD command, the SMTP server +initializes all XFORWARD attributes to [UNAVAILABLE]. With each +valid XFORWARD command, the server updates XFORWARD attributes with +the specified values.

+ +

The server must not mix client attributes from XFORWARD with +client attributes from the current SMTP session.

+ +

At the end of each MAIL FROM transaction (i.e. RSET or DOT), +the server resets all XFORWARD attributes to the undefined state, +and is ready to receive another initial XFORWARD command.

+ +

XFORWARD Server reply codes

+ +
+ + + + + + + + + + + + + + + +
Code Meaning
250 success
421 unable to proceed, disconnecting
501 bad command parameter syntax
503 mail transaction in progress
550 insufficient authorization
+ +
+ +

XFORWARD Example

+ +

In the following example, information sent by the client is +shown in bold font.

+ +
+
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-VRFY
+250-ETRN
+250-XFORWARD NAME ADDR PROTO HELO
+250 8BITMIME
+XFORWARD NAME=spike.porcupine.org ADDR=168.100.189.2 PROTO=ESMTP 
+250 Ok
+XFORWARD HELO=spike.porcupine.org
+250 Ok
+MAIL FROM:<wietse@porcupine.org>
+250 Ok
+RCPT TO:<user@example.com>
+250 Ok
+DATA
+354 End data with <CR><LF>.<CR><LF>
+. . .message content. . .
+.
+250 Ok: queued as 3CF6B2AAE8
+QUIT
+221 Bye
+
+
+ +

Security

+ +

The XFORWARD command changes audit trails. Use of this command +must be restricted to authorized clients.

+ +

SMTP connection caching

+ +

SMTP connection caching makes it possible to deliver multiple +messages within the same SMTP session. The XFORWARD attributes are +reset after the MAIL FROM transaction completes (after RSET or DOT), +so there is no risk of information leakage.

+ +

References

+ +

Moore, K, "SMTP Service Extension for Delivery Status Notifications", +RFC 1891, January 1996.

+ + + + diff --git a/proto/access b/proto/access new file mode 100644 index 0000000..983bf37 --- /dev/null +++ b/proto/access @@ -0,0 +1,478 @@ +#++ +# NAME +# access 5 +# SUMMARY +# Postfix SMTP server access table +# SYNOPSIS +# \fBpostmap /etc/postfix/access\fR +# +# \fBpostmap -q "\fIstring\fB" /etc/postfix/access\fR +# +# \fBpostmap -q - /etc/postfix/access <\fIinputfile\fR +# DESCRIPTION +# This document describes access control on remote SMTP client +# information: host names, network addresses, and envelope +# sender or recipient addresses; it is implemented by the +# Postfix SMTP server. See \fBheader_checks\fR(5) or +# \fBbody_checks\fR(5) for access control on the content of +# email messages. +# +# Normally, the \fBaccess\fR(5) table is specified as a text file +# that serves as input to the \fBpostmap\fR(1) command. +# The result, an indexed file in \fBdbm\fR or \fBdb\fR format, +# is used for fast searching by the mail system. Execute the +# command "\fBpostmap /etc/postfix/access\fR" to rebuild an +# indexed file after changing the corresponding text file. +# +# When the table is provided via other means such as NIS, LDAP +# or SQL, the same lookups are done as for ordinary indexed files. +# +# Alternatively, the table can be provided as a regular-expression +# map where patterns are given as regular expressions, or lookups +# can be directed to TCP-based server. In those cases, the lookups +# are done in a slightly different way as described below under +# "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES". +# CASE FOLDING +# .ad +# .fi +# The search string is folded to lowercase before database +# lookup. As of Postfix 2.3, the search string is not case +# folded with database types such as regexp: or pcre: whose +# lookup fields can match both upper and lower case. +# TABLE FORMAT +# .ad +# .fi +# The input format for the \fBpostmap\fR(1) command is as follows: +# .IP "\fIpattern action\fR" +# When \fIpattern\fR matches a mail address, domain or host address, +# perform the corresponding \fIaction\fR. +# .IP "blank lines and comments" +# Empty lines and whitespace-only lines are ignored, as +# are lines whose first non-whitespace character is a `#'. +# .IP "multi-line text" +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# EMAIL ADDRESS PATTERNS +# .ad +# .fi +# With lookups from indexed files such as DB or DBM, or from networked +# tables such as NIS, LDAP or SQL, patterns are tried in the order as +# listed below: +# .IP \fIuser\fR@\fIdomain\fR +# Matches the specified mail address. +# .IP \fIdomain.tld\fR +# Matches \fIdomain.tld\fR as the domain part of an email address. +# .sp +# The pattern \fIdomain.tld\fR also matches subdomains, but only +# when the string \fBsmtpd_access_maps\fR is listed in the Postfix +# \fBparent_domain_matches_subdomains\fR configuration setting. +# .IP \fI.domain.tld\fR +# Matches subdomains of \fIdomain.tld\fR, but only when the +# string \fBsmtpd_access_maps\fR is not listed in the Postfix +# \fBparent_domain_matches_subdomains\fR configuration setting. +# .IP \fIuser\fR@ +# Matches all mail addresses with the specified user part. +# .PP +# Note: lookup of the null sender address is not possible with +# some types of lookup table. By default, Postfix uses \fB<>\fR +# as the lookup key for such addresses. The value is specified with +# the \fBsmtpd_null_access_lookup_key\fR parameter in the Postfix +# \fBmain.cf\fR file. +# EMAIL ADDRESS EXTENSION +# .fi +# .ad +# When a mail address localpart contains the optional recipient delimiter +# (e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes: +# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIdomain\fR, +# \fIuser+foo\fR@, and \fIuser\fR@. +# HOST NAME/ADDRESS PATTERNS +# .ad +# .fi +# With lookups from indexed files such as DB or DBM, or from networked +# tables such as NIS, LDAP or SQL, the following lookup patterns are +# examined in the order as listed: +# .IP \fIdomain.tld\fR +# Matches \fIdomain.tld\fR. +# .sp +# The pattern \fIdomain.tld\fR also matches subdomains, but only +# when the string \fBsmtpd_access_maps\fR is listed in the Postfix +# \fBparent_domain_matches_subdomains\fR configuration setting. +# .IP \fI.domain.tld\fR +# Matches subdomains of \fIdomain.tld\fR, but only when the +# string \fBsmtpd_access_maps\fR is not listed in the Postfix +# \fBparent_domain_matches_subdomains\fR configuration setting. +# .IP \fInet.work.addr.ess\fR +# .IP \fInet.work.addr\fR +# .IP \fInet.work\fR +# .IP \fInet\fR +# Matches the specified IPv4 host address or subnetwork. An +# IPv4 host address is a sequence of four decimal octets +# separated by ".". +# +# Subnetworks are matched by repeatedly truncating the last +# ".octet" from the remote IPv4 host address string until a +# match is found in the access table, or until further +# truncation is not possible. +# +# NOTE 1: The access map lookup key must be in canonical form: +# do not specify unnecessary null characters, and do not +# enclose network address information with "[]" characters. +# +# NOTE 2: use the \fBcidr\fR lookup table type to specify +# network/netmask patterns. See \fBcidr_table\fR(5) for details. +# .IP \fInet:work:addr:ess\fR +# .IP \fInet:work:addr\fR +# .IP \fInet:work\fR +# .IP \fInet\fR +# Matches the specified IPv6 host address or subnetwork. An +# IPv6 host address is a sequence of three to eight hexadecimal +# octet pairs separated by ":". +# +# Subnetworks are matched by repeatedly truncating the last +# ":octetpair" from the remote IPv6 host address string until +# a match is found in the access table, or until further +# truncation is not possible. +# +# NOTE 1: the truncation and comparison are done with the +# string representation of the IPv6 host address. Thus, not +# all the ":" subnetworks will be tried. +# +# NOTE 2: The access map lookup key must be in canonical form: +# do not specify unnecessary null characters, and do not +# enclose network address information with "[]" characters. +# +# NOTE 3: use the \fBcidr\fR lookup table type to specify +# network/netmask patterns. See \fBcidr_table\fR(5) for details. +# +# IPv6 support is available in Postfix 2.2 and later. +# ACCEPT ACTIONS +# .ad +# .fi +# .IP \fBOK\fR +# Accept the address etc. that matches the pattern. +# .IP \fIall-numerical\fR +# An all-numerical result is treated as OK. This format is +# generated by address-based relay authorization schemes +# such as pop-before-smtp. +# .PP +# For other accept actions, see "OTHER ACTIONS" below. +# REJECT ACTIONS +# .ad +# .fi +# Postfix version 2.3 and later support enhanced status codes +# as defined in RFC 3463. +# When no code is specified at the beginning of the \fItext\fR +# below, Postfix inserts a default enhanced status code of "5.7.1" +# in the case of reject actions, and "4.7.1" in the case of +# defer actions. See "ENHANCED STATUS CODES" below. +# .IP "\fB4\fINN text\fR" +# .IP "\fB5\fINN text\fR" +# Reject the address etc. that matches the pattern, and respond with +# the numerical three-digit code and text. \fB4\fINN\fR means "try +# again later", while \fB5\fINN\fR means "do not try again". +# +# The following responses have special meaning for the Postfix +# SMTP server: +# .RS +# .IP "\fB421 \fItext\fR (Postfix 2.3 and later)" +# .IP "\fB521 \fItext\fR (Postfix 2.6 and later)" +# After responding with the numerical three-digit code and +# text, disconnect immediately from the SMTP client. This +# frees up SMTP server resources so that they can be made +# available to another SMTP client. +# .IP +# Note: The "521" response should be used only with botnets +# and other malware where interoperability is of no concern. +# The "send 521 and disconnect" behavior is NOT defined in +# the SMTP standard. +# .RE +# .IP "\fBREJECT \fIoptional text...\fR +# Reject the address etc. that matches the pattern. Reply with +# "\fB$access_map_reject_code \fIoptional text...\fR" when the +# optional text is +# specified, otherwise reply with a generic error response message. +# .IP "\fBDEFER \fIoptional text...\fR +# Reject the address etc. that matches the pattern. Reply with +# "\fB$access_map_defer_code \fIoptional text...\fR" when the +# optional text is +# specified, otherwise reply with a generic error response message. +# .sp +# This feature is available in Postfix 2.6 and later. +# .IP "\fBDEFER_IF_REJECT \fIoptional text...\fR +# Defer the request if some later restriction would result in a +# REJECT action. Reply with "\fB$access_map_defer_code 4.7.1 +# \fIoptional text...\fR" when the +# optional text is specified, otherwise reply with a generic error +# response message. +# .sp +# Prior to Postfix 2.6, the SMTP reply code is 450. +# .sp +# This feature is available in Postfix 2.1 and later. +# .IP "\fBDEFER_IF_PERMIT \fIoptional text...\fR +# Defer the request if some later restriction would result in a +# an explicit or implicit PERMIT action. +# Reply with "\fB$access_map_defer_code 4.7.1 \fI optional +# text...\fR" when the +# optional text is specified, otherwise reply with a generic error +# response message. +# .sp +# Prior to Postfix 2.6, the SMTP reply code is 450. +# .sp +# This feature is available in Postfix 2.1 and later. +# .PP +# For other reject actions, see "OTHER ACTIONS" below. +# OTHER ACTIONS +# .ad +# .fi +# .IP \fIrestriction...\fR +# Apply the named UCE restriction(s) (\fBpermit\fR, \fBreject\fR, +# \fBreject_unauth_destination\fR, and so on). +# .IP "\fBBCC \fIuser@domain\fR" +# Send one copy of the message to the specified recipient. +# .sp +# If multiple BCC actions are specified within the same SMTP +# MAIL transaction, with Postfix 3.0 only the last action +# will be used. +# .sp +# This feature is available in Postfix 3.0 and later. +# \" .IP "\fBDELAY \fItime\fR" +# \" Place the message into the deferred queue, and delay the +# \" initial delivery attempt by \fItime\fR. The time value may +# \" be followed by a one-character suffix that specifies the +# \" time unit: s (seconds), m (minutes), h (hours), d (days), +# \" w (weeks). The default time unit is s (seconds). +# \" .sp +# \" Limitations: +# \" .RS +# \" .IP \(bu +# \" This action affects all the recipients of the message. +# \" .IP \(bu +# \" The delay value has no effect with remote file systems that +# \" don't correctly emulate UNIX local file system semantics. +# \" In that case, the delay will be half of $queue_run_delay +# \" on average. +# \" .IP \(bu +# \" Mail will still be delivered with "sendmail -q", "postfix +# \" flush" or "postqueue -f". +# \" .IP \(bu +# \" Delayed mail increases the amount of disk I/O during deferred +# \" queue scans. When large amounts of mail are queued for +# \" delayed delivery it may be preferable to use the HOLD feature +# \" instead. +# \" .RE +# \" .IP +# \" This feature is available in Postfix 2.3 and later. +# .IP "\fBDISCARD \fIoptional text...\fR +# Claim successful delivery and silently discard the message. +# Log the optional text if specified, otherwise log a generic +# message. +# .sp +# Note: this action currently affects all recipients of the message. +# To discard only one recipient without discarding the entire message, +# use the transport(5) table to direct mail to the discard(8) service. +# .sp +# This feature is available in Postfix 2.0 and later. +# .IP \fBDUNNO\fR +# Pretend that the lookup key was not found. This +# prevents Postfix from trying substrings of the lookup key +# (such as a subdomain name, or a network address subnetwork). +# .sp +# This feature is available in Postfix 2.0 and later. +# .IP "\fBFILTER \fItransport:destination\fR" +# After the message is queued, send the entire message through +# the specified external content filter. The \fItransport\fR +# name specifies the first field of a mail delivery agent +# definition in master.cf; the syntax of the next-hop +# \fIdestination\fR is described in the manual page of the +# corresponding delivery agent. More information about +# external content filters is in the Postfix FILTER_README +# file. +# .sp +# Note 1: do not use $\fInumber\fR regular expression +# substitutions for \fItransport\fR or \fIdestination\fR +# unless you know that the information has a trusted origin. +# .sp +# Note 2: this action overrides the main.cf \fBcontent_filter\fR +# setting, and affects all recipients of the message. In the +# case that multiple \fBFILTER\fR actions fire, only the last +# one is executed. +# .sp +# Note 3: the purpose of the FILTER command is to override +# message routing. To override the recipient's \fItransport\fR +# but not the next-hop \fIdestination\fR, specify an empty +# filter \fIdestination\fR (Postfix 2.7 and later), or specify +# a \fItransport:destination\fR that delivers through a +# different Postfix instance (Postfix 2.6 and earlier). Other +# options are using the recipient-dependent \fBtrans\%port\%_maps\fR +# or the sen\%der-dependent +# \fBsender\%_de\%pen\%dent\%_de\%fault\%_trans\%port\%_maps\fR +# features. +# .sp +# This feature is available in Postfix 2.0 and later. +# .IP "\fBHOLD \fIoptional text...\fR" +# Place the message on the \fBhold\fR queue, where it will +# sit until someone either deletes it or releases it for +# delivery. +# Log the optional text if specified, otherwise log a generic +# message. +# +# Mail that is placed on hold can be examined with the +# \fBpostcat\fR(1) command, and can be destroyed or released with +# the \fBpostsuper\fR(1) command. +# .sp +# Note: use "\fBpostsuper -r\fR" to release mail that was kept on +# hold for a significant fraction of \fB$maximal_queue_lifetime\fR +# or \fB$bounce_queue_lifetime\fR, or longer. Use "\fBpostsuper -H\fR" +# only for mail that will not expire within a few delivery attempts. +# .sp +# Note: this action currently affects all recipients of the message. +# .sp +# This feature is available in Postfix 2.0 and later. +# .IP "\fBPREPEND \fIheadername: headervalue\fR" +# Prepend the specified message header to the message. +# When more than one PREPEND action executes, the first +# prepended header appears before the second etc. prepended +# header. +# .sp +# Note: this action must execute before the message content +# is received; it cannot execute in the context of +# \fBsmtpd_end_of_data_restrictions\fR. +# .sp +# This feature is available in Postfix 2.1 and later. +# .IP "\fBREDIRECT \fIuser@domain\fR" +# After the message is queued, send the message to the specified +# address instead of the intended recipient(s). When multiple +# \fBREDIRECT\fR actions fire, only the last one takes effect. +# .sp +# Note: this action overrides the FILTER action, and currently +# overrides all recipients of the message. +# .sp +# This feature is available in Postfix 2.1 and later. +# .IP "\fBINFO \fIoptional text...\fR +# Log an informational record with the optional text, together +# with client information and if available, with helo, sender, +# recipient and protocol information. +# .sp +# This feature is available in Postfix 3.0 and later. +# .IP "\fBWARN \fIoptional text...\fR +# Log a warning with the optional text, together with client information +# and if available, with helo, sender, recipient and protocol information. +# .sp +# This feature is available in Postfix 2.1 and later. +# ENHANCED STATUS CODES +# .ad +# .fi +# Postfix version 2.3 and later support enhanced status codes +# as defined in RFC 3463. +# When an enhanced status code is specified in an access +# table, it is subject to modification. The following +# transformations are needed when the same access table is +# used for client, helo, sender, or recipient access restrictions; +# they happen regardless of whether Postfix replies to a MAIL +# FROM, RCPT TO or other SMTP command. +# .IP \(bu +# When a sender address matches a REJECT action, the Postfix +# SMTP server will transform a recipient DSN status (e.g., +# 4.1.1-4.1.6) into the corresponding sender DSN status, and +# vice versa. +# .IP \(bu +# When non-address information matches a REJECT action (such +# as the HELO command argument or the client hostname/address), +# the Postfix SMTP server will transform a sender or recipient +# DSN status into a generic non-address DSN status (e.g., +# 4.0.0). +# REGULAR EXPRESSION TABLES +# .ad +# .fi +# This section describes how the table lookups change when the table +# is given in the form of regular expressions. For a description of +# regular expression lookup table syntax, see \fBregexp_table\fR(5) +# or \fBpcre_table\fR(5). +# +# Each pattern is a regular expression that is applied to the entire +# string being looked up. Depending on the application, that string +# is an entire client hostname, an entire client IP address, or an +# entire mail address. Thus, no parent domain or parent network search +# is done, \fIuser@domain\fR mail addresses are not broken up into +# their \fIuser@\fR and \fIdomain\fR constituent parts, nor is +# \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. +# +# Patterns are applied in the order as specified in the table, until a +# pattern is found that matches the search string. +# +# Actions are the same as with indexed file lookups, with +# the additional feature that parenthesized substrings from the +# pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on. +# TCP-BASED TABLES +# .ad +# .fi +# This section describes how the table lookups change when lookups +# are directed to a TCP-based server. For a description of the TCP +# client/server lookup protocol, see \fBtcp_table\fR(5). +# This feature is not available up to and including Postfix version 2.4. +# +# Each lookup operation uses the entire query string once. +# Depending on the application, that string is an entire client +# hostname, an entire client IP address, or an entire mail address. +# Thus, no parent domain or parent network search is done, +# \fIuser@domain\fR mail addresses are not broken up into +# their \fIuser@\fR and \fIdomain\fR constituent parts, nor is +# \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. +# +# Actions are the same as with indexed file lookups. +# EXAMPLE +# .ad +# .fi +# The following example uses an indexed file, so that the +# order of table entries does not matter. The example permits +# access by the client at address 1.2.3.4 but rejects all +# other clients in 1.2.3.0/24. Instead of \fBhash\fR lookup +# tables, some systems use \fBdbm\fR. Use the command +# "\fBpostconf -m\fR" to find out what lookup tables Postfix +# supports on your system. +# +# .nf +# .na +# /etc/postfix/main.cf: +# smtpd_client_restrictions = +# check_client_access hash:/etc/postfix/access +# +# /etc/postfix/access: +# 1.2.3 REJECT +# 1.2.3.4 OK +# .fi +# .ad +# +# Execute the command "\fBpostmap /etc/postfix/access\fR" after +# editing the file. +# BUGS +# The table format does not understand quoting conventions. +# SEE ALSO +# postmap(1), Postfix lookup table manager +# smtpd(8), SMTP server +# postconf(5), configuration parameters +# transport(5), transport:nexthop syntax +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# SMTPD_ACCESS_README, built-in SMTP server access control +# DATABASE_README, Postfix lookup table overview +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/aliases b/proto/aliases new file mode 100644 index 0000000..6442ac1 --- /dev/null +++ b/proto/aliases @@ -0,0 +1,206 @@ +#++ +# NAME +# aliases 5 +# SUMMARY +# Postfix local alias database format +# SYNOPSIS +# .fi +# \fBnewaliases\fR +# DESCRIPTION +# The \fBaliases\fR(5) table provides a system-wide mechanism to +# redirect mail for local recipients. The redirections are +# processed by the Postfix \fBlocal\fR(8) delivery agent. +# +# Normally, the \fBaliases\fR(5) table is specified as a text file +# that serves as input to the \fBpostalias\fR(1) command. The +# result, an indexed file in \fBdbm\fR or \fBdb\fR format, is +# used for fast lookup by the mail system. Execute the command +# \fBnewaliases\fR in order to rebuild the indexed file after +# changing the Postfix alias database. +# +# When the table is provided via other means such as NIS, LDAP +# or SQL, the same lookups are done as for ordinary indexed files. +# +# Alternatively, the table can be provided as a regular-expression +# map where patterns are given as regular expressions. In +# this case, the lookups are done in a slightly different way +# as described below under "REGULAR EXPRESSION TABLES". +# +# Users can control delivery of their own mail by setting +# up \fB.forward\fR files in their home directory. +# Lines in per-user \fB.forward\fR files have the same syntax +# as the right-hand side of \fBaliases\fR(5) entries. +# +# The format of the alias database input file is as follows: +# .IP \(bu +# An alias definition has the form +# .sp +# .nf +# \fIname\fR: \fIvalue1\fR, \fIvalue2\fR, \fI...\fR +# .fi +# .IP \(bu +# Empty lines and whitespace-only lines are ignored, as +# are lines whose first non-whitespace character is a `#'. +# .IP \(bu +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# .PP +# The \fIname\fR is a local address (no domain part). +# Use double quotes when the name contains any special characters +# such as whitespace, `#', `:', or `@'. The \fIname\fR is folded to +# lowercase, in order to make database lookups case insensitive. +# .PP +# In addition, when an alias exists for \fBowner-\fIname\fR, +# this will override the envelope sender address, so that +# delivery diagnostics are directed to \fBowner-\fIname\fR, +# instead of the originator of the message (for details, see +# \fBowner_request_special\fR, \fBexpand_owner_alias\fR and +# \fBreset_owner_alias\fR). +# This is typically used to direct delivery errors to the maintainer of +# a mailing list, who is in a better position to deal with mailing +# list delivery problems than the originator of the undelivered mail. +# .PP +# The \fIvalue\fR contains one or more of the following: +# .IP \fIaddress\fR +# Mail is forwarded to \fIaddress\fR, which is compatible +# with the RFC 822 standard. +# .IP \fI/file/name\fR +# Mail is appended to \fI/file/name\fR. See \fBlocal\fR(8) +# for details of delivery to file. +# Delivery is not limited to regular files. For example, to dispose +# of unwanted mail, deflect it to \fB/dev/null\fR. +# .IP "|\fIcommand\fR" +# Mail is piped into \fIcommand\fR. Commands that contain special +# characters, such as whitespace, should be enclosed between double +# quotes. See \fBlocal\fR(8) for details of delivery to command. +# .sp +# When the command fails, a limited amount of command output is +# mailed back to the sender. The file \fB/usr/include/sysexits.h\fR +# defines the expected exit status codes. For example, use +# \fB"|exit 67"\fR to simulate a "user unknown" error, and +# \fB"|exit 0"\fR to implement an expensive black hole. +# .IP \fB:include:\fI/file/name\fR +# Mail is sent to the destinations listed in the named file. +# Lines in \fB:include:\fR files have the same syntax +# as the right-hand side of alias entries. +# .sp +# A destination can be any destination that is described in this +# manual page. However, delivery to "|\fIcommand\fR" and +# \fI/file/name\fR is disallowed by default. To enable, edit the +# \fBallow_mail_to_commands\fR and \fBallow_mail_to_files\fR +# configuration parameters. +# ADDRESS EXTENSION +# .ad +# .fi +# When alias database search fails, and the recipient localpart +# contains the optional recipient delimiter (e.g., \fIuser+foo\fR), +# the search is repeated for the unextended address (e.g., \fIuser\fR). +# +# The \fBpropagate_unmatched_extensions\fR parameter controls +# whether an unmatched address extension (\fI+foo\fR) is +# propagated to the result of table lookup. +# CASE FOLDING +# .ad +# .fi +# The local(8) delivery agent always folds the search string +# to lowercase before database lookup. +# REGULAR EXPRESSION TABLES +# .ad +# .fi +# This section describes how the table lookups change when the table +# is given in the form of regular expressions. For a description of +# regular expression lookup table syntax, see \fBregexp_table\fR(5) +# or \fBpcre_table\fR(5). NOTE: these formats do not use ":" at the +# end of a pattern. +# +# Each regular expression is applied to the entire search +# string. Thus, a search string \fIuser+foo\fR is not broken +# up into \fIuser\fR and \fIfoo\fR. +# +# Regular expressions are applied in the order as specified +# in the table, until a regular expression is found that +# matches the search string. +# +# Lookup results are the same as with indexed file lookups. +# For security reasons there is no support for \fB$1\fR, +# \fB$2\fR etc. substring interpolation. +# SECURITY +# .ad +# .fi +# The \fBlocal\fR(8) delivery agent disallows regular expression +# substitution of $1 etc. in \fBalias_maps\fR, because that +# would open a security hole. +# +# The \fBlocal\fR(8) delivery agent will silently ignore +# requests to use the \fBproxymap\fR(8) server within +# \fBalias_maps\fR. Instead it will open the table directly. +# Before Postfix version 2.2, the \fBlocal\fR(8) delivery +# agent will terminate with a fatal error. +# CONFIGURATION PARAMETERS +# .ad +# .fi +# The following \fBmain.cf\fR parameters are especially relevant. +# The text below provides only a parameter summary. See +# \fBpostconf\fR(5) for more details including examples. +# .IP "\fBalias_database (see 'postconf -d' output)\fR" +# The alias databases for \fBlocal\fR(8) delivery that are updated with +# "\fBnewaliases\fR" or with "\fBsendmail -bi\fR". +# .IP "\fBalias_maps (see 'postconf -d' output)\fR" +# The alias databases that are used for \fBlocal\fR(8) delivery. +# .IP "\fBallow_mail_to_commands (alias, forward)\fR" +# Restrict \fBlocal\fR(8) mail delivery to external commands. +# .IP "\fBallow_mail_to_files (alias, forward)\fR" +# Restrict \fBlocal\fR(8) mail delivery to external files. +# .IP "\fBexpand_owner_alias (no)\fR" +# When delivering to an alias "\fIaliasname\fR" that has an +# "owner-\fIaliasname\fR" companion alias, set the envelope sender +# address to the expansion of the "owner-\fIaliasname\fR" alias. +# .IP "\fBpropagate_unmatched_extensions (canonical, virtual)\fR" +# What address lookup tables copy an address extension from the lookup +# key to the lookup result. +# .IP "\fBowner_request_special (yes)\fR" +# Enable special treatment for owner-\fIlistname\fR entries in the +# \fBaliases\fR(5) file, and don't split owner-\fIlistname\fR and +# \fIlistname\fR-request address localparts when the recipient_delimiter +# is set to "-". +# .IP "\fBrecipient_delimiter (empty)\fR" +# The set of characters that can separate a user name from its +# extension (example: user+foo), or a .forward file name from its +# extension (example: .forward+foo). +# .PP +# Available in Postfix version 2.3 and later: +# .IP "\fBfrozen_delivered_to (yes)\fR" +# Update the \fBlocal\fR(8) delivery agent's idea of the Delivered-To: +# address (see prepend_delivered_header) only once, at the start of +# a delivery attempt; do not update the Delivered-To: address while +# expanding aliases or .forward files. +# STANDARDS +# RFC 822 (ARPA Internet Text Messages) +# SEE ALSO +# local(8), local delivery agent +# newaliases(1), create/update alias database +# postalias(1), create/update alias database +# postconf(5), configuration parameters +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/aliases0 b/proto/aliases0 new file mode 100644 index 0000000..b00a3e1 --- /dev/null +++ b/proto/aliases0 @@ -0,0 +1,38 @@ +# +# Sample aliases file. Install in the location as specified by the +# output from the command "postconf alias_maps". Typical path names +# are /etc/aliases or /etc/mail/aliases. +# +# >>>>>>>>>> The program "newaliases" must be run after +# >> NOTE >> this file is updated for any changes to +# >>>>>>>>>> show through to Postfix. +# + +# Person who should get root's mail. Don't receive mail as root! +#root: you + +# Basic system aliases -- these MUST be present +MAILER-DAEMON: postmaster +postmaster: root + +# General redirections for pseudo accounts +bin: root +daemon: root +named: root +nobody: root +uucp: root +www: root +ftp-bugs: root +postfix: root + +# Put your local aliases here. + +# Well-known aliases +manager: root +dumper: root +operator: root +abuse: postmaster + +# trap decode to catch security attacks +decode: root + diff --git a/proto/bounce b/proto/bounce new file mode 100644 index 0000000..e7f5815 --- /dev/null +++ b/proto/bounce @@ -0,0 +1,214 @@ +#++ +# NAME +# bounce 5 +# SUMMARY +# Postfix bounce message template format +# SYNOPSIS +# \fBbounce_template_file = /etc/postfix/bounce.cf\fR +# +# \fBpostconf -b\fR [\fItemplate_file\fR] +# DESCRIPTION +# The Postfix \fBbounce\fR(8) server produces delivery status +# notification (DSN) messages for undeliverable mail, delayed +# mail, successful delivery or address verification requests. +# +# By default, these notifications are generated from built-in +# templates with message headers and message text. Sites can +# override the built-in information by specifying a bounce +# template file with the \fBbounce_template_file\fR configuration +# parameter. +# +# This document describes the general procedure to create a +# bounce template file, followed by the specific details of +# bounce template formats. +# GENERAL PROCEDURE +# .ad +# .fi +# To create a customized bounce template file, create a +# temporary +# copy of the file \fB/etc/postfix/bounce.cf.default\fR and +# edit the temporary file. +# +# To preview the results of $\fIname\fR expansions in the +# template text, use the command +# +# .nf +# \fBpostconf -b\fR \fItemporary_file\fR +# .fi +# +# Errors in the template will be reported to the standard +# error stream and to the syslog daemon. +# +# While previewing the text, be sure to pay particular attention +# to the expansion of time value parameters that appear in +# the delayed mail notification text. +# +# Once the result is satisfactory, copy the template to the +# Postfix configuration directory and specify in main.cf +# something like: +# +# .nf +# /etc/postfix/main.cf: +# bounce_template_file = /etc/postfix/bounce.cf +# .fi +# TEMPLATE FILE FORMAT +# .ad +# .fi +# The template file can specify templates for failed mail, +# delayed mail, successful delivery or for address verification. +# These templates are named \fBfailure_template\fR, +# \fBdelay_template\fR, \fBsuccess_template\fR and +# \fBverify_template\fR, respectively. You can but do not +# have to specify all four templates in a bounce template +# file. +# +# Each template starts with "\fItemplate_name\fB = <$/ +# REJECT IFRAME vulnerability exploit +# SEE ALSO +# cleanup(8), canonicalize and enqueue Postfix message +# pcre_table(5), format of PCRE lookup tables +# regexp_table(5), format of POSIX regular expression tables +# postconf(1), Postfix configuration utility +# postmap(1), Postfix lookup table management +# postsuper(1), Postfix janitor +# postcat(1), show Postfix queue file contents +# RFC 2045, base64 and quoted-printable encoding rules +# RFC 2047, message header encoding for non-ASCII text +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# CONTENT_INSPECTION_README, Postfix content inspection overview +# BUILTIN_FILTER_README, Postfix built-in content inspection +# BACKSCATTER_README, blocking returned forged mail +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/html2text.rc b/proto/html2text.rc new file mode 100644 index 0000000..9e8819f --- /dev/null +++ b/proto/html2text.rc @@ -0,0 +1,13 @@ +P.vspace.after = 1 +PRE.indent.left = 0 +UL.indents = 4 4 4 4 4 +OL.indents = 4 4 4 4 4 +DL.vspace.before = 0 +DL.vspace.after = 0 +DT.vspace.before = 0 +DT.indent.left = 0 +DD.indent.left = 4 +BLOCKQUOTE.indent.left = 4 +BLOCKQUOTE.indent.right = 0 +A.attributes.internal_link = NONE +A.attributes.external_link = NONE diff --git a/proto/ldap_table b/proto/ldap_table new file mode 100644 index 0000000..b770e4a --- /dev/null +++ b/proto/ldap_table @@ -0,0 +1,723 @@ +#++ +# NAME +# ldap_table 5 +# SUMMARY +# Postfix LDAP client configuration +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" ldap:/etc/postfix/\fIfilename\fR +# +# \fBpostmap -q - ldap:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting or mail routing. These tables are usually in +# \fBdbm\fR or \fBdb\fR format. +# +# Alternatively, lookup tables can be specified as LDAP databases. +# +# In order to use LDAP lookups, define an LDAP source as a lookup +# table in main.cf, for example: +# +# .nf +# alias_maps = ldap:/etc/postfix/ldap-aliases.cf +# .fi +# +# The file /etc/postfix/ldap-aliases.cf has the same format as +# the Postfix main.cf file, and can specify the parameters +# described below. An example is given at the end of this manual. +# +# This configuration method is available with Postfix version +# 2.1 and later. See the section "OBSOLETE MAIN.CF PARAMETERS" +# below for older Postfix versions. +# +# For details about LDAP SSL and STARTTLS, see the section +# on SSL and STARTTLS below. +# LIST MEMBERSHIP +# .ad +# .fi +# When using LDAP to store lists such as $mynetworks, +# $mydestination, $relay_domains, $local_recipient_maps, +# etc., it is important to understand that the table must +# store each list member as a separate key. The table lookup +# verifies the *existence* of the key. See "Postfix lists +# versus tables" in the DATABASE_README document for a +# discussion. +# +# Do NOT create tables that return the full list of domains +# in $mydestination or $relay_domains etc., or IP addresses +# in $mynetworks. +# +# DO create tables with each matching item as a key and with +# an arbitrary value. With LDAP databases it is not uncommon to +# return the key itself. +# +# For example, NEVER do this in a map defining $mydestination: +# +# .nf +# query_filter = domain=* +# result_attribute = domain +# .fi +# +# Do this instead: +# +# .nf +# query_filter = domain=%s +# result_attribute = domain +# .fi +# GENERAL LDAP PARAMETERS +# .ad +# .fi +# In the text below, default values are given in parentheses. +# Note: don't use quotes in these variables; at least, not until the +# Postfix configuration routines understand how to deal with quoted +# strings. +# .IP "\fBserver_host (default: localhost)\fR" +# The name of the host running the LDAP server, e.g. +# +# .nf +# server_host = ldap.example.com +# .fi +# +# Depending on the LDAP client library you're using, it should +# be possible to specify multiple servers here, with the library +# trying them in order should the first one fail. It should also +# be possible to give each server in the list a different port +# (overriding \fBserver_port\fR below), by naming them like +# +# .nf +# server_host = ldap.example.com:1444 +# .fi +# +# With OpenLDAP, a (list of) LDAP URLs can be used to specify both +# the hostname(s) and the port(s): +# +# .nf +# server_host = ldap://ldap.example.com:1444 +# ldap://ldap2.example.com:1444 +# .fi +# +# All LDAP URLs accepted by the OpenLDAP library are supported, +# including connections over UNIX domain sockets, and LDAP SSL +# (the last one provided that OpenLDAP was compiled with support +# for SSL): +# +# .nf +# server_host = ldapi://%2Fsome%2Fpath +# ldaps://ldap.example.com:636 +# .fi +# .IP "\fBserver_port (default: 389)\fR" +# The port the LDAP server listens on, e.g. +# +# .nf +# server_port = 778 +# .fi +# .IP "\fBtimeout (default: 10 seconds)\fR" +# The number of seconds a search can take before timing out, e.g. +# +# .fi +# timeout = 5 +# .fi +# .IP "\fBsearch_base (No default; you must configure this)\fR" +# The RFC2253 base DN at which to conduct the search, e.g. +# +# .nf +# search_base = dc=your, dc=com +# .fi +# .IP +# With Postfix 2.2 and later this parameter supports the +# following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. +# .IP "\fB%s\fR" +# This is replaced by the input key. +# RFC 2253 quoting is used to make sure that the input key +# does not add unexpected metacharacters. +# .IP "\fB%u\fR" +# When the input key is an address of the form user@domain, \fB%u\fR +# is replaced by the (RFC 2253) quoted local part of the address. +# Otherwise, \fB%u\fR is replaced by the entire search string. +# If the localpart is empty, the search is suppressed and returns +# no results. +# .IP "\fB%d\fR" +# When the input key is an address of the form user@domain, \fB%d\fR +# is replaced by the (RFC 2253) quoted domain part of the address. +# Otherwise, the search is suppressed and returns no results. +# .IP "\fB%[SUD]\fR" +# For the \fBsearch_base\fR parameter, the upper-case equivalents +# of the above expansions behave identically to their lower-case +# counter-parts. With the \fBresult_format\fR parameter (previously +# called \fBresult_filter\fR see the COMPATIBILITY section and below), +# they expand to the corresponding components of input key rather +# than the result value. +# .IP "\fB%[1-9]\fR" +# The patterns %1, %2, ... %9 are replaced by the corresponding +# most significant component of the input key's domain. If the +# input key is \fIuser@mail.example.com\fR, then %1 is \fBcom\fR, +# %2 is \fBexample\fR and %3 is \fBmail\fR. If the input key is +# unqualified or does not have enough domain components to satisfy +# all the specified patterns, the search is suppressed and returns +# no results. +# .RE +# .IP "\fBquery_filter (default: mailacceptinggeneralid=%s)\fR" +# The RFC2254 filter used to search the directory, where \fB%s\fR +# is a substitute for the address Postfix is trying to resolve, +# e.g. +# +# .nf +# query_filter = (&(mail=%s)(paid_up=true)) +# .fi +# +# This parameter supports the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. (Postfix 2.2 and later). +# .IP "\fB%s\fR" +# This is replaced by the input key. +# RFC 2254 quoting is used to make sure that the input key +# does not add unexpected metacharacters. +# .IP "\fB%u\fR" +# When the input key is an address of the form user@domain, \fB%u\fR +# is replaced by the (RFC 2254) quoted local part of the address. +# Otherwise, \fB%u\fR is replaced by the entire search string. +# If the localpart is empty, the search is suppressed and returns +# no results. +# .IP "\fB%d\fR" +# When the input key is an address of the form user@domain, \fB%d\fR +# is replaced by the (RFC 2254) quoted domain part of the address. +# Otherwise, the search is suppressed and returns no results. +# .IP "\fB%[SUD]\fR" +# The upper-case equivalents of the above expansions behave in the +# \fBquery_filter\fR parameter identically to their lower-case +# counter-parts. With the \fBresult_format\fR parameter (previously +# called \fBresult_filter\fR see the COMPATIBILITY section and below), +# they expand to the corresponding components of input key rather +# than the result value. +# .IP +# The above %S, %U and %D expansions are available with Postfix 2.2 +# and later. +# .IP "\fB%[1-9]\fR" +# The patterns %1, %2, ... %9 are replaced by the corresponding +# most significant component of the input key's domain. If the +# input key is \fIuser@mail.example.com\fR, then %1 is \fBcom\fR, +# %2 is \fBexample\fR and %3 is \fBmail\fR. If the input key is +# unqualified or does not have enough domain components to satisfy +# all the specified patterns, the search is suppressed and returns +# no results. +# .IP +# The above %1, ..., %9 expansions are available with Postfix 2.2 +# and later. +# .RE +# .IP +# The "domain" parameter described below limits the input +# keys to addresses in matching domains. When the "domain" +# parameter is non-empty, LDAP queries for unqualified +# addresses or addresses in non-matching domains are suppressed +# and return no results. +# +# NOTE: DO NOT put quotes around the \fBquery_filter\fR parameter. +# .IP "\fBresult_format (default: \fB%s\fR)\fR" +# Called \fBresult_filter\fR in Postfix releases prior to 2.2. +# Format template applied to result attributes. Most commonly used +# to append (or prepend) text to the result. This parameter supports +# the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. (Postfix 2.2 and later). +# .IP "\fB%s\fR" +# This is replaced by the value of the result attribute. When +# result is empty it is skipped. +# .IP "\fB%u\fR +# When the result attribute value is an address of the form +# user@domain, \fB%u\fR is replaced by the local part of the +# address. When the result has an empty localpart it is skipped. +# .IP "\fB%d\fR" +# When a result attribute value is an address of the form +# user@domain, \fB%d\fR is replaced by the domain part of +# the attribute value. When the result is unqualified it +# is skipped. +# .IP "\fB%[SUD1-9]\fR" +# The upper-case and decimal digit expansions interpolate +# the parts of the input key rather than the result. Their +# behavior is identical to that described with \fBquery_filter\fR, +# and in fact because the input key is known in advance, lookups +# whose key does not contain all the information specified in +# the result template are suppressed and return no results. +# .IP +# The above %S, %U, %D and %1, ..., %9 expansions are available with +# Postfix 2.2 and later. +# .RE +# .IP +# For example, using "result_format = smtp:[%s]" allows one +# to use a mailHost attribute as the basis of a transport(5) +# table. After applying the result format, multiple values +# are concatenated as comma separated strings. The expansion_limit +# and size_limit parameters explained below allow one to +# restrict the number of values in the result, which is +# especially useful for maps that should return a single +# value. +# +# The default value \fB%s\fR specifies that each +# attribute value should be used as is. +# +# This parameter was called \fBresult_filter\fR in Postfix +# releases prior to 2.2. If no "result_format" is specified, +# the value of "result_filter" will be used instead before +# resorting to the default value. This provides compatibility +# with old configuration files. +# +# NOTE: DO NOT put quotes around the result format! +# .IP "\fBdomain (default: no domain list)\fR" +# This is a list of domain names, paths to files, or +# dictionaries. When specified, only fully qualified search +# keys with a *non-empty* localpart and a matching domain +# are eligible for lookup: 'user' lookups, bare domain lookups +# and "@domain" lookups are not performed. This can significantly +# reduce the query load on the LDAP server. +# +# .nf +# domain = postfix.org, hash:/etc/postfix/searchdomains +# .fi +# +# It is best not to use LDAP to store the domains eligible +# for LDAP lookups. +# +# NOTE: DO NOT define this parameter for local(8) aliases. +# +# This feature is available in Postfix 1.0 and later. +# .IP "\fBresult_attribute (default: maildrop)\fR" +# The attribute(s) Postfix will read from any directory +# entries returned by the lookup, to be resolved to an email +# address. +# +# .nf +# result_attribute = mailbox, maildrop +# .fi +# +# Don't rely on the default value ("maildrop"). Set the +# result_attribute explicitly in all ldap table configuration +# files. This is particularly relevant when no result_attribute +# is applicable, e.g. cases in which leaf_result_attribute and/or +# terminal_result_attribute are used instead. The default value +# is harmless if "maildrop" is also listed as a leaf or terminal +# result attribute, but it is best to not leave this to chance. +# .IP "\fBspecial_result_attribute (default: empty)\fR" +# The attribute(s) of directory entries that can contain DNs +# or RFC 2255 LDAP URLs. If found, a recursive search +# is performed to retrieve the entry referenced by the DN, or +# the entries matched by the URL query. +# +# .nf +# special_result_attribute = memberdn +# .fi +# +# DN recursion retrieves the same result_attributes as the +# main query, including the special attributes for further +# recursion. +# +# URL processing retrieves only those attributes that are included +# in both the URL definition and as result attributes (ordinary, +# special, leaf or terminal) in the Postfix table definition. +# If the URL lists any of the table's special result attributes, +# these are retrieved and used recursively. A URL that does not +# specify any attribute selection, is equivalent (RFC 2255) to a +# URL that selects all attributes, in which case the selected +# attributes will be the full set of result attributes in the +# Postfix table. +# +# If an LDAP URL attribute-descriptor or the corresponding Postfix +# LDAP table result attribute (but not both) uses RFC 2255 sub-type +# options ("attr;option"), the attribute requested from the LDAP server +# will include the sub-type option. In all other cases, the URL +# attribute and the table attribute must match exactly. Attributes +# with options in both the URL and the Postfix table are requested +# only when the options are identical. LDAP attribute-descriptor +# options are very rarely used, most LDAP users will not +# need to concern themselves with this level of nuanced detail. +# .IP "\fBterminal_result_attribute (default: empty)\fR" +# When one or more terminal result attributes are found in an LDAP +# entry, all other result attributes are ignored and only the terminal +# result attributes are returned. This is useful for delegating expansion +# of group members to a particular host, by using an optional "maildrop" +# attribute on selected groups to route the group to a specific host, +# where the group is expanded, possibly via mailing-list manager or +# other special processing. +# +# .nf +# result_attribute = +# terminal_result_attribute = maildrop +# .fi +# +# When using terminal and/or leaf result attributes, the +# result_attribute is best set to an empty value when it is not +# used, or else explicitly set to the desired value, even if it is +# the default value "maildrop". +# +# This feature is available with Postfix 2.4 or later. +# .IP "\fBleaf_result_attribute (default: empty)\fR" +# When one or more special result attributes are found in a non-terminal +# (see above) LDAP entry, leaf result attributes are excluded from the +# expansion of that entry. This is useful when expanding groups and the +# desired mail address attribute(s) of the member objects obtained via +# DN or URI recursion are also present in the group object. To only +# return the attribute values from the leaf objects and not the +# containing group, add the attribute to the leaf_result_attribute list, +# and not the result_attribute list, which is always expanded. Note, +# the default value of "result_attribute" is not empty, you may want to +# set it explicitly empty when using "leaf_result_attribute" to expand +# the group to a list of member DN addresses. If groups have both +# member DN references AND attributes that hold multiple string valued +# rfc822 addresses, then the string attributes go in "result_attribute". +# The attributes that represent the email addresses of objects +# referenced via a DN (or LDAP URI) go in "leaf_result_attribute". +# +# .nf +# result_attribute = memberaddr +# special_result_attribute = memberdn +# terminal_result_attribute = maildrop +# leaf_result_attribute = mail +# .fi +# +# When using terminal and/or leaf result attributes, the +# result_attribute is best set to an empty value when it is not +# used, or else explicitly set to the desired value, even if it is +# the default value "maildrop". +# +# This feature is available with Postfix 2.4 or later. +# .IP "\fBscope (default: sub)\fR" +# The LDAP search scope: \fBsub\fR, \fBbase\fR, or \fBone\fR. +# These translate into LDAP_SCOPE_SUBTREE, LDAP_SCOPE_BASE, +# and LDAP_SCOPE_ONELEVEL. +# .IP "\fBbind (default: yes)\fR" +# Whether or how to bind to the LDAP server. Newer LDAP +# implementations don't require clients to bind, which saves +# time. Example: +# +# .nf +# # Don't bind +# bind = no +# # Use SIMPLE bind +# bind = yes +# # Use SASL bind +# bind = sasl +# .fi +# +# Postfix versions prior to 2.8 only support "bind = no" which +# means don't bind, and "bind = yes" which means do a SIMPLE bind. +# Postfix 2.8 and later also supports "bind = SASL" when compiled +# with LDAP SASL support as described in LDAP_README, it also adds +# the synonyms "bind = none" and "bind = simple" for "bind = no" +# and "bind = yes" respectively. See the SASL section below for +# additional parameters available with "bind = sasl". +# +# If you do need to bind, you might consider configuring +# Postfix to connect to the local machine on a port that's +# an SSL tunnel to your LDAP server. If your LDAP server +# doesn't natively support SSL, put a tunnel (wrapper, proxy, +# whatever you want to call it) on that system too. This +# should prevent the password from traversing the network in +# the clear. +# .IP "\fBbind_dn (default: empty)\fR" +# If you do have to bind, do it with this distinguished name. Example: +# +# .nf +# bind_dn = uid=postfix, dc=your, dc=com +# .fi +# With "bind = sasl" (see above) the DN may be optional for some SASL +# mechanisms, don't specify a DN if not needed. +# .IP "\fBbind_pw (default: empty)\fR" +# The password for the distinguished name above. If you have +# to use this, you probably want to make the map configuration +# file readable only by the Postfix user. When using the +# obsolete ldap:ldapsource syntax, with map parameters in +# main.cf, it is not possible to securely store the bind +# password. This is because main.cf needs to be world readable +# to allow local accounts to submit mail via the sendmail +# command. Example: +# +# .nf +# bind_pw = postfixpw +# .fi +# With "bind = sasl" (see above) the password may be optional +# for some SASL mechanisms, don't specify a password if not needed. +# .IP "\fBcache (IGNORED with a warning)\fR" +# .IP "\fBcache_expiry (IGNORED with a warning)\fR" +# .IP "\fBcache_size (IGNORED with a warning)\fR" +# The above parameters are NO LONGER SUPPORTED by Postfix. +# Cache support has been dropped from OpenLDAP as of release +# 2.1.13. +# .IP "\fBrecursion_limit (default: 1000)\fR" +# A limit on the nesting depth of DN and URL special result +# attribute evaluation. The limit must be a non-zero positive +# number. +# .IP "\fBexpansion_limit (default: 0)\fR" +# A limit on the total number of result elements returned +# (as a comma separated list) by a lookup against the map. +# A setting of zero disables the limit. Lookups fail with a +# temporary error if the limit is exceeded. Setting the +# limit to 1 ensures that lookups do not return multiple +# values. +# .IP "\fBsize_limit (default: $expansion_limit)\fR" +# A limit on the number of LDAP entries returned by any single +# LDAP search performed as part of the lookup. A setting of +# 0 disables the limit. Expansion of DN and URL references +# involves nested LDAP queries, each of which is separately +# subjected to this limit. +# +# Note: even a single LDAP entry can generate multiple lookup +# results, via multiple result attributes and/or multi-valued +# result attributes. This limit caps the per search resource +# utilization on the LDAP server, not the final multiplicity +# of the lookup result. It is analogous to the "-z" option +# of "ldapsearch". +# .IP "\fBdereference (default: 0)\fR" +# When to dereference LDAP aliases. (Note that this has +# nothing do with Postfix aliases.) The permitted values are +# those legal for the OpenLDAP/UM LDAP implementations: +# .RS +# .IP 0 +# never +# .IP 1 +# when searching +# .IP 2 +# when locating the base object for the search +# .IP 3 +# always +# .RE +# .IP +# See ldap.h or the ldap_open(3) or ldapsearch(1) man pages +# for more information. And if you're using an LDAP package +# that has other possible values, please bring it to the +# attention of the postfix-users@postfix.org mailing list. +# .IP "\fBchase_referrals (default: 0)\fR" +# Sets (or clears) LDAP_OPT_REFERRALS (requires LDAP version +# 3 support). +# .IP "\fBversion (default: 2)\fR" +# Specifies the LDAP protocol version to use. +# .IP "\fBdebuglevel (default: 0)\fR" +# What level to set for debugging in the OpenLDAP libraries. +# LDAP SASL PARAMETERS +# .ad +# .fi +# If you're using the OpenLDAP libraries compiled with SASL +# support, Postfix 2.8 and later built with LDAP SASL support +# as described in LDAP_README can authenticate to LDAP servers +# via SASL. +# +# This enables authentication to the LDAP server via mechanisms +# other than a simple password. The added flexibility has a cost: +# it is no longer practical to set an explicit timeout on the duration +# of an LDAP bind operation. Under adverse conditions, whether a SASL +# bind times out, or if it does, the duration of the timeout is +# determined by the LDAP and SASL libraries. +# +# It is best to use tables that use SASL binds via proxymap(8), this +# way the requesting process can time-out the proxymap request. This +# also lets you tailer the process environment by overriding the +# proxymap(8) import_environment setting in master.cf(5). Special +# environment settings may be needed to configure GSSAPI credential +# caches or other SASL mechanism specific options. The GSSAPI +# credentials used for LDAP lookups may need to be different than +# say those used for the Postfix SMTP client to authenticate to remote +# servers. +# +# Using SASL mechanisms requires LDAP protocol version 3, the default +# protocol version is 2 for backwards compatibility. You must set +# "version = 3" in addition to "bind = sasl". +# +# The following parameters are relevant to using LDAP with SASL +# .IP "\fBsasl_mechs (default: empty)\fR" +# Space separated list of SASL mechanism(s) to try. +# .IP "\fBsasl_realm (default: empty)\fR" +# SASL Realm to use, if applicable. +# .IP "\fBsasl_authz_id (default: empty)\fR" +# The SASL authorization identity to assert, if applicable. +# .IP "\fBsasl_minssf (default: 0)\fR" +# The minimum required sasl security factor required to establish a +# connection. +# LDAP SSL AND STARTTLS PARAMETERS +# .ad +# .fi +# If you're using the OpenLDAP libraries compiled with SSL +# support, Postfix can connect to LDAP SSL servers and can +# issue the STARTTLS command. +# +# LDAP SSL service can be requested by using a LDAP SSL URL +# in the server_host parameter: +# +# .nf +# server_host = ldaps://ldap.example.com:636 +# .fi +# +# STARTTLS can be turned on with the start_tls parameter: +# +# .nf +# start_tls = yes +# .fi +# +# Both forms require LDAP protocol version 3, which has to be set +# explicitly with: +# +# .nf +# version = 3 +# .fi +# +# If any of the Postfix programs querying the map is configured in +# master.cf to run chrooted, all the certificates and keys involved +# have to be copied to the chroot jail. Of course, the private keys +# should only be readable by the user "postfix". +# +# The following parameters are relevant to LDAP SSL and STARTTLS: +# .IP "\fBstart_tls (default: no)\fR" +# Whether or not to issue STARTTLS upon connection to the +# server. Don't set this with LDAP SSL (the SSL session is setup +# automatically when the TCP connection is opened). +# .IP "\fBtls_ca_cert_dir (No default; set either this or tls_ca_cert_file)\fR" +# Directory containing X509 Certification Authority certificates +# in PEM format which are to be recognized by the client in +# SSL/TLS connections. The files each contain one CA certificate. +# The files are looked up by the CA subject name hash value, +# which must hence be available. If more than one CA certificate +# with the same name hash value exist, the extension must be +# different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is +# performed in the ordering of the extension number, regardless +# of other properties of the certificates. Use the c_rehash +# utility (from the OpenSSL distribution) to create the +# necessary links. +# .IP "\fBtls_ca_cert_file (No default; set either this or tls_ca_cert_dir)\fR" +# File containing the X509 Certification Authority certificates +# in PEM format which are to be recognized by the client in +# SSL/TLS connections. This setting takes precedence over +# tls_ca_cert_dir. +# .IP "\fBtls_cert (No default; you must set this)\fR" +# File containing client's X509 certificate to be used by +# the client in SSL/ TLS connections. +# .IP "\fBtls_key (No default; you must set this)\fR" +# File containing the private key corresponding to the above +# tls_cert. +# .IP "\fBtls_require_cert (default: no)\fR" +# Whether or not to request server's X509 certificate and +# check its validity when establishing SSL/TLS connections. +# The supported values are \fBno\fR and \fByes\fR. +# .sp +# With \fBno\fR, the server certificate trust chain is not checked, +# but with OpenLDAP prior to 2.1.13, the name in the server +# certificate must still match the LDAP server name. With OpenLDAP +# 2.0.0 to 2.0.11 the server name is not necessarily what you +# specified, rather it is determined (by reverse lookup) from the +# IP address of the LDAP server connection. With OpenLDAP prior to +# 2.0.13, subjectAlternativeName extensions in the LDAP server +# certificate are ignored: the server name must match the subject +# CommonName. The \fBno\fR setting corresponds to the \fBnever\fR +# value of \fBTLS_REQCERT\fR in LDAP client configuration files. +# .sp +# Don't use TLS with OpenLDAP 2.0.x (and especially with x <= 11) +# if you can avoid it. +# .sp +# With \fByes\fR, the server certificate must be issued by a trusted +# CA, and not be expired. The LDAP server name must match one of the +# name(s) found in the certificate (see above for OpenLDAP library +# version dependent behavior). The \fByes\fR setting corresponds to the +# \fBdemand\fR value of \fBTLS_REQCERT\fR in LDAP client configuration +# files. +# .sp +# The "try" and "allow" values of \fBTLS_REQCERT\fR have no equivalents +# here. They are not available with OpenLDAP 2.0, and in any case have +# questionable security properties. Either you want TLS verified LDAP +# connections, or you don't. +# .sp +# The \fByes\fR value only works correctly with Postfix 2.5 and later, +# or with OpenLDAP 2.0. Earlier Postfix releases or later OpenLDAP +# releases don't work together with this setting. Support for LDAP +# over TLS was added to Postfix based on the OpenLDAP 2.0 API. +# .IP "\fBtls_random_file (No default)\fR" +# Path of a file to obtain random bits from when /dev/[u]random +# is not available, to be used by the client in SSL/TLS +# connections. +# .IP "\fBtls_cipher_suite (No default)\fR" +# Cipher suite to use in SSL/TLS negotiations. +# EXAMPLE +# .ad +# .fi +# Here's a basic example for using LDAP to look up local(8) +# aliases. +# Assume that in main.cf, you have: +# +# .nf +# alias_maps = hash:/etc/aliases, +# ldap:/etc/postfix/ldap-aliases.cf +# .fi +# +# and in ldap:/etc/postfix/ldap-aliases.cf you have: +# +# .nf +# server_host = ldap.example.com +# search_base = dc=example, dc=com +# .fi +# +# Upon receiving mail for a local address "ldapuser" that +# isn't found in the /etc/aliases database, Postfix will +# search the LDAP server listening at port 389 on ldap.example.com. +# It will bind anonymously, search for any directory entries +# whose mailacceptinggeneralid attribute is "ldapuser", read +# the "maildrop" attributes of those found, and build a list +# of their maildrops, which will be treated as RFC822 addresses +# to which the message will be delivered. +# OBSOLETE MAIN.CF PARAMETERS +# .ad +# .fi +# For backwards compatibility with Postfix version 2.0 and earlier, +# LDAP parameters can also be defined in main.cf. Specify +# as LDAP source a name that doesn't begin with a slash or +# a dot. The LDAP parameters will then be accessible as the +# name you've given the source in its definition, an underscore, +# and the name of the parameter. For example, if the map is +# specified as "ldap:\fIldapsource\fR", the "server_host" +# parameter below would be defined in main.cf as +# "\fIldapsource\fR_server_host". +# +# Note: with this form, the passwords for the LDAP sources are +# written in main.cf, which is normally world-readable. Support +# for this form will be removed in a future Postfix version. +# OTHER OBSOLETE FEATURES +# .ad +# .fi +# For backwards compatibility with the pre +# 2.2 LDAP clients, \fBresult_filter\fR can for now be used instead +# of \fBresult_format\fR, when the latter parameter is not also set. +# The new name better reflects the function of the parameter. This +# compatibility interface may be removed in a future release. +# SEE ALSO +# postmap(1), Postfix lookup table manager +# postconf(5), configuration parameters +# mysql_table(5), MySQL lookup tables +# pgsql_table(5), PostgreSQL lookup tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# LDAP_README, Postfix LDAP client guide +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# .ad +# .fi +# Carsten Hoeger, +# Hery Rakotoarisoa, +# John Hensley, +# Keith Stevenson, +# LaMont Jones, +# Liviu Daia, +# Manuel Guesdon, +# Mike Mattice, +# Prabhat K Singh, +# Sami Haahtinen, +# Samuel Tardieu, +# Victor Duchovni, +# and many others. +#-- diff --git a/proto/lmdb_table b/proto/lmdb_table new file mode 100644 index 0000000..53a9cd9 --- /dev/null +++ b/proto/lmdb_table @@ -0,0 +1,119 @@ +#++ +# NAME +# lmdb_table 5 +# SUMMARY +# Postfix LMDB adapter +# SYNOPSIS +# \fBpostmap lmdb:/etc/postfix/\fIfilename\fR +# .br +# \fBpostmap -i lmdb:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# +# \fBpostmap -d "\fIkey\fB" lmdb:/etc/postfix/\fIfilename\fR +# .br +# \fBpostmap -d - lmdb:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# +# \fBpostmap -q "\fIkey\fB" lmdb:/etc/postfix/\fIfilename\fR +# .br +# \fBpostmap -q - lmdb:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix LMDB adapter provides access to a persistent, +# memory-mapped, key-value store. The database size is limited +# only by the size of the memory address space (typically 31 +# or 47 bits on 32-bit or 64-bit CPUs, respectively) and by +# the available file system space. +# REQUESTS +# .ad +# .fi +# The LMDB adapter supports all Postfix lookup table operations. +# This makes LMDB suitable for Postfix address rewriting, +# routing, access policies, caches, or any information that +# can be stored under a fixed lookup key. +# +# When a transaction fails due to a full database, Postfix +# resizes the database and retries the transaction. +# +# Postfix table lookups may generate partial search keys such +# as domain names without one or more subdomains, network +# addresses without one or more least-significant octets, or +# email addresses without the localpart, address extension +# or domain portion. This behavior is also found with, for +# example, btree:, hash:, or ldap: tables. +# +# Unlike other flat-file Postfix databases, changes to +# an LMDB database do not trigger automatic daemon program +# restart, and do not require "\fBpostfix reload\fR". +# RELIABILITY +# .ad +# .fi +# LMDB's copy-on-write architecture provides safe updates, +# at the cost of using more space than some other flat-file +# databases. Read operations are memory-mapped for speed. +# Write operations are not memory-mapped to avoid silent +# corruption due to stray pointer bugs. +# +# Multiple processes can safely update an LMDB database without +# serializing requests through the proxymap(8) service. This +# makes LMDB suitable as a shared cache for verify(8) or +# postscreen(8) services. +# SYNCHRONIZATION +# .ad +# .fi +# The Postfix LMDB adapter does not use LMDB's built-in locking +# scheme, because that would require world-writable lockfiles +# and would violate the Postfix security model. Instead, +# Postfix uses fcntl(2) locks with whole-file granularity. +# Programs that use LMDB's built-in locking protocol will +# corrupt a Postfix LMDB database or will read garbage. +# +# Every Postfix LMDB database read or write transaction must +# be protected from start to end with a shared or exclusive +# fcntl(2) lock. A writer may atomically downgrade an exclusive +# lock to a shared lock, but it must hold an exclusive lock +# while opening another write transaction. +# +# Note that fcntl(2) locks do not protect transactions within +# the same process against each other. If a program cannot +# avoid making simultaneous database requests, then it must +# protect its transactions with in-process locks, in addition +# to the per-process fcntl(2) locks. +# CONFIGURATION PARAMETERS +# .ad +# .fi +# Short-lived programs automatically pick up changes to +# main.cf. With long-running daemon programs, Use the command +# "\fBpostfix reload\fR" after a configuration change. +# .IP "\fBlmdb_map_size (default: 16777216)\fR" +# The initial LMDB database size limit in bytes. +# SEE ALSO +# postconf(1), Postfix supported lookup tables +# postmap(1), Postfix lookup table maintenance +# postconf(5), configuration parameters +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# LMDB_README, Postfix OpenLDAP LMDB howto +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# HISTORY +# LMDB support was introduced with Postfix version 2.11. +# AUTHOR(S) +# Howard Chu +# Symas Corporation +# +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/manual-format b/proto/manual-format new file mode 100644 index 0000000..2e34b9a --- /dev/null +++ b/proto/manual-format @@ -0,0 +1,21 @@ +Be consistent and improve the order later. + +NAME +DESCRIPTION +SECURITY +STANDARDS +DIAGNOSTICS +BUGS +ENVIRONMENT +CONFIGURATION PARAMETERS +FILES +SEE ALSO +daemons +commands +configuration files +master +syslogd +README FILES +LICENSE +HISTORY +AUTHOR(S) diff --git a/proto/master b/proto/master new file mode 100644 index 0000000..670b800 --- /dev/null +++ b/proto/master @@ -0,0 +1,255 @@ +#++ +# NAME +# master 5 +# SUMMARY +# Postfix master process configuration file format +# DESCRIPTION +# The Postfix mail system is implemented by small number of +# (mostly) client commands that are invoked by users, and by +# a larger number of services that run in the background. +# +# Postfix services are implemented by daemon processes. These +# run in the background under control of the \fBmaster\fR(8) +# process. The master.cf configuration file defines how a +# client program connects to a service, and what daemon +# program runs when a service is requested. Most daemon +# processes are short-lived and terminate voluntarily after +# serving \fBmax_use\fR clients, or after inactivity for +# \fBmax_idle\fR or more units of time. +# +# All daemons specified here must speak a Postfix-internal +# protocol. In order to execute non-Postfix software use the +# \fBlocal\fR(8), \fBpipe\fR(8) or \fBspawn\fR(8) services, or +# run the server under control by \fBinetd\fR(8) or equivalent. +# .PP +# After changing master.cf you must execute "\fBpostfix reload\fR" +# to reload the configuration. +# SYNTAX +# .ad +# .fi +# The general format of the master.cf file is as follows: +# .IP \(bu +# Empty lines and whitespace-only lines are ignored, as are +# lines whose first non-whitespace character is a `#'. +# .IP \(bu +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# .IP \(bu +# Each logical line defines a single Postfix service. +# Each service is identified by its name and type as described +# below. When multiple lines specify the same service name +# and type, only the last one is remembered. Otherwise, the +# order of master.cf service definitions does not matter. +# .PP +# Each logical line consists of eight fields separated by +# whitespace. These are described below in the order as they +# appear in the master.cf file. +# +# Where applicable a field of "-" requests that the built-in +# default value be used. For boolean fields specify "y" or +# "n" to override the default value. +# .IP "\fBService name\fR" +# The service name syntax depends on the service type as +# described next. +# .IP "\fBService type\fR" +# Specify one of the following service types: +# .RS +# .IP \fBinet\fR +# The service listens on a TCP/IP socket and is accessible +# via the network. +# +# The service name is specified as \fIhost:port\fR, denoting +# the host and port on which new connections should be +# accepted. The host part (and colon) may be omitted. Either +# host or port may be given in symbolic form (see \fBhosts\fR(5) or +# \fBservices\fR(5)) or in numeric form (IP address or port number). +# Host information may be enclosed inside "[]"; this form +# is necessary only with IPv6 addresses. +# .sp +# Examples: a service named \fB127.0.0.1:smtp\fR or \fB::1:smtp\fR +# receives +# mail via the loopback interface only; and a service named +# \fB10025\fR accepts connections on TCP port 10025 via +# all interfaces configured with the \fBinet_interfaces\fR +# parameter. +# +# .sp +# Note: with Postfix version 2.2 and later specify +# "\fBinet_interfaces = loopback-only\fR" in main.cf, instead +# of hard-coding loopback IP address information in master.cf +# or in main.cf. +# .IP \fBunix\fR +# The service listens on a UNIX-domain stream socket and is +# accessible for local clients only. +# +# The service name is a pathname relative to the Postfix +# queue directory (pathname controlled with the \fBqueue_directory\fR +# configuration parameter in main.cf). +# .sp +# On Solaris 8 and earlier systems the \fBunix\fR type is +# implemented with streams sockets. +# .IP \fBunix-dgram\fR +# The service listens on a UNIX-domain datagram socket and is +# accessible for local clients only. +# +# The service name is a pathname relative to the Postfix +# queue directory (pathname controlled with the \fBqueue_directory\fR +# configuration parameter in main.cf). +# .IP "\fBfifo\fR (obsolete)" +# The service listens on a FIFO (named pipe) and is accessible +# for local clients only. +# +# The service name is a pathname relative to the Postfix +# queue directory (pathname controlled with the \fBqueue_directory\fR +# configuration parameter in main.cf). +# .IP \fBpass\fR +# The service listens on a UNIX-domain stream socket, and is +# accessible to local clients only. It receives one open +# connection (file descriptor passing) per connection request. +# +# The service name is a pathname relative to the Postfix +# queue directory (pathname controlled with the \fBqueue_directory\fR +# configuration parameter in main.cf). +# .sp +# On Solaris 8 and earlier systems the \fBpass\fR type is +# implemented with streams sockets. +# +# This feature is available as of Postfix version 2.5. +# .RE +# .IP "\fBPrivate (default: y)\fR" +# Whether or not access is restricted to the mail system. +# Internet (type \fBinet\fR) services can't be private. +# .IP "\fBUnprivileged (default: y)\fR" +# Whether the service runs with root privileges or as the +# owner of the Postfix system (the owner name is controlled +# by the \fBmail_owner\fR configuration variable in the +# main.cf file). +# .sp +# The \fBlocal\fR(8), \fBpipe\fR(8), \fBspawn\fR(8), and +# \fBvirtual\fR(8) daemons require privileges. +# .IP "\fBChroot (default: Postfix >= 3.0: n, Postfix <3.0: y)\fR" +# Whether or not the service runs chrooted to the mail queue +# directory (pathname is controlled by the \fBqueue_directory\fR +# configuration variable in the main.cf file). +# .sp +# Chroot should not be used with the \fBlocal\fR(8), +# \fBpipe\fR(8), \fBspawn\fR(8), and \fBvirtual\fR(8) daemons. +# Although the +# \fBproxymap\fR(8) server can run chrooted, doing so defeats +# most of the purpose of having that service in the first +# place. +# .sp +# The files in the examples/chroot-setup subdirectory of the +# Postfix source show how to set up a Postfix chroot environment +# on a variety of systems. See also BASIC_CONFIGURATION_README +# for issues related to running daemons chrooted. +# .IP "\fBWake up time (default: 0)\fR" +# Automatically wake up the named service after the specified +# number of seconds. The wake up is implemented by connecting +# to the service and sending a wake up request. A ? at the +# end of the wake-up time field requests that no wake up +# events be sent before the first time a service is used. +# Specify 0 for no automatic wake up. +# .sp +# The \fBpickup\fR(8), \fBqmgr\fR(8) and \fBflush\fR(8) +# daemons require a wake up timer. +# .IP "\fBProcess limit (default: $default_process_limit)\fR" +# The maximum number of processes that may execute this +# service simultaneously. Specify 0 for no process count limit. +# .sp +# NOTE: Some Postfix services must be configured as a +# single-process service (for example, \fBqmgr\fR(8)) and +# some services must be configured with no process limit (for +# example, \fBcleanup\fR(8)). These limits must not be +# changed. +# .IP "\fBCommand name + arguments\fR" +# The command to be executed. Characters that are special +# to the shell such as ">" or "|" have no special meaning +# here, and quotes cannot be used to protect arguments +# containing whitespace. To protect whitespace, use "{" +# and "}" as described below. +# .sp +# The command name is relative to the Postfix daemon directory +# (pathname is controlled by the \fBdaemon_directory\fR +# configuration variable). +# .sp +# The command argument syntax for specific commands is +# specified in the respective daemon manual page. +# .sp +# The following command-line options have the same effect for +# all daemon programs: +# .RS +# .IP \fB-D\fR +# Run the daemon under control by the command specified with +# the \fBdebugger_command\fR variable in the main.cf +# configuration file. See DEBUG_README for hints and tips. +# .IP "\fB-o { \fIname\fR = \fIvalue\fB }\fR (long form, Postfix >= 3.0)" +# .IP "\fB-o \fIname\fR=\fIvalue\fR (short form)" +# Override the named main.cf configuration parameter. The +# parameter value can refer to other parameters as \fI$name\fR +# etc., just like in main.cf. See \fBpostconf\fR(5) for +# syntax. +# .sp +# NOTE 1: With the "long form" shown above, whitespace +# after "{", around "=", and before "}" is ignored, and +# whitespace within the parameter value is preserved. +# .sp +# NOTE 2: with the "short form" shown above, do not specify +# whitespace around the "=" or in +# parameter values. To specify a parameter value that contains +# whitespace, use the long form described above, or use commas +# instead of spaces, or specify the value in main.cf. Example: +# .sp +# .nf +# /etc/postfix/master.cf: +# submission inet .... smtpd +# -o smtpd_xxx_yyy=$submission_xxx_yyy +# .sp +# /etc/postfix/main.cf +# submission_xxx_yyy = text with whitespace... +# .fi +# .sp +# NOTE 3: Over-zealous use of parameter overrides makes the +# Postfix configuration hard to understand and maintain. At +# a certain point, it might be easier to configure multiple +# instances of Postfix, instead of configuring multiple +# personalities via master.cf. +# .IP \fB-v\fR +# Increase the verbose logging level. Specify multiple \fB-v\fR +# options to make a Postfix daemon process increasingly verbose. +# .IP "Other command-line arguments" +# Specify "{" and "}" around command arguments that contain +# whitespace (Postfix 3.0 and later). Whitespace +# after "{" and before "}" is ignored. +# SEE ALSO +# master(8), process manager +# postconf(5), configuration parameters +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# BASIC_CONFIGURATION_README, basic configuration +# DEBUG_README, Postfix debugging +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Initial version by +# Magnus Baeck +# Lund Institute of Technology +# Sweden +# +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/memcache_table b/proto/memcache_table new file mode 100644 index 0000000..c97a9b4 --- /dev/null +++ b/proto/memcache_table @@ -0,0 +1,236 @@ +#++ +# NAME +# memcache_table 5 +# SUMMARY +# Postfix memcache client configuration +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" memcache:/etc/postfix/\fIfilename\fR +# +# \fBpostmap -q - memcache:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting or mail routing. These tables are usually in +# \fBdbm\fR or \fBdb\fR format. +# +# Alternatively, lookup tables can be specified as memcache +# instances. To use memcache lookups, define a memcache +# source as a lookup table in main.cf, for example: +# +# .nf +# virtual_alias_maps = memcache:/etc/postfix/memcache-aliases.cf +# .fi +# +# The file /etc/postfix/memcache-aliases.cf has the same +# format as the Postfix main.cf file, and specifies the +# parameters described below. +# +# The Postfix memcache client supports the lookup, update, +# delete and sequence (first/next) operations. The sequence +# operation requires a backup database that supports the +# operation. +# MEMCACHE MAIN PARAMETERS +# .ad +# .fi +# .IP "\fBmemcache (default: inet:localhost:11211)\fR" +# The memcache server (note: singular) that Postfix will try +# to connect to. For a TCP server specify "inet:" followed by +# a hostname or address, ":", and a port name or number. +# Specify an IPv6 address inside "[]". +# For a UNIX-domain server specify "unix:" followed by the +# socket pathname. Examples: +# +# .nf +# memcache = inet:memcache.example.com:11211 +# memcache = inet:127.0.0.1:11211 +# memcache = inet:[fc00:8d00:189::3]:11211 +# memcache = unix:/path/to/socket +# .fi +# +# NOTE: to access a UNIX-domain socket with the proxymap(8) +# server, the socket must be accessible by the unprivileged +# postfix user. +# .IP "\fBbackup (default: undefined)\fR" +# An optional Postfix database that provides persistent backup +# for the memcache database. The Postfix memcache client will +# update the memcache database whenever it looks up or changes +# information in the persistent database. Specify a Postfix +# "type:table" database. Examples: +# +# .nf +# # Non-shared postscreen cache. +# backup = btree:/var/lib/postfix/postscreen_cache_map +# +# # Shared postscreen cache for processes on the same host. +# backup = proxy:btree:/var/lib/postfix/postscreen_cache_map +# .fi +# +# Access to remote proxymap servers is under development. +# +# NOTE 1: When sharing a persistent \fBpostscreen\fR(8) or +# \fBverify\fR(8) cache, disable automatic cache cleanup (set +# *_cache_cleanup_interval = 0) except with one Postfix +# instance that will be responsible for cache cleanup. +# +# NOTE 2: When multiple tables share the same memcache +# database, each table should use the \fBkey_format\fR feature +# (see below) to prepend its own unique string to the lookup +# key. Otherwise, automatic \fBpostscreen\fR(8) or \fBverify\fR(8) +# cache cleanup may not work. +# +# NOTE 3: When the backup database is accessed with "proxy:" +# lookups, the full backup database name (including the +# "proxy:" prefix) must be specified in the proxymap server's +# proxy_read_maps or proxy_write_maps setting (depending on +# whether the access is read-only or read-write). +# .IP "\fBflags (default: 0)\fR" +# Optional flags that should be stored along with a memcache +# update. The flags are ignored when looking up information. +# .IP "\fBttl (default: 3600)\fR" +# The expiration time in seconds of memcache updates. +# +# NOTE 1: When using a memcache table as \fBpostscreen\fR(8) +# or \fBverify\fR(8) cache without persistent backup, specify +# a zero *_cache_cleanup_interval value with all Postfix +# instances that use the memcache, and specify the largest +# \fBpostscreen\fR(8) *_ttl value or \fBverify\fR(8) *_expire_time +# value as the memcache table's \fBttl\fR value. +# +# NOTE 2: According to memcache protocol documentation, a +# value greater than 30 days (2592000 seconds) specifies +# absolute UNIX +# time. Smaller values are relative to the time of the update. +# MEMCACHE KEY PARAMETERS +# .ad +# .fi +# .IP "\fBkey_format (default: %s)\fB" +# Format of the lookup and update keys that the Postfix +# memcache client sends to the memcache server. +# By default, these are the same as the lookup and update +# keys that the memcache client receives from Postfix +# applications. +# +# NOTE 1: The \fBkey_format\fR feature is not used for \fBbackup\fR +# database requests. +# +# NOTE 2: When multiple tables share the same memcache +# database, each table should prepend its own unique string +# to the lookup key. Otherwise, automatic \fBpostscreen\fR(8) +# or \fBverify\fR(8) cache cleanup may not work. +# +# Examples: +# +# .nf +# key_format = aliases:%s +# key_format = verify:%s +# key_format = postscreen:%s +# .fi +# +# The \fBkey_format\fR parameter supports the following '%' +# expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. +# .IP "\fB%s\fR" +# This is replaced by the memcache client input key. +# .IP "\fB%u\fR" +# When the input key is an address of the form user@domain, +# \fB%u\fR is replaced by the SQL quoted local part of the +# address. Otherwise, \fB%u\fR is replaced by the entire +# search string. If the localpart is empty, a lookup is +# silently suppressed and returns no results (an update is +# skipped with a warning). +# .IP "\fB%d\fR" +# When the input key is an address of the form user@domain, +# \fB%d\fR is replaced by the domain part of the address. +# Otherwise, a lookup is silently suppressed and returns no +# results (an update is skipped with a warning). +# .IP "\fB%[SUD]\fR" +# The upper-case equivalents of the above expansions behave +# in the \fBkey_format\fR parameter identically to their +# lower-case counter-parts. +# .IP "\fB%[1-9]\fR" +# The patterns %1, %2, ... %9 are replaced by the corresponding +# most significant component of the input key's domain. If +# the input key is \fIuser@mail.example.com\fR, then %1 is +# \fBcom\fR, %2 is \fBexample\fR and %3 is \fBmail\fR. If the +# input key is unqualified or does not have enough domain +# components to satisfy all the specified patterns, a lookup +# is silently suppressed and returns no results (an update +# is skipped with a warning). +# .RE +# .IP "\fBdomain (default: no domain list)\fR" +# This feature can significantly reduce database server load. +# Specify a list of domain names, paths to files, or "type:table" +# databases. +# When specified, only fully qualified search keys with a +# *non-empty* localpart and a matching domain are eligible +# for lookup or update: bare 'user' lookups, bare domain +# lookups and "@domain" lookups are silently skipped (updates +# are skipped with a warning). Example: +# +# .nf +# domain = example.com, hash:/etc/postfix/searchdomains +# .fi +# MEMCACHE ERROR CONTROLS +# .ad +# .fi +# .IP "\fBdata_size_limit (default: 10240)\fR" +# The maximal memcache reply data length in bytes. +# .IP "\fBline_size_limit (default: 1024)\fR" +# The maximal memcache reply line length in bytes. +# .IP "\fBmax_try (default: 2)\fR" +# The number of times to try a memcache command before giving +# up. The memcache client does not retry a command when the +# memcache server accepts no connection. +# .IP "\fBretry_pause (default: 1)\fR" +# The time in seconds before retrying a failed memcache command. +# .IP "\fBtimeout (default: 2)\fR" +# The time limit for sending a memcache command and for +# receiving a memcache reply. +# BUGS +# The Postfix memcache client cannot be used for security-sensitive +# tables such as \fBalias_maps\fR (these may contain +# "\fI|command\fR and "\fI/file/name\fR" destinations), or +# \fBvirtual_uid_maps\fR, \fBvirtual_gid_maps\fR and +# \fBvirtual_mailbox_maps\fR (these specify UNIX process +# privileges or "\fI/file/name\fR" destinations). In a typical +# deployment a memcache database is writable by any process +# that can talk to the memcache server; in contrast, +# security-sensitive tables must never be writable by the +# unprivileged Postfix user. +# +# The Postfix memcache client requires additional configuration +# when used as \fBpostscreen\fR(8) or \fBverify\fR(8) cache. +# For details see the \fBbackup\fR and \fBttl\fR parameter +# discussions in the MEMCACHE MAIN PARAMETERS section above. +# SEE ALSO +# postmap(1), Postfix lookup table manager +# postconf(5), configuration parameters +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# MEMCACHE_README, Postfix memcache client guide +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# HISTORY +# .ad +# .fi +# Memcache support was introduced with Postfix version 2.9. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/mysql_table b/proto/mysql_table new file mode 100644 index 0000000..b4c7c75 --- /dev/null +++ b/proto/mysql_table @@ -0,0 +1,400 @@ +#++ +# NAME +# mysql_table 5 +# SUMMARY +# Postfix MySQL client configuration +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" mysql:/etc/postfix/\fIfilename\fR +# +# \fBpostmap -q - mysql:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting or mail routing. These tables are usually in +# \fBdbm\fR or \fBdb\fR format. +# +# Alternatively, lookup tables can be specified as MySQL databases. +# In order to use MySQL lookups, define a MySQL source as a lookup +# table in main.cf, for example: +# .nf +# alias_maps = mysql:/etc/mysql-aliases.cf +# .fi +# +# The file /etc/postfix/mysql-aliases.cf has the same format as +# the Postfix main.cf file, and can specify the parameters +# described below. +# LIST MEMBERSHIP +# .ad +# .fi +# When using SQL to store lists such as $mynetworks, +# $mydestination, $relay_domains, $local_recipient_maps, +# etc., it is important to understand that the table must +# store each list member as a separate key. The table lookup +# verifies the *existence* of the key. See "Postfix lists +# versus tables" in the DATABASE_README document for a +# discussion. +# +# Do NOT create tables that return the full list of domains +# in $mydestination or $relay_domains etc., or IP addresses +# in $mynetworks. +# +# DO create tables with each matching item as a key and with +# an arbitrary value. With SQL databases it is not uncommon to +# return the key itself or a constant value. +# MYSQL PARAMETERS +# .ad +# .fi +# .IP "\fBhosts\fR" +# The hosts that Postfix will try to connect to and query from. +# Specify \fIunix:\fR for UNIX domain sockets, \fIinet:\fR for TCP +# connections (default). Example: +# .nf +# hosts = host1.some.domain host2.some.domain:port +# hosts = unix:/file/name +# .fi +# +# The hosts are tried in random order, with all connections over +# UNIX domain sockets being tried before those over TCP. The +# connections are automatically closed after being idle for about +# 1 minute, and are re-opened as necessary. Postfix versions 2.0 +# and earlier do not randomize the host order. +# +# NOTE: if you specify localhost as a hostname (even if you +# prefix it with \fIinet:\fR), MySQL will connect to the default +# UNIX domain socket. In order to instruct MySQL to connect to +# localhost over TCP you have to specify +# .nf +# hosts = 127.0.0.1 +# .fi +# .IP "\fBuser, password\fR" +# The user name and password to log into the mysql server. +# Example: +# .nf +# user = someone +# password = some_password +# .fi +# .IP "\fBdbname\fR" +# The database name on the servers. Example: +# .nf +# dbname = customer_database +# .fi +# .IP "\fBquery\fR" +# The SQL query template used to search the database, where \fB%s\fR +# is a substitute for the address Postfix is trying to resolve, +# e.g. +# .nf +# query = SELECT replacement FROM aliases WHERE mailbox = '%s' +# .fi +# +# By default, every query must return a result set (instead +# of storing its results in a table); with "\fBrequire_result_set +# = no\fR" (Postfix 3.2 and later), the absence of a result +# set is treated as "not found". +# +# This parameter supports the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. +# .IP "\fB%s\fR" +# This is replaced by the input key. +# SQL quoting is used to make sure that the input key does not +# add unexpected metacharacters. +# .IP "\fB%u\fR" +# When the input key is an address of the form user@domain, \fB%u\fR +# is replaced by the SQL quoted local part of the address. +# Otherwise, \fB%u\fR is replaced by the entire search string. +# If the localpart is empty, the query is suppressed and returns +# no results. +# .IP "\fB%d\fR" +# When the input key is an address of the form user@domain, \fB%d\fR +# is replaced by the SQL quoted domain part of the address. +# Otherwise, the query is suppressed and returns no results. +# .IP "\fB%[SUD]\fR" +# The upper-case equivalents of the above expansions behave in the +# \fBquery\fR parameter identically to their lower-case counter-parts. +# With the \fBresult_format\fR parameter (see below), they expand the +# input key rather than the result value. +# .IP "\fB%[1-9]\fR" +# The patterns %1, %2, ... %9 are replaced by the corresponding +# most significant component of the input key's domain. If the +# input key is \fIuser@mail.example.com\fR, then %1 is \fBcom\fR, +# %2 is \fBexample\fR and %3 is \fBmail\fR. If the input key is +# unqualified or does not have enough domain components to satisfy +# all the specified patterns, the query is suppressed and returns +# no results. +# .RE +# .IP +# The \fBdomain\fR parameter described below limits the input +# keys to addresses in matching domains. When the \fBdomain\fR +# parameter is non-empty, SQL queries for unqualified addresses +# or addresses in non-matching domains are suppressed +# and return no results. +# +# This parameter is available with Postfix 2.2. In prior releases +# the SQL query was built from the separate parameters: +# \fBselect_field\fR, \fBtable\fR, \fBwhere_field\fR and +# \fBadditional_conditions\fR. The mapping from the old parameters +# to the equivalent query is: +# +# .nf +# SELECT [\fBselect_field\fR] +# FROM [\fBtable\fR] +# WHERE [\fBwhere_field\fR] = '%s' +# [\fBadditional_conditions\fR] +# .fi +# +# The '%s' in the \fBWHERE\fR clause expands to the escaped search string. +# With Postfix 2.2 these legacy parameters are used if the \fBquery\fR +# parameter is not specified. +# +# NOTE: DO NOT put quotes around the query parameter. +# .IP "\fBresult_format (default: \fB%s\fR)\fR" +# Format template applied to result attributes. Most commonly used +# to append (or prepend) text to the result. This parameter supports +# the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. +# .IP "\fB%s\fR" +# This is replaced by the value of the result attribute. When +# result is empty it is skipped. +# .IP "\fB%u\fR +# When the result attribute value is an address of the form +# user@domain, \fB%u\fR is replaced by the local part of the +# address. When the result has an empty localpart it is skipped. +# .IP "\fB%d\fR" +# When a result attribute value is an address of the form +# user@domain, \fB%d\fR is replaced by the domain part of +# the attribute value. When the result is unqualified it +# is skipped. +# .IP "\fB%[SUD1-9]\fR" +# The upper-case and decimal digit expansions interpolate +# the parts of the input key rather than the result. Their +# behavior is identical to that described with \fBquery\fR, +# and in fact because the input key is known in advance, queries +# whose key does not contain all the information specified in +# the result template are suppressed and return no results. +# .RE +# .IP +# For example, using "result_format = smtp:[%s]" allows one +# to use a mailHost attribute as the basis of a transport(5) +# table. After applying the result format, multiple values +# are concatenated as comma separated strings. The expansion_limit +# and parameter explained below allows one to restrict the number +# of values in the result, which is especially useful for maps that +# must return at most one value. +# +# The default value \fB%s\fR specifies that each result value should +# be used as is. +# +# This parameter is available with Postfix 2.2 and later. +# +# NOTE: DO NOT put quotes around the result format! +# .IP "\fBdomain (default: no domain list)\fR" +# This is a list of domain names, paths to files, or +# dictionaries. When specified, only fully qualified search +# keys with a *non-empty* localpart and a matching domain +# are eligible for lookup: 'user' lookups, bare domain lookups +# and "@domain" lookups are not performed. This can significantly +# reduce the query load on the MySQL server. +# .nf +# domain = postfix.org, hash:/etc/postfix/searchdomains +# .fi +# +# It is best not to use SQL to store the domains eligible +# for SQL lookups. +# +# This parameter is available with Postfix 2.2 and later. +# +# NOTE: DO NOT define this parameter for local(8) aliases, +# because the input keys are always unqualified. +# .IP "\fBexpansion_limit (default: 0)\fR" +# A limit on the total number of result elements returned +# (as a comma separated list) by a lookup against the map. +# A setting of zero disables the limit. Lookups fail with a +# temporary error if the limit is exceeded. Setting the +# limit to 1 ensures that lookups do not return multiple +# values. +# .IP "\fBoption_file\fR" +# Read options from the given file instead of the default my.cnf +# location. This reads options from the \fB[client]\fR option +# group, optionally followed by options from the group given +# with \fBoption_group\fR. +# .sp +# This parameter is available with Postfix 2.11 and later. +# .IP "\fBoption_group (default: Postfix >=3.2: client, <= 3.1: empty)\fR" +# Read options from the given group of the mysql options file, +# after reading options from the \fB[client]\fR group. +# .sp +# Postfix 3.2 and later read \fB[client]\fR option group +# settings by default. To disable this specify no \fBoption_file\fR +# and specify "\fBoption_group =\fR" (i.e. an empty value). +# .sp +# Postfix 3.1 and earlier don't read \fB[client]\fR option +# group settings unless a non-empty \fBoption_file\fR or +# \fBoption_group\fR value are specified. To enable this, +# specify, for example, "\fBoption_group = client\fR". +# .sp +# This parameter is available with Postfix 2.11 and later. +# .IP "\fBrequire_result_set (default: yes)\fR" +# If "\fByes\fR", require that every query returns a result +# set. If "\fBno\fR", treat the absence of a result set as +# "not found". +# .sp +# This parameter is available with Postfix 3.2 and later. +# .IP "\fBtls_cert_file\fR" +# File containing client's X509 certificate. +# .sp +# This parameter is available with Postfix 2.11 and later. +# .IP "\fBtls_key_file\fR" +# File containing the private key corresponding to \fBtls_cert_file\fR. +# .sp +# This parameter is available with Postfix 2.11 and later. +# .IP "\fBtls_CAfile\fR" +# File containing certificates for all of the X509 Certification +# Authorities the client will recognize. Takes precedence over +# \fBtls_CApath\fR. +# .sp +# This parameter is available with Postfix 2.11 and later. +# .IP "\fBtls_CApath\fR" +# Directory containing X509 Certification Authority certificates +# in separate individual files. +# .sp +# This parameter is available with Postfix 2.11 and later. +# .IP "\fBtls_verify_cert (default: no)\fR" +# Verify that the server's name matches the common name in the +# certificate. +# .sp +# This parameter is available with Postfix 2.11 and later. +# USING MYSQL STORED PROCEDURES +# .ad +# .fi +# Postfix 3.2 and later support calling a stored procedure +# instead of using a SELECT statement in the query, e.g. +# +# .nf +# \fBquery\fR = CALL lookup('%s') +# .fi +# +# The previously described '%' expansions can be used in the +# parameter(s) to the stored procedure. +# +# By default, every stored procedure call must return a result +# set, i.e. every code path must execute a SELECT statement +# that returns a result set (instead of storing its results +# in a table). With "\fBrequire_result_set = no\fR", the +# absence of a result set is treated as "not found". +# +# A stored procedure must not return multiple result sets. +# That is, there must be no code path that executes multiple +# SELECT statements that return a result (instead of storing +# their results in a table). +# +# The following is an example of a stored procedure returning +# a single result set: +# +# .nf +# CREATE [DEFINER=`user`@`host`] PROCEDURE +# `lookup`(IN `param` VARCHAR(255)) +# READS SQL DATA +# SQL SECURITY INVOKER +# BEGIN +# select goto from alias where address=param; +# END +# .fi +# OBSOLETE MAIN.CF PARAMETERS +# .ad +# .fi +# For compatibility with other Postfix lookup tables, MySQL +# parameters can also be defined in main.cf. In order to do that, +# specify as MySQL source a name that doesn't begin with a slash +# or a dot. The MySQL parameters will then be accessible as the +# name you've given the source in its definition, an underscore, +# and the name of the parameter. For example, if the map is +# specified as "mysql:\fImysqlname\fR", the parameter "hosts" +# would be defined in main.cf as "\fImysqlname\fR_hosts". +# +# Note: with this form, the passwords for the MySQL sources are +# written in main.cf, which is normally world-readable. Support +# for this form will be removed in a future Postfix version. +# OBSOLETE QUERY INTERFACE +# .ad +# .fi +# This section describes an interface that is deprecated as +# of Postfix 2.2. It is replaced by the more general \fBquery\fR +# interface described above. If the \fBquery\fR parameter +# is defined, the legacy parameters described here ignored. +# Please migrate to the new interface as the legacy interface +# may be removed in a future release. +# +# The following parameters can be used to fill in a +# SELECT template statement of the form: +# +# .nf +# SELECT [\fBselect_field\fR] +# FROM [\fBtable\fR] +# WHERE [\fBwhere_field\fR] = '%s' +# [\fBadditional_conditions\fR] +# .fi +# +# The specifier %s is replaced by the search string, and is +# escaped so if it contains single quotes or other odd characters, +# it will not cause a parse error, or worse, a security problem. +# .IP "\fBselect_field\fR" +# The SQL "select" parameter. Example: +# .nf +# \fBselect_field\fR = forw_addr +# .fi +# .IP "\fBtable\fR" +# The SQL "select .. from" table name. Example: +# .nf +# \fBtable\fR = mxaliases +# .fi +# .IP "\fBwhere_field\fR +# The SQL "select .. where" parameter. Example: +# .nf +# \fBwhere_field\fR = alias +# .fi +# .IP "\fBadditional_conditions\fR +# Additional conditions to the SQL query. Example: +# .nf +# \fBadditional_conditions\fR = AND status = 'paid' +# .fi +# SEE ALSO +# postmap(1), Postfix lookup table maintenance +# postconf(5), configuration parameters +# ldap_table(5), LDAP lookup tables +# pgsql_table(5), PostgreSQL lookup tables +# sqlite_table(5), SQLite lookup tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# MYSQL_README, Postfix MYSQL client guide +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# HISTORY +# MySQL support was introduced with Postfix version 1.0. +# AUTHOR(S) +# Original implementation by: +# Scott Cotton, Joshua Marcus +# IC Group, Inc. +# +# Further enhancements by: +# Liviu Daia +# Institute of Mathematics of the Romanian Academy +# P.O. BOX 1-764 +# RO-014700 Bucharest, ROMANIA +# +# Stored-procedure support by John Fawcett. +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/nisplus_table b/proto/nisplus_table new file mode 100644 index 0000000..2c8aefc --- /dev/null +++ b/proto/nisplus_table @@ -0,0 +1,89 @@ +#++ +# NAME +# nisplus_table 5 +# SUMMARY +# Postfix NIS+ client +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" "nisplus:[\fIname\fB=%s];\fIname.name.\fB"\fR +# +# \fBpostmap -q - "nisplus:[\fIname\fB=%s];\fIname.name.\fB" <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional lookup tables. +# These tables are usually in \fBdbm\fR or \fBdb\fR format. +# Alternatively, lookup tables can be specified as NIS+ +# databases. +# +# To find out what types of lookup tables your Postfix system +# supports use the "\fBpostconf -m\fR" command. +# +# To test Postfix NIS+ lookup tables, use the "\fBpostmap -q\fR" +# command as described in the SYNOPSIS above. +# QUERY SYNTAX +# .ad +# .fi +# Most of the NIS+ query is specified via the NIS+ map name. The +# general format of a Postfix NIS+ map name is as follows: +# +# .fi +# \fBnisplus:[\fIname\fB=%s];\fIname.name.name\fB.:\fIcolumn\fR +# .fi +# +# Postfix NIS+ map names differ from what one normally +# would use with commands such as \fBniscat\fR: +# .IP \(bu +# With each NIS+ table lookup, "\fB%s\fR" is replaced by a +# version of the lookup string. There can be only one +# "\fB%s\fR" instance in a Postfix NIS+ map name. +# .IP \(bu +# Postfix NIS+ map names use "\fB;\fR" instead of "\fB,\fR", +# because the latter character is special in the Postfix +# main.cf file. Postfix replaces "\fB;\fR" characters in +# the map name by "\fB,\fR" before making NIS+ queries. +# .IP \(bu +# The ":\fIcolumn\fR" part in the NIS+ map name is not part +# of the actual NIS+ query. Instead, it specifies the number +# of the table column that provides the lookup result. When +# no ":\fIcolumn\fR" is specified the first column (1) is used. +# EXAMPLE +# .ad +# .fi +# A NIS+ aliases map might be queried as follows: +# +# .nf +# alias_maps = dbm:/etc/mail/aliases, +# nisplus:[alias=%s];mail_aliases.org_dir.$mydomain.:1 +# .fi +# +# This queries the local aliases file before the NIS+ file. +# SEE ALSO +# postmap(1), Postfix lookup table manager +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Geoff Gibbs +# UK-HGMP-RC +# Hinxton +# Cambridge +# CB10 1SB, UK +# +# Adopted and adapted by: +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/pcre_table b/proto/pcre_table new file mode 100644 index 0000000..7f15a81 --- /dev/null +++ b/proto/pcre_table @@ -0,0 +1,210 @@ +#++ +# NAME +# pcre_table 5 +# SUMMARY +# format of Postfix PCRE tables +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" pcre:/etc/postfix/\fIfilename\fR +# +# \fBpostmap -q - pcre:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# +# \fBpostmap -hmq - pcre:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# +# \fBpostmap -bmq - pcre:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting, mail routing, or access control. These tables +# are usually in \fBdbm\fR or \fBdb\fR format. +# +# Alternatively, lookup tables can be specified in Perl Compatible +# Regular Expression form. In this case, each input is compared +# against a list of patterns. When a match is found, the +# corresponding result is returned and the search is terminated. +# +# To find out what types of lookup tables your Postfix system +# supports use the "\fBpostconf -m\fR" command. +# +# To test lookup tables, use the "\fBpostmap -q\fR" command +# as described in the SYNOPSIS above. Use "\fBpostmap -hmq +# -\fR <\fIfile\fR" for header_checks(5) patterns, and +# "\fBpostmap -bmq -\fR <\fIfile\fR" for body_checks(5) +# (Postfix 2.6 and later). +# COMPATIBILITY +# .ad +# .fi +# With Postfix version 2.2 and earlier specify "\fBpostmap +# -fq\fR" to query a table that contains case sensitive +# patterns. Patterns are case insensitive by default. +# TABLE FORMAT +# .ad +# .fi +# The general form of a PCRE table is: +# .IP "\fB/\fIpattern\fB/\fIflags result\fR" +# When \fIpattern\fR matches the input string, use +# the corresponding \fIresult\fR value. +# .IP "\fB!/\fIpattern\fB/\fIflags result\fR" +# When \fIpattern\fR does \fBnot\fR match the input string, use +# the corresponding \fIresult\fR value. +# .IP "\fBif /\fIpattern\fB/\fIflags\fR" +# .IP "\fBendif\fR" +# If the input string matches /\fIpattern\fR/, then match that +# input string against the patterns between \fBif\fR and +# \fBendif\fR. The \fBif\fR..\fBendif\fR can nest. +# .sp +# Note: do not prepend whitespace to patterns inside +# \fBif\fR..\fBendif\fR. +# .sp +# This feature is available in Postfix 2.1 and later. +# .IP "\fBif !/\fIpattern\fB/\fIflags\fR" +# .IP "\fBendif\fR" +# If the input string does not match /\fIpattern\fR/, then +# match that input string against the patterns between \fBif\fR +# and \fBendif\fR. The \fBif\fR..\fBendif\fR can nest. +# .sp +# Note: do not prepend whitespace to patterns inside +# \fBif\fR..\fBendif\fR. +# .sp +# This feature is available in Postfix 2.1 and later. +# .IP "blank lines and comments" +# Empty lines and whitespace-only lines are ignored, as +# are lines whose first non-whitespace character is a `#'. +# .IP "multi-line text" +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# .PP +# Each pattern is a perl-like regular expression. The expression +# delimiter can be any non-alphanumerical character, except +# whitespace or characters +# that have special meaning (traditionally the forward slash is used). +# The regular expression can contain whitespace. +# +# By default, matching is case-insensitive, and newlines are not +# treated as special characters. The behavior is controlled by flags, +# which are toggled by appending one or more of the following +# characters after the pattern: +# .IP "\fBi\fR (default: on)" +# Toggles the case sensitivity flag. By default, matching is case +# insensitive. +# .IP "\fBm\fR (default: off)" +# Toggles the PCRE_MULTILINE flag. When this flag is on, the \fB^\fR +# and \fB$\fR metacharacters match immediately after and immediately +# before a newline character, respectively, in addition to +# matching at the start and end of the subject string. +# .IP "\fBs\fR (default: on)" +# Toggles the PCRE_DOTALL flag. When this flag is on, the \fB.\fR +# metacharacter matches the newline character. With +# Postfix versions prior to 2.0, the flag is off by +# default, which is inconvenient for multi-line message header +# matching. +# .IP "\fBx\fR (default: off)" +# Toggles the pcre extended flag. When this flag is on, whitespace +# characters in the pattern (other than in a character class) +# are ignored. To include a whitespace character as part of +# the pattern, escape it with backslash. +# .sp +# Note: do not use \fB#\fIcomment\fR after patterns. +# .IP "\fBA\fR (default: off)" +# Toggles the PCRE_ANCHORED flag. When this flag is on, +# the pattern is forced to be "anchored", that is, it is +# constrained to match only at the start of the string which +# is being searched (the "subject string"). This effect can +# also be achieved by appropriate constructs in the pattern +# itself. +# .IP "\fBE\fR (default: off)" +# Toggles the PCRE_DOLLAR_ENDONLY flag. When this flag is on, +# a \fB$\fR metacharacter in the pattern matches only at the +# end of the subject string. Without this flag, a dollar also +# matches immediately before the final character if it is a +# newline character (but not before any other newline +# characters). This flag is ignored if PCRE_MULTILINE +# flag is set. +# .IP "\fBU\fR (default: off)" +# Toggles the ungreedy matching flag. When this flag is on, +# the pattern matching engine inverts the "greediness" of +# the quantifiers so that they are not greedy by default, +# but become greedy if followed by "?". This flag can also +# set by a (?U) modifier within the pattern. +# .IP "\fBX\fR (default: off)" +# Toggles the PCRE_EXTRA flag. +# When this flag is on, any backslash in a pattern that is +# followed by a letter that has no special meaning causes an +# error, thus reserving these combinations for future expansion. +# SEARCH ORDER +# .ad +# .fi +# Patterns are applied in the order as specified in the table, until a +# pattern is found that matches the input string. +# +# Each pattern is applied to the entire input string. +# Depending on the application, that string is an entire client +# hostname, an entire client IP address, or an entire mail address. +# Thus, no parent domain or parent network search is done, and +# \fIuser@domain\fR mail addresses are not broken up into their +# \fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR +# broken up into \fIuser\fR and \fIfoo\fR. +# TEXT SUBSTITUTION +# .ad +# .fi +# Substitution of substrings (text that matches patterns +# inside "()") from the matched expression into the result +# string is requested with $1, $2, etc.; specify $$ to produce +# a $ character as output. +# The macros in the result string may need to be written as +# ${n} or $(n) if they aren't followed by whitespace. +# +# Note: since negated patterns (those preceded by \fB!\fR) return a +# result when the expression does not match, substitutions are not +# available for negated patterns. +# EXAMPLE SMTPD ACCESS MAP +# # Protect your outgoing majordomo exploders +# /^(?!owner-)(.*)-outgoing@(.*)/ 550 Use ${1}@${2} instead +# +# # Bounce friend@whatever, except when whatever is our domain (you would +# # be better just bouncing all friend@ mail - this is just an example). +# /^(friend@(?!my\\.domain$).*)$/ 550 Stick this in your pipe $1 +# +# # A multi-line entry. The text is sent as one line. +# # +# /^noddy@my\\.domain$/ +# \ 550 This user is a funny one. You really don't want to send mail to +# \ them as it only makes their head spin. +# EXAMPLE HEADER FILTER MAP +# /^Subject: make money fast/ REJECT +# /^To: friend@public\\.com/ REJECT +# EXAMPLE BODY FILTER MAP +# # First skip over base 64 encoded text to save CPU cycles. +# # Requires PCRE version 3. +# ~^[[:alnum:]+/]{60,}$~ OK +# +# # Put your own body patterns here. +# SEE ALSO +# postmap(1), Postfix lookup table manager +# postconf(5), configuration parameters +# regexp_table(5), format of POSIX regular expression tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# AUTHOR(S) +# The PCRE table lookup code was originally written by: +# Andrew McNamara +# andrewm@connect.com.au +# connect.com.au Pty. Ltd. +# Level 3, 213 Miller St +# North Sydney, NSW, Australia +# +# Adopted and adapted by: +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/pgsql_table b/proto/pgsql_table new file mode 100644 index 0000000..fefc7a8 --- /dev/null +++ b/proto/pgsql_table @@ -0,0 +1,318 @@ +#++ +# NAME +# pgsql_table 5 +# SUMMARY +# Postfix PostgreSQL client configuration +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" pgsql:/etc/postfix/\fIfilename\fR +# +# \fBpostmap -q - pgsql:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting or mail routing. These tables are usually in +# \fBdbm\fR or \fBdb\fR format. +# +# Alternatively, lookup tables can be specified as PostgreSQL +# databases. In order to use PostgreSQL lookups, define a +# PostgreSQL source as a lookup table in main.cf, for example: +# .nf +# alias_maps = pgsql:/etc/pgsql-aliases.cf +# .fi +# +# The file /etc/postfix/pgsql-aliases.cf has the same format as +# the Postfix main.cf file, and can specify the parameters +# described below. +# LIST MEMBERSHIP +# .ad +# .fi +# When using SQL to store lists such as $mynetworks, +# $mydestination, $relay_domains, $local_recipient_maps, +# etc., it is important to understand that the table must +# store each list member as a separate key. The table lookup +# verifies the *existence* of the key. See "Postfix lists +# versus tables" in the DATABASE_README document for a +# discussion. +# +# Do NOT create tables that return the full list of domains +# in $mydestination or $relay_domains etc., or IP addresses +# in $mynetworks. +# +# DO create tables with each matching item as a key and with +# an arbitrary value. With SQL databases it is not uncommon to +# return the key itself or a constant value. +# PGSQL PARAMETERS +# .ad +# .fi +# .IP "\fBhosts\fR" +# The hosts that Postfix will try to connect to and query +# from. Besides a \fBpostgresql://\fR connection URI, this +# setting supports the historical forms \fBunix:/\fIpathname\fR +# for UNIX-domain sockets and \fBinet:\fIhost:port\fR for TCP +# connections, where the \fBunix:\fR and \fBinet:\fR prefixes +# are accepted and ignored for backwards compatibility. +# Examples: +# .nf +# hosts = postgresql://username@example.com/tablename?sslmode=require +# hosts = host1.some.domain host2.some.domain:port +# hosts = unix:/file/name +# .fi +# +# The hosts are tried in random order. The connections are +# automatically closed after being idle for about 1 minute, +# and are re-opened as necessary. +# .IP "\fBuser, password\fR" +# The user name and password to log into the pgsql server. +# Example: +# .nf +# user = someone +# password = some_password +# .fi +# .IP "\fBdbname\fR" +# The database name on the servers. Example: +# .nf +# dbname = customer_database +# .fi +# .IP "\fBquery\fR" +# The SQL query template used to search the database, where \fB%s\fR +# is a substitute for the address Postfix is trying to resolve, +# e.g. +# .nf +# query = SELECT replacement FROM aliases WHERE mailbox = '%s' +# .fi +# +# This parameter supports the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. (Postfix 2.2 and later) +# .IP "\fB%s\fR" +# This is replaced by the input key. +# SQL quoting is used to make sure that the input key does not +# add unexpected metacharacters. +# .IP "\fB%u\fR" +# When the input key is an address of the form user@domain, \fB%u\fR +# is replaced by the SQL quoted local part of the address. +# Otherwise, \fB%u\fR is replaced by the entire search string. +# If the localpart is empty, the query is suppressed and returns +# no results. +# .IP "\fB%d\fR" +# When the input key is an address of the form user@domain, \fB%d\fR +# is replaced by the SQL quoted domain part of the address. +# Otherwise, the query is suppressed and returns no results. +# .IP "\fB%[SUD]\fR" +# The upper-case equivalents of the above expansions behave in the +# \fBquery\fR parameter identically to their lower-case counter-parts. +# With the \fBresult_format\fR parameter (see below), they expand the +# input key rather than the result value. +# .IP +# The above %S, %U and %D expansions are available with Postfix 2.2 +# and later +# .IP "\fB%[1-9]\fR" +# The patterns %1, %2, ... %9 are replaced by the corresponding +# most significant component of the input key's domain. If the +# input key is \fIuser@mail.example.com\fR, then %1 is \fBcom\fR, +# %2 is \fBexample\fR and %3 is \fBmail\fR. If the input key is +# unqualified or does not have enough domain components to satisfy +# all the specified patterns, the query is suppressed and returns +# no results. +# .IP +# The above %1, ... %9 expansions are available with Postfix 2.2 +# and later +# .RE +# .IP +# The \fBdomain\fR parameter described below limits the input +# keys to addresses in matching domains. When the \fBdomain\fR +# parameter is non-empty, SQL queries for unqualified addresses +# or addresses in non-matching domains are suppressed +# and return no results. +# +# The precedence of this parameter has changed with Postfix 2.2, +# in prior releases the precedence was, from highest to lowest, +# \fBselect_function\fR, \fBquery\fR, \fBselect_field\fR, ... +# +# With Postfix 2.2 the \fBquery\fR parameter has highest precedence, +# see COMPATIBILITY above. +# +# NOTE: DO NOT put quotes around the \fBquery\fR parameter. +# .IP "\fBresult_format (default: \fB%s\fR)\fR" +# Format template applied to result attributes. Most commonly used +# to append (or prepend) text to the result. This parameter supports +# the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. +# .IP "\fB%s\fR" +# This is replaced by the value of the result attribute. When +# result is empty it is skipped. +# .IP "\fB%u\fR +# When the result attribute value is an address of the form +# user@domain, \fB%u\fR is replaced by the local part of the +# address. When the result has an empty localpart it is skipped. +# .IP "\fB%d\fR" +# When a result attribute value is an address of the form +# user@domain, \fB%d\fR is replaced by the domain part of +# the attribute value. When the result is unqualified it +# is skipped. +# .IP "\fB%[SUD1-9]\fR" +# The upper-case and decimal digit expansions interpolate +# the parts of the input key rather than the result. Their +# behavior is identical to that described with \fBquery\fR, +# and in fact because the input key is known in advance, queries +# whose key does not contain all the information specified in +# the result template are suppressed and return no results. +# .RE +# .IP +# For example, using "result_format = smtp:[%s]" allows one +# to use a mailHost attribute as the basis of a transport(5) +# table. After applying the result format, multiple values +# are concatenated as comma separated strings. The expansion_limit +# and parameter explained below allows one to restrict the number +# of values in the result, which is especially useful for maps that +# must return at most one value. +# +# The default value \fB%s\fR specifies that each result value should +# be used as is. +# +# This parameter is available with Postfix 2.2 and later. +# +# NOTE: DO NOT put quotes around the result format! +# .IP "\fBdomain (default: no domain list)\fR" +# This is a list of domain names, paths to files, or +# dictionaries. When specified, only fully qualified search +# keys with a *non-empty* localpart and a matching domain +# are eligible for lookup: 'user' lookups, bare domain lookups +# and "@domain" lookups are not performed. This can significantly +# reduce the query load on the PostgreSQL server. +# .nf +# domain = postfix.org, hash:/etc/postfix/searchdomains +# .fi +# +# It is best not to use SQL to store the domains eligible +# for SQL lookups. +# +# This parameter is available with Postfix 2.2 and later. +# +# NOTE: DO NOT define this parameter for local(8) aliases, +# because the input keys are always unqualified. +# .IP "\fBexpansion_limit (default: 0)\fR" +# A limit on the total number of result elements returned +# (as a comma separated list) by a lookup against the map. +# A setting of zero disables the limit. Lookups fail with a +# temporary error if the limit is exceeded. Setting the +# limit to 1 ensures that lookups do not return multiple +# values. +# OBSOLETE MAIN.CF PARAMETERS +# .ad +# .fi +# For compatibility with other Postfix lookup tables, PostgreSQL +# parameters can also be defined in main.cf. In order to do +# that, specify as PostgreSQL source a name that doesn't begin +# with a slash or a dot. The PostgreSQL parameters will then +# be accessible as the name you've given the source in its +# definition, an underscore, and the name of the parameter. For +# example, if the map is specified as "pgsql:\fIpgsqlname\fR", +# the parameter "hosts" would be defined in main.cf as +# "\fIpgsqlname\fR_hosts". +# +# Note: with this form, the passwords for the PostgreSQL sources +# are written in main.cf, which is normally world-readable. +# Support for this form will be removed in a future Postfix +# version. +# OBSOLETE QUERY INTERFACES +# .ad +# .fi +# This section describes query interfaces that are deprecated +# as of Postfix 2.2. Please migrate to the new \fBquery\fR +# interface as the old interfaces are slated to be phased +# out. +# .IP "\fBselect_function\fR" +# This parameter specifies a database function name. Example: +# .nf +# select_function = my_lookup_user_alias +# .fi +# +# This is equivalent to: +# .nf +# query = SELECT my_lookup_user_alias('%s') +# .fi +# +# This parameter overrides the legacy table-related fields (described +# below). With Postfix versions prior to 2.2, it also overrides the +# \fBquery\fR parameter. Starting with Postfix 2.2, the \fBquery\fR +# parameter has highest precedence, and the \fBselect_function\fR +# parameter is deprecated. +# .PP +# The following parameters (with lower precedence than the +# \fBselect_function\fR interface described above) can be used to +# build the SQL select statement as follows: +# +# .nf +# SELECT [\fBselect_field\fR] +# FROM [\fBtable\fR] +# WHERE [\fBwhere_field\fR] = '%s' +# [\fBadditional_conditions\fR] +# .fi +# +# The specifier %s is replaced with each lookup by the lookup key +# and is escaped so if it contains single quotes or other odd +# characters, it will not cause a parse error, or worse, a security +# problem. +# +# Starting with Postfix 2.2, this interface is obsoleted by the more +# general \fBquery\fR interface described above. If higher precedence +# the \fBquery\fR or \fBselect_function\fR parameters described above +# are defined, the parameters described here are ignored. +# .IP "\fBselect_field\fR" +# The SQL "select" parameter. Example: +# .nf +# \fBselect_field\fR = forw_addr +# .fi +# .IP "\fBtable\fR" +# The SQL "select .. from" table name. Example: +# .nf +# \fBtable\fR = mxaliases +# .fi +# .IP "\fBwhere_field\fR +# The SQL "select .. where" parameter. Example: +# .nf +# \fBwhere_field\fR = alias +# .fi +# .IP "\fBadditional_conditions\fR +# Additional conditions to the SQL query. Example: +# .nf +# \fBadditional_conditions\fR = AND status = 'paid' +# .fi +# SEE ALSO +# postmap(1), Postfix lookup table manager +# postconf(5), configuration parameters +# ldap_table(5), LDAP lookup tables +# mysql_table(5), MySQL lookup tables +# sqlite_table(5), SQLite lookup tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# PGSQL_README, Postfix PostgreSQL client guide +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# HISTORY +# PgSQL support was introduced with Postfix version 2.1. +# AUTHOR(S) +# Based on the MySQL client by: +# Scott Cotton, Joshua Marcus +# IC Group, Inc. +# +# Ported to PostgreSQL by: +# Aaron Sethman +# +# Further enhanced by: +# Liviu Daia +# Institute of Mathematics of the Romanian Academy +# P.O. BOX 1-764 +# RO-014700 Bucharest, ROMANIA +#-- diff --git a/proto/postconf.html.epilog b/proto/postconf.html.epilog new file mode 100644 index 0000000..46a20e9 --- /dev/null +++ b/proto/postconf.html.epilog @@ -0,0 +1,5 @@ + + + + + diff --git a/proto/postconf.html.prolog b/proto/postconf.html.prolog new file mode 100644 index 0000000..a7d41ee --- /dev/null +++ b/proto/postconf.html.prolog @@ -0,0 +1,105 @@ + + + + + + +Postfix Configuration Parameters + + + + + + + +

Postfix Configuration Parameters

+ +
+ +

Postfix main.cf file format

+ +

The Postfix main.cf configuration file specifies a very small +subset of all the parameters that control the operation of the +Postfix mail system. Parameters not explicitly specified are left +at their default values.

+ +

The general format of the main.cf file is as follows:

+ +
    + +

  • Each logical line is in the form "parameter = value". +Whitespace around the "=" is ignored, as is whitespace at the end +of a logical line.

    + +

  • Empty lines and whitespace-only lines are ignored, as are +lines whose first non-whitespace character is a `#'.

    + +

  • A logical line starts with non-whitespace text. A line +that starts with whitespace continues a logical line.

    + +

  • A parameter value may refer to other parameters.

    + +
      + +

    • The expressions "$name" and "${name}" are recursively +replaced with the value of the named parameter. The parameter name +must contain only characters from the set [a-zA-Z0-9_]. +An undefined parameter value is replaced with the empty value.

      + +

    • The expressions "${name?value}" and "${name?{value}}" are +replaced with "value" when "$name" is non-empty. The parameter name +must contain only characters from the set [a-zA-Z0-9_]. These forms are +supported with Postfix versions ≥ 2.2 and ≥ 3.0, respectively. +

      + +

    • The expressions "${name:value}" and "${name:{value}}" are +replaced with "value" when "$name" is empty. The parameter name must +contain only characters from the set [a-zA-Z0-9_]. These forms are +supported with Postfix versions ≥ 2.2 and ≥ 3.0, respectively. +

      + +

    • The expression "${name?{value1}:{value2}}" is replaced +with "value1" when "$name" is non-empty, and with "value2" when +"$name" is empty. The "{}" is required for "value1", optional for +"value2". The parameter name must contain only characters from the +set [a-zA-Z0-9_]. This form is supported with Postfix versions +≥ 3.0.

      + +

    • The first item inside "${...}" may be a relational expression +of the form: "{value3} == {value4}". Besides the "==" (equality) +operator Postfix supports "!=" (inequality), "<", "≤", "≥", +and ">". The comparison is numerical when both operands are all +digits, otherwise the comparison is lexicographical. These forms +are supported with Postfix versions ≥ 3.0.

      + +

    • Each "value" is subject to recursive named parameter and +relational expression evaluation, except where noted.

      + +

    • Whitespace before or after each "{value}" is ignored.

      + +

    • Specify "$$" to produce a single "$" character.

      + +

    • The legacy form "$(...)" is equivalent to the preferred +form "${...}".

      + +
    + +

  • When the same parameter is defined multiple times, only +the last instance is remembered.

    + +

  • Otherwise, the order of main.cf parameter definitions does +not matter.

    + +
+ +

The remainder of this document is a description of all Postfix +configuration parameters. Default values are shown after the +parameter name in parentheses, and can be looked up with the +"postconf -d" command.

+ +

Note: this is not an invitation to make changes to Postfix +configuration parameters. Unnecessary changes are likely to impair +the operation of the mail system.

+ +
diff --git a/proto/postconf.man.epilog b/proto/postconf.man.epilog new file mode 100644 index 0000000..1392615 --- /dev/null +++ b/proto/postconf.man.epilog @@ -0,0 +1,23 @@ +.SH SEE ALSO +.na +.nf +postconf(1), Postfix configuration parameter maintenance +master(5), Postfix daemon configuration maintenance +.SH LICENSE +.ad +.fi +The Secure Mailer license must be distributed with this software. +.SH AUTHOR(S) +.na +.nf +Wietse Venema +IBM T.J. Watson Research +P.O. Box 704 +Yorktown Heights, NY 10598, USA +.sp +Wietse Venema +Google, Inc. +111 8th Avenue +New York, NY 10011, USA +.sp +Viktor Dukhovni diff --git a/proto/postconf.man.prolog b/proto/postconf.man.prolog new file mode 100644 index 0000000..64b1e97 --- /dev/null +++ b/proto/postconf.man.prolog @@ -0,0 +1,85 @@ +.TH POSTCONF 5 +.SH NAME +postconf +\- +Postfix configuration parameters +.SH SYNOPSIS +.na +.nf +\fBpostconf\fR \fIparameter\fR ... + +\fBpostconf \-e\fR "\fIparameter=value\fR" ... +.SH DESCRIPTION +.ad +.fi +The Postfix main.cf configuration file specifies parameters that +control the operation of the Postfix mail system. Typically the +file contains only a small subset of all parameters; parameters +not specified are left at their default values. +.PP +The general format of the main.cf file is as follows: +.IP \(bu +Each logical line has the form "parameter = value". +Whitespace around the "=" is ignored, as is whitespace at the +end of a logical line. +.IP \(bu +Empty lines and whitespace-only lines are ignored, as are lines +whose first non-whitespace character is a `#'. +.IP \(bu +A logical line starts with non-whitespace text. A line that starts +with whitespace continues a logical line. +.IP \(bu +A parameter value may refer to other parameters. +.RS +.IP \(bu +The expressions "$name" and "${name}" are recursively replaced with +the value of the named parameter. The parameter name must contain +only characters from the set [a-zA-Z0-9_]. An undefined parameter +value is replaced with the empty value. +.IP \(bu +The expressions "${name?value}" and "${name?{value}}" are replaced +with "value" when "$name" is non-empty. The parameter name must +contain only characters from the set [a-zA-Z0-9_]. These forms are +supported with Postfix versions >= 2.2 and >= 3.0, respectively. +.IP \(bu +The expressions "${name:value}" and "${name:{value}}" are replaced +with "value" when "$name" is empty. The parameter name must contain +only characters from the set [a-zA-Z0-9_]. These forms are supported +with Postfix versions >= 2.2 and >= 3.0, respectively. +.IP \(bu +The expression "${name?{value1}:{value2}}" is replaced with "value1" +when "$name" is non-empty, and with "value2" when "$name" is empty. +The "{}" is required for "value1", optional for "value2". The +parameter name must contain only characters from the set [a-zA-Z0-9_]. +This form is supported with Postfix versions >= 3.0. +.IP \(bu +The first item inside "${...}" may be a relational expression of the +form: "{value3} == {value4}". Besides the "==" (equality) operator +Postfix supports "!=" (inequality), "<", "<=", ">=", and ">". The +comparison is numerical when both operands are all digits, otherwise +the comparison is lexicographical. These forms are supported with +Postfix versions >= 3.0. +.IP \(bu +Each "value" is subject to recursive named parameter and relational +expression evaluation, except where noted. +.IP \(bu +Whitespace before or after each "{value}" is ignored. +.IP \(bu +Specify "$$" to produce a single "$" character. +.IP \(bu +The legacy form "$(...)" is equivalent to the preferred form "${...}". +.RE +.IP \(bu +When the same parameter is defined multiple times, only the last +instance is remembered. +.IP \(bu +Otherwise, the order of main.cf parameter definitions does not matter. +.PP +The remainder of this document is a description of all Postfix +configuration parameters. Default values are shown after the +parameter name in parentheses, and can be looked up with the +"\fBpostconf \-d\fR" command. +.PP +Note: this is not an invitation to make changes to Postfix +configuration parameters. Unnecessary changes can impair the +operation of the mail system. diff --git a/proto/postconf.proto b/proto/postconf.proto new file mode 100644 index 0000000..02bbfcb --- /dev/null +++ b/proto/postconf.proto @@ -0,0 +1,17683 @@ +# This is the input file for automatically generating the postconf(5) +# manual page, the summaries of parameters in on-line manual pages, +# and for the postconf.5.html hyperlinked document. +# +# The following tools operate on information from this file: +# +# xpostconf +# Extracts specific parameter definitions from this file, or +# produces a sorted version of all the information in this +# document. +# +# postconf2html +# Adds parameter name +default headers. The result can be embedded +# into the postconf.5.html hyperlinked document. +# +# postconf2man +# Converts this file into something that can be embedded into +# the postconf(5) UNIX-style manual page. This tool knows only +# a limited subset of HTML as described below. +# +# postconf2src +# Converts this file result into something that can be embedded +# into Postfix source code files. +# +# The subset of HTML that you can use is limited by the postconf2man +# tool: +# +# * Supported HTML elements are: blockquote, ul, li, dl, dt, dd, +# p, pre, b, i, h, and the escapes for < <= >= >. Sorry, no +# tables. +# +# * HTML elements must be specified in lower case. +# +# * Lists cannot be nested. +# +# * The postconf2man tool leaves unrecognized HTML in place as a +# reminder that it is not supported. +# +# * Text between is stripped out. The +# must appear on separate lines. +# +# * Use to request an empty line in the middle +# of a block of text. This is needed with indented lists. +# +# * Blank lines are special for postconf2man: it replaces them by +# a "new paragraph" command. Don't put any blank lines inside +#
text. Instead, put those blank lines between +#
and
. +# +# * Text after a blank line must start with an HTML element. +# +# Also: +# +# * All
and
text must be closed with and
. +# +# * Use 
..
for examples +# between narrative text, instead of indenting examples by hand. +# +# * Use 
..
for the "Examples:" section at the end +# of a parameter description. +# +# The postlink tool automatically inserts hyperlinks for the following, +# so you must not hyperlink that information yourself: +# +# * Postfix manual pages +# * URLs +# * RFCs +# * Postfix configuration parameters +# * Postfix README files +# * Address classes and other terminology. +# +# The xpostconf and postconf2html tools expect the file format described +# in the comments below. The description includes the transformation +# that is done by the postconf2html tool. +# +# * The format of this file is blocks of text separated by one or +# more empty (or all whitespace) lines. +# +# * A text block that begins with %PARAM specifies a parameter name +# and its default value, separated by whitespace. The text in +# the blocks that follow is the parameter description. +# +# * The first line (text up to the first ". ") is used in Postfix +# on-line manual pages, in the one-line configuration parameter +# summaries. +# +# * A text block that begins with the "<" character is treated as +# literal HTML. For example, to specify a "dl" list element one +# would write: +# +# |
name
+# | +# |text that describes "name". +# | +# |
... +# +# As described below, the text that describes "name" will be +# enclosed with

and

. +# +# An "ul" list element would be written like this: +# +# |
  • text for this list element. +# +# * Any text block that does not begin with < is an error. + +%CLASS address-verification Address verification (Postfix 2.1 and later) + +

    +Sender/recipient address verification is implemented by sending +probe email messages that are not actually delivered. This feature +is requested via the reject_unverified_sender and +reject_unverified_recipient access restrictions. The status of +verification probes is maintained by the address verification +service. See the file ADDRESS_VERIFICATION_README for information +about how to configure and operate the Postfix sender/recipient +address verification service. +

    + +%CLASS smtpd-compatibility Compatibility controls + +%CLASS resource-control Resource controls + +%CLASS after-queue-filter After-queue content filter + +

    +As of version 1.0, Postfix can be configured to send new mail to +an external content filter AFTER the mail is queued. This content +filter is expected to inject mail back into a (Postfix or other) +MTA for further delivery. See the FILTER_README document for +details. +

    + +%CLASS before-queue-filter Before-queue content filter + +

    +The Postfix SMTP server can be configured to send incoming mail to +a real-time SMTP-based content filter BEFORE mail is queued. This +content filter is expected to inject mail back into Postfix. See +the SMTPD_PROXY_README document for details on how to configure +and operate this feature. +

    + +%CLASS basic-config Basic configuration parameters + +%CLASS smtpd-access-relay SMTP server access and relay control + +%CLASS smtpd-sasl SMTP server SASL authentication + +%CLASS unknown-recipients Rejecting mail for unknown recipients + +%CLASS smtpd-reply-code SMTP server response codes + +%CLASS other Other configuration parameters + +%PARAM access_map_reject_code 554 + +

    +The numerical Postfix SMTP server response code for +an access(5) map "reject" action. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM access_map_defer_code 450 + +

    +The numerical Postfix SMTP server response code for +an access(5) map "defer" action, including "defer_if_permit" +or "defer_if_reject". Prior to Postfix 2.6, the response +is hard-coded as "450". +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +

    +This feature is available in Postfix 2.6 and later. +

    + +%PARAM address_verify_default_transport $default_transport + +

    +Overrides the default_transport parameter setting for address +verification probes. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_local_transport $local_transport + +

    +Overrides the local_transport parameter setting for address +verification probes. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_map see "postconf -d" output + +

    +Lookup table for persistent address verification status +storage. The table is maintained by the verify(8) service, and +is opened before the process releases privileges. +

    + +

    +The lookup table is persistent by default (Postfix 2.7 and later). +Specify an empty table name to keep the information in volatile +memory which is lost after "postfix reload" or "postfix +stop". This is the default with Postfix version 2.6 and earlier. +

    + +

    +Specify a location in a file system that will not fill up. If the +database becomes corrupted, the world comes to an end. To recover +delete (NOT: truncate) the file and do "postfix reload". +

    + +

    Postfix daemon processes do not use root privileges when opening +this file (Postfix 2.5 and later). The file must therefore be +stored under a Postfix-owned directory such as the data_directory. +As a migration aid, an attempt to open the file under a non-Postfix +directory is redirected to the Postfix-owned data_directory, and a +warning is logged.

    + +

    +Examples: +

    + +
    +address_verify_map = hash:/var/lib/postfix/verify
+address_verify_map = btree:/var/lib/postfix/verify
+
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_negative_cache yes + +

    +Enable caching of failed address verification probe results. When +this feature is enabled, the cache may pollute quickly with garbage. +When this feature is disabled, Postfix will generate an address +probe for every lookup. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_negative_expire_time 3d + +

    +The time after which a failed probe expires from the address +verification cache. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_negative_refresh_time 3h + +

    +The time after which a failed address verification probe needs to +be refreshed. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_cache_cleanup_interval 12h + +

    The amount of time between verify(8) address verification +database cleanup runs. This feature requires that the database +supports the "delete" and "sequence" operators. Specify a zero +interval to disable database cleanup.

    + +

    After each database cleanup run, the verify(8) daemon logs the +number of entries that were retained and dropped. A cleanup run is +logged as "partial" when the daemon terminates early after "postfix +reload", "postfix stop", or no requests for $max_idle +seconds.

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks).

    + +

    This feature is available in Postfix 2.7.

    + +%PARAM address_verify_poll_count normal: 3, overload: 1 + +

    +How many times to query the verify(8) service for the completion +of an address verification request in progress. +

    + +

    By default, the Postfix SMTP server polls the verify(8) service +up to three times under non-overload conditions, and only once when +under overload. With Postfix version 2.5 and earlier, the SMTP +server always polls the verify(8) service up to three times by +default.

    + +

    +Specify 1 to implement a crude form of greylisting, that is, always +defer the first delivery request for a new address. +

    + +

    +Examples: +

    + +
    +# Postfix ≤ 2.6 default
+address_verify_poll_count = 3
+# Poor man's greylisting
+address_verify_poll_count = 1
+
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_poll_delay 3s + +

    +The delay between queries for the completion of an address +verification request in progress. +

    + +

    +The default polling delay is 3 seconds. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_positive_expire_time 31d + +

    +The time after which a successful probe expires from the address +verification cache. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_positive_refresh_time 7d + +

    +The time after which a successful address verification probe needs +to be refreshed. The address verification status is not updated +when the probe fails (optimistic caching). +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_relay_transport $relay_transport + +

    +Overrides the relay_transport parameter setting for address +verification probes. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_relayhost $relayhost + +

    +Overrides the relayhost parameter setting for address verification +probes. This information can be overruled with the transport(5) table. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_sender $double_bounce_sender + +

    The sender address to use in address verification probes; prior +to Postfix 2.5 the default was "postmaster". To +avoid problems with address probes that are sent in response to +address probes, the Postfix SMTP server excludes the probe sender +address from all SMTPD access blocks.

    + +

    +Specify an empty value (address_verify_sender =) or <> if you want +to use the null sender address. Beware, some sites reject mail from +<>, even though RFCs require that such addresses be accepted. +

    + +

    +Examples: +

    + +
    +address_verify_sender = <>
+address_verify_sender = postmaster@my.domain
+
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_transport_maps $transport_maps + +

    +Overrides the transport_maps parameter setting for address verification +probes. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM address_verify_virtual_transport $virtual_transport + +

    +Overrides the virtual_transport parameter setting for address +verification probes. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM alias_database see "postconf -d" output + +

    +The alias databases for local(8) delivery that are updated with +"newaliases" or with "sendmail -bi". +

    + +

    +This is a separate configuration parameter because not all the +tables specified with $alias_maps have to be local files. +

    + +

    +Examples: +

    + +
    +alias_database = hash:/etc/aliases
+alias_database = hash:/etc/mail/aliases
+
    + +%PARAM alias_maps see "postconf -d" output + +

    +The alias databases that are used for local(8) delivery. See +aliases(5) for syntax details. +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +Note: these lookups are recursive. +

    + +

    +The default list is system dependent. On systems with NIS, the +default is to search the local alias database, then the NIS alias +database. +

    + +

    +If you change the alias database, run "postalias /etc/aliases" +(or wherever your system stores the mail alias file), or simply +run "newaliases" to build the necessary DBM or DB file. +

    + +

    +The local(8) delivery agent disallows regular expression substitution +of $1 etc. in alias_maps, because that would open a security hole. +

    + +

    +The local(8) delivery agent will silently ignore requests to use +the proxymap(8) server within alias_maps. Instead it will open the +table directly. Before Postfix version 2.2, the local(8) delivery +agent will terminate with a fatal error. +

    + +

    +Examples: +

    + +
    +alias_maps = hash:/etc/aliases, nis:mail.aliases
+alias_maps = hash:/etc/aliases
+
    + +%PARAM allow_mail_to_commands alias, forward + +

    +Restrict local(8) mail delivery to external commands. The default +is to disallow delivery to "|command" in :include: files (see +aliases(5) for the text that defines this terminology). +

    + +

    +Specify zero or more of: alias, forward or include, +in order to allow commands in aliases(5), .forward files or in +:include: files, respectively. +

    + +

    +Example: +

    + +
    +allow_mail_to_commands = alias,forward,include
+
    + +%PARAM allow_mail_to_files alias, forward + +

    +Restrict local(8) mail delivery to external files. The default is +to disallow "/file/name" destinations in :include: files (see +aliases(5) for the text that defines this terminology). +

    + +

    +Specify zero or more of: alias, forward or include, +in order to allow "/file/name" destinations in aliases(5), .forward +files and in :include: files, respectively. +

    + +

    +Example: +

    + +
    +allow_mail_to_files = alias,forward,include
+
    + +%PARAM allow_min_user no + +

    +Allow a sender or recipient address to have `-' as the first +character. By +default, this is not allowed, to avoid accidents with software that +passes email addresses via the command line. Such software +would not be able to distinguish a malicious address from a +bona fide command-line option. Although this can be prevented by +inserting a "--" option terminator into the command line, this is +difficult to enforce consistently and globally.

    + +

    As of Postfix version 2.5, this feature is implemented by +trivial-rewrite(8). With earlier versions this feature was implemented +by qmgr(8) and was limited to recipient addresses only.

    + +%PARAM allow_percent_hack yes + +

    +Enable the rewriting of the form "user%domain" to "user@domain". +This is enabled by default. +

    + +

    Note: as of Postfix version 2.2, message header address rewriting +happens only when one of the following conditions is true:

    + +
      + +
    • The message is received with the Postfix sendmail(1) command, + +
    • The message is received from a network client that matches +$local_header_rewrite_clients, + +
    • The message is received from the network, and the +remote_header_rewrite_domain parameter specifies a non-empty value. + +
    + +

    To get the behavior before Postfix version 2.2, specify +"local_header_rewrite_clients = static:all".

    + +

    +Example: +

    + +
    +allow_percent_hack = no
+
    + +%PARAM allow_untrusted_routing no + +

    +Forward mail with sender-specified routing (user[@%!]remote[@%!]site) +from untrusted clients to destinations matching $relay_domains. +

    + +

    +By default, this feature is turned off. This closes a nasty open +relay loophole where a backup MX host can be tricked into forwarding +junk mail to a primary MX host which then spams it out to the world. +

    + +

    +This parameter also controls if non-local addresses with sender-specified +routing can match Postfix access tables. By default, such addresses +cannot match Postfix access tables, because the address is ambiguous. +

    + +%PARAM always_bcc + +

    +Optional address that receives a "blind carbon copy" of each message +that is received by the Postfix mail system. +

    + +

    +Note: with Postfix 2.3 and later the BCC address is added as if it +was specified with NOTIFY=NONE. The sender will not be notified +when the BCC address is undeliverable, as long as all down-stream +software implements RFC 3461. +

    + +

    +Note: with Postfix 2.2 and earlier the sender will be notified +when the BCC address is undeliverable. +

    + +

    Note: automatic BCC recipients are produced only for new mail. +To avoid mailer loops, automatic BCC recipients are not generated +after Postfix forwards mail internally, or after Postfix generates +mail itself.

    + +%PARAM berkeley_db_create_buffer_size 16777216 + +

    +The per-table I/O buffer size for programs that create Berkeley DB +hash or btree tables. Specify a byte count. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM berkeley_db_read_buffer_size 131072 + +

    +The per-table I/O buffer size for programs that read Berkeley DB +hash or btree tables. Specify a byte count. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM best_mx_transport + +

    +Where the Postfix SMTP client should deliver mail when it detects +a "mail loops back to myself" error condition. This happens when +the local MTA is the best SMTP mail exchanger for a destination +not listed in $mydestination, $inet_interfaces, $proxy_interfaces, +$virtual_alias_domains, or $virtual_mailbox_domains. By default, +the Postfix SMTP client returns such mail as undeliverable. +

    + +

    +Specify, for example, "best_mx_transport = local" to pass the mail +from the Postfix SMTP client to the local(8) delivery agent. You +can specify +any message delivery "transport" or "transport:nexthop" that is +defined in the master.cf file. See the transport(5) manual page +for the syntax and meaning of "transport" or "transport:nexthop". +

    + +

    +However, this feature is expensive because it ties up a Postfix +SMTP client process while the local(8) delivery agent is doing its +work. It is more efficient (for Postfix) to list all hosted domains +in a table or database. +

    + +%PARAM biff yes + +

    +Whether or not to use the local biff service. This service sends +"new mail" notifications to users who have requested new mail +notification with the UNIX command "biff y". +

    + +

    +For compatibility reasons this feature is on by default. On systems +with lots of interactive users, the biff service can be a performance +drain. Specify "biff = no" in main.cf to disable. +

    + +%PARAM body_checks + +

    Optional lookup tables for content inspection as specified in +the body_checks(5) manual page.

    + +

    Note: with Postfix versions before 2.0, these rules inspect +all content after the primary message headers.

    + +%PARAM body_checks_size_limit 51200 + +

    +How much text in a message body segment (or attachment, if you +prefer to use that term) is subjected to body_checks inspection. +The amount of text is limited to avoid scanning huge attachments. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM bounce_queue_lifetime 5d + +

    +Consider a bounce message as undeliverable, when delivery fails +with a temporary error, and the time in the queue has reached the +bounce_queue_lifetime limit. By default, this limit is the same +as for regular mail. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is d (days). +

    + +

    +Specify 0 when mail delivery should be tried only once. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM bounce_size_limit 50000 + +

    The maximal amount of original message text that is sent in a +non-delivery notification. Specify a byte count. A message is +returned as either message/rfc822 (the complete original) or as +text/rfc822-headers (the headers only). With Postfix version 2.4 +and earlier, a message is always returned as message/rfc822 and is +truncated when it exceeds the size limit. +

    + +

    Notes:

    + +
      + +

    • If you increase this limit, then you should increase the +mime_nesting_limit value proportionally.

      + +

    • Be careful when making changes. Excessively large values +will result in the loss of non-delivery notifications, when a bounce +message size exceeds a local or remote MTA's message size limit. +

      + +
    + +%PARAM canonical_maps + +

    +Optional address mapping lookup tables for message headers and +envelopes. The mapping is applied to both sender and recipient +addresses, in both envelopes and in headers, as controlled +with the canonical_classes parameter. This is typically used +to clean up dirty addresses from legacy mail systems, or to replace +login names by Firstname.Lastname. The table format and lookups +are documented in canonical(5). For an overview of Postfix address +manipulations see the ADDRESS_REWRITING_README document. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +Note: these lookups are recursive. +

    + +

    +If you use this feature, run "postmap /etc/postfix/canonical" to +build the necessary DBM or DB file after every change. The changes +will become visible after a minute or so. Use "postfix reload" +to eliminate the delay. +

    + +

    Note: with Postfix version 2.2, message header address mapping +happens only when message header address rewriting is enabled:

    + +
      + +
    • The message is received with the Postfix sendmail(1) command, + +
    • The message is received from a network client that matches +$local_header_rewrite_clients, + +
    • The message is received from the network, and the +remote_header_rewrite_domain parameter specifies a non-empty value. + +
    + +

    To get the behavior before Postfix version 2.2, specify +"local_header_rewrite_clients = static:all".

    + +

    +Examples: +

    + +
    +canonical_maps = dbm:/etc/postfix/canonical
+canonical_maps = hash:/etc/postfix/canonical
+
    + +%PARAM canonical_classes envelope_sender, envelope_recipient, header_sender, header_recipient + +

    What addresses are subject to canonical_maps address mapping. +By default, canonical_maps address mapping is applied to envelope +sender and recipient addresses, and to header sender and header +recipient addresses.

    + +

    Specify one or more of: envelope_sender, envelope_recipient, +header_sender, header_recipient

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM sender_canonical_classes envelope_sender, header_sender + +

    What addresses are subject to sender_canonical_maps address +mapping. By default, sender_canonical_maps address mapping is +applied to envelope sender addresses, and to header sender addresses. +

    + +

    Specify one or more of: envelope_sender, header_sender

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM recipient_canonical_classes envelope_recipient, header_recipient + +

    What addresses are subject to recipient_canonical_maps address +mapping. By default, recipient_canonical_maps address mapping is +applied to envelope recipient addresses, and to header recipient +addresses.

    + +

    Specify one or more of: envelope_recipient, header_recipient +

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM command_directory see "postconf -d" output + +

    +The location of all postfix administrative commands. +

    + +%PARAM command_time_limit 1000s + +

    +Time limit for delivery to external commands. This limit is used +by the local(8) delivery agent, and is the default time limit for +delivery by the pipe(8) delivery agent. +

    + +

    +Note: if you set this time limit to a large value you must update the +global ipc_timeout parameter as well. +

    + +%PARAM daemon_directory see "postconf -d" output + +

    +The directory with Postfix support programs and daemon programs. +These should not be invoked directly by humans. The directory must +be owned by root. +

    + +%PARAM daemon_timeout 18000s + +

    How much time a Postfix daemon process may take to handle a +request before it is terminated by a built-in watchdog timer.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM debug_peer_level 2 + +

    The increment in verbose logging level when a remote client or +server matches a pattern in the debug_peer_list parameter.

    + +%PARAM debug_peer_list + +

    Optional list of remote client or server hostname or network +address patterns that cause the verbose logging level to increase +by the amount specified in $debug_peer_level.

    + +

    Specify domain names, network/netmask patterns, "/file/name" +patterns or "type:table" lookup tables. The right-hand side result +from "type:table" lookups is ignored.

    + +

    Pattern matching of domain names is controlled by the presence +or absence of "debug_peer_list" in the parent_domain_matches_subdomains +parameter value.

    + +

    +Examples: +

    + +
    +debug_peer_list = 127.0.0.1
+debug_peer_list = example.com
+
    + +%PARAM default_database_type see "postconf -d" output + +

    +The default database type for use in newaliases(1), postalias(1) +and postmap(1) commands. On many UNIX systems the default type is +either dbm or hash. The default setting is frozen +when the Postfix system is built. +

    + +

    +Examples: +

    + +
    +default_database_type = hash
+default_database_type = dbm
+
    + +%PARAM default_delivery_slot_cost 5 + +

    +How often the Postfix queue manager's scheduler is allowed to +preempt delivery of one message with another. +

    + +

    +Each transport maintains a so-called "available delivery slot counter" +for each message. One message can be preempted by another one when +the other message can be delivered using no more delivery slots +(i.e., invocations of delivery agents) than the current message +counter has accumulated (or will eventually accumulate - see about +slot loans below). This parameter controls how often is the counter +incremented - it happens after each default_delivery_slot_cost +recipients have been delivered. +

    + +

    +The cost of 0 is used to disable the preempting scheduling completely. +The minimum value the scheduling algorithm can use is 2 - use it +if you want to maximize the message throughput rate. Although there +is no maximum, it doesn't make much sense to use values above say +50. +

    + +

    +The only reason why the value of 2 is not the default is the way +this parameter affects the delivery of mailing-list mail. In the +worst case, delivery can take somewhere between (cost+1/cost) +and (cost/cost-1) times more than if the preemptive scheduler was +disabled. The default value of 5 turns out to provide reasonable +message response times while making sure the mailing-list deliveries +are not extended by more than 20-25 percent even in the worst case. +

    + +

    Use transport_delivery_slot_cost to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +

    +Examples: +

    + +
    +default_delivery_slot_cost = 0
+default_delivery_slot_cost = 2
+
    + +%PARAM default_destination_concurrency_limit 20 + +

    +The default maximal number of parallel deliveries to the same +destination. This is the default limit for delivery via the lmtp(8), +pipe(8), smtp(8) and virtual(8) delivery agents. +With per-destination recipient limit > 1, a destination is a domain, +otherwise it is a recipient. +

    + +

    Use transport_destination_concurrency_limit to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +%PARAM default_destination_recipient_limit 50 + +

    +The default maximal number of recipients per message delivery. +This is the default limit for delivery via the lmtp(8), pipe(8), +smtp(8) and virtual(8) delivery agents. +

    + +

    Setting this parameter to a value of 1 affects email deliveries +as follows:

    + +
      + +

    • It changes the meaning of the corresponding per-destination +concurrency limit, from concurrency of deliveries to the same +domain into concurrency of deliveries to the same recipient. +Different recipients are delivered in parallel, subject to the +process limits specified in master.cf.

      + +

    • It changes the meaning of the corresponding per-destination +rate delay, from the delay between deliveries to the same +domain into the delay between deliveries to the same +recipient. Again, different recipients are delivered in parallel, +subject to the process limits specified in master.cf.

      + +

    • It changes the meaning of other corresponding per-destination +settings in a similar manner, from settings for delivery to the +same domain into settings for delivery to the same +recipient. + +

    + +

    Use transport_destination_recipient_limit to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +%PARAM default_extra_recipient_limit 1000 + +

    +The default value for the extra per-transport limit imposed on the +number of in-memory recipients. This extra recipient space is +reserved for the cases when the Postfix queue manager's scheduler +preempts one message with another and suddenly needs some extra +recipients slots for the chosen message in order to avoid performance +degradation. +

    + +

    Use transport_extra_recipient_limit to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +%PARAM default_minimum_delivery_slots 3 + +

    +How many recipients a message must have in order to invoke the +Postfix queue manager's scheduling algorithm at all. Messages +which would never accumulate at least this many delivery slots +(subject to slot cost parameter as well) are never preempted. +

    + +

    Use transport_minimum_delivery_slots to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +%PARAM default_privs nobody + +

    +The default rights used by the local(8) delivery agent for delivery +to external file or command. These rights are used when delivery +is requested from an aliases(5) file that is owned by root, or +when delivery is done on behalf of root. DO NOT SPECIFY A +PRIVILEGED USER OR THE POSTFIX OWNER. +

    + +%PARAM default_process_limit 100 + +

    +The default maximal number of Postfix child processes that provide +a given service. This limit can be overruled for specific services +in the master.cf file. +

    + +%PARAM default_rbl_reply see "postconf -d" output + +

    +The default Postfix SMTP server response template for a request that is +rejected by an RBL-based restriction. This template can be overruled +by specific entries in the optional rbl_reply_maps lookup table. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +

    +The template does not support Postfix configuration parameter $name +substitution. Instead, it supports exactly one level of $name +substitution for the following attributes: +

    + +
    + +
    $client
    + +
    The client hostname and IP address, formatted as name[address].
    + +
    $client_address
    + +
    The client IP address.
    + +
    $client_name
    + +
    The client hostname or "unknown". See reject_unknown_client_hostname +for more details.
    + +
    $reverse_client_name
    + +
    The client hostname from address->name lookup, or "unknown". +See reject_unknown_reverse_client_hostname for more details.
    + +#
    $forward_client_name
    +# +#
    The client hostname from address->name lookup followed by +#name->address lookup, or "unknown". See +#reject_unknown_forward_client_hostname for more details.
    + +
    $helo_name
    + +
    The hostname given in HELO or EHLO command or empty string.
    + +
    $rbl_class
    + +
    The blacklisted entity type: Client host, Helo command, Sender +address, or Recipient address.
    + +
    $rbl_code
    + +
    The numerical SMTP response code, as specified with the +maps_rbl_reject_code configuration parameter. Note: The numerical +SMTP response code is required, and must appear at the start of the +reply. With Postfix version 2.3 and later this information may be followed +by an RFC 3463 enhanced status code.
    + +
    $rbl_domain
    + +
    The RBL domain where $rbl_what is blacklisted.
    + +
    $rbl_reason
    + +
    The reason why $rbl_what is blacklisted, or an empty string.
    + +
    $rbl_what
    + +
    The entity that is blacklisted (an IP address, a hostname, a domain +name, or an email address whose domain was blacklisted).
    + +
    $recipient
    + +
    The recipient address or <> in case of the null address.
    + +
    $recipient_domain
    + +
    The recipient domain or empty string.
    + +
    $recipient_name
    + +
    The recipient address localpart or <> in case of null address.
    + +
    $sender
    + +
    The sender address or <> in case of the null address.
    + +
    $sender_domain
    + +
    The sender domain or empty string.
    + +
    $sender_name
    + +
    The sender address localpart or <> in case of the null address.
    + +
    ${name?text}
    + +
    Expands to `text' if $name is not empty.
    + +
    ${name:text}
    + +
    Expands to `text' if $name is empty.
    + +
    + +

    +Instead of $name you can also specify ${name} or $(name). +

    + +

    Note: when an enhanced status code is specified in an RBL reply +template, it is subject to modification. The following transformations +are needed when the same RBL reply template is used for client, +helo, sender, or recipient access restrictions.

    + +
      + +

    • When rejecting a sender address, the Postfix SMTP server +will transform a recipient DSN status (e.g., 4.1.1-4.1.6) into the +corresponding sender DSN status, and vice versa.

      + +

    • When rejecting non-address information (such as the HELO +command argument or the client hostname/address), the Postfix SMTP +server will transform a sender or recipient DSN status into a generic +non-address DSN status (e.g., 4.0.0).

      + +
    + +%PARAM default_recipient_limit 20000 + +

    +The default per-transport upper limit on the number of in-memory +recipients. These limits take priority over the global +qmgr_message_recipient_limit after the message has been assigned +to the respective transports. See also default_extra_recipient_limit +and qmgr_message_recipient_minimum. +

    + +

    Use transport_recipient_limit to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +%PARAM default_recipient_refill_limit 100 + +

    +The default per-transport limit on the number of recipients refilled at +once. When not all message recipients fit into the memory at once, keep +loading more of them in batches of at least this many at a time. See also +$default_recipient_refill_delay, which may result in recipient batches +lower than this when this limit is too high for too slow deliveries. +

    + +

    Use transport_recipient_refill_limit to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +

    This feature is available in Postfix 2.4 and later.

    + +%PARAM default_recipient_refill_delay 5s + +

    +The default per-transport maximum delay between recipients refills. +When not all message recipients fit into the memory at once, keep loading +more of them at least once every this many seconds. This is used to +make sure the recipients are refilled in timely manner even when +$default_recipient_refill_limit is too high for too slow deliveries. +

    + +

    Use transport_recipient_refill_delay to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +

    This feature is available in Postfix 2.4 and later.

    + +%PARAM default_transport smtp + +

    +The default mail delivery transport and next-hop destination for +destinations that do not match $mydestination, $inet_interfaces, +$proxy_interfaces, $virtual_alias_domains, $virtual_mailbox_domains, +or $relay_domains. This information can be overruled with the +sender_dependent_default_transport_maps parameter and with the +transport(5) table.

    + +

    +In order of decreasing precedence, the nexthop destination is taken +from $sender_dependent_default_transport_maps, $default_transport, +$sender_dependent_relayhost_maps, $relayhost, or from the recipient +domain. +

    + +

    +Specify a string of the form transport:nexthop, where transport +is the name of a mail delivery transport defined in master.cf. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. +

    + +

    +Example: +

    + +
    +default_transport = uucp:relayhostname
+
    + +%PARAM defer_code 450 + +

    +The numerical Postfix SMTP server response code when a remote SMTP +client request is rejected by the "defer" restriction. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM defer_transports + +

    +The names of message delivery transports that should not deliver mail +unless someone issues "sendmail -q" or equivalent. Specify zero +or more names of mail delivery transports names that appear in the +first field of master.cf. +

    + +

    +Example: +

    + +
    +defer_transports = smtp
+
    + +%PARAM deliver_lock_attempts 20 + +

    +The maximal number of attempts to acquire an exclusive lock on a +mailbox file or bounce(8) logfile. +

    + +%PARAM deliver_lock_delay 1s + +

    +The time between attempts to acquire an exclusive lock on a mailbox +file or bounce(8) logfile. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM disable_vrfy_command no + +

    +Disable the SMTP VRFY command. This stops some techniques used to +harvest email addresses. +

    + +

    +Example: +

    + +
    +disable_vrfy_command = no
+
    + +%PARAM double_bounce_sender double-bounce + +

    The sender address of postmaster notifications that are generated +by the mail system. All mail to this address is silently discarded, +in order to terminate mail bounce loops.

    + +%PARAM duplicate_filter_limit 1000 + +

    The maximal number of addresses remembered by the address +duplicate filter for aliases(5) or virtual(5) alias expansion, or +for showq(8) queue displays.

    + +%PARAM enable_original_recipient yes + +

    Enable support for the original recipient address after an +address is rewritten to a different address (for example with +aliasing or with canonical mapping).

    + +

    The original recipient address is used as follows:

    + +
    + +
    Final delivery
    With "enable_original_recipient = +yes", the original recipient address is stored in the X-Original-To +message header. This header may be used to distinguish between +different recipients that share the same mailbox.
    + +
    Recipient deduplication
    With "enable_original_recipient += yes", the cleanup(8) daemon performs duplicate recipient elimination +based on the content of (original recipient, maybe-rewritten +recipient) pairs. Otherwise, the cleanup(8) daemon performs duplicate +recipient elimination based only on the maybe-rewritten recipient +address.
    + +
    + +

    Note: with Postfix ≤ 3.2 the "setting enable_original_recipient += no" breaks address verification for addresses that are +aliased or otherwise rewritten (Postfix is unable to store the +address verification result under the original probe destination +address; instead, it can store the result only under the rewritten +address).

    + +

    This feature is available in Postfix 2.1 and later. Postfix +version 2.0 behaves as if this parameter is always set to yes. +Postfix versions before 2.0 have no support for the original recipient +address.

    + +%PARAM export_environment see "postconf -d" output + +

    +The list of environment variables that a Postfix process will export +to non-Postfix processes. The TZ variable is needed for sane +time keeping on System-V-ish systems. +

    + +

    +Specify a list of names and/or name=value pairs, separated by +whitespace or comma. Specify "{ name=value }" to protect whitespace +or comma in parameter values (whitespace after the opening "{" and +before the closing "}" +is ignored). The form name=value is supported with Postfix version +2.1 and later; the use of {} is supported with Postfix 3.0 and +later.

    + +

    +Example: +

    + +
    +export_environment = TZ PATH=/bin:/usr/bin
+
    + +%PARAM smtp_fallback_relay $fallback_relay + +

    +Optional list of relay hosts for SMTP destinations that can't be +found or that are unreachable. With Postfix 2.2 and earlier this +parameter is called fallback_relay.

    + +

    +By default, mail is returned to the sender when a destination is +not found, and delivery is deferred when a destination is unreachable. +

    + +

    With bulk email deliveries, it can be beneficial to run the +fallback relay MTA on the same host, so that it can reuse the sender +IP address. This speeds up deliveries that are delayed by IP-based +reputation systems (greylist, etc.).

    + +

    The fallback relays must be SMTP destinations. Specify a domain, +host, host:port, [host]:port, [address] or [address]:port; the form +[host] turns off MX lookups. If you specify multiple SMTP +destinations, Postfix will try them in the specified order.

    + +

    To prevent mailer loops between MX hosts and fall-back hosts, +Postfix version 2.2 and later will not use the fallback relays for +destinations that it is MX host for (assuming DNS lookup is turned on). +

    + +%PARAM fallback_relay + +

    +Optional list of relay hosts for SMTP destinations that can't be +found or that are unreachable. With Postfix 2.3 this parameter +is renamed to smtp_fallback_relay.

    + +

    +By default, mail is returned to the sender when a destination is +not found, and delivery is deferred when a destination is unreachable. +

    + +

    The fallback relays must be SMTP destinations. Specify a domain, +host, host:port, [host]:port, [address] or [address]:port; the form +[host] turns off MX lookups. If you specify multiple SMTP +destinations, Postfix will try them in the specified order.

    + +

    Note: before Postfix 2.2, do not use the fallback_relay feature +when relaying mail +for a backup or primary MX domain. Mail would loop between the +Postfix MX host and the fallback_relay host when the final destination +is unavailable.

    + +
      + +
    • In main.cf specify "relay_transport = relay", + +
    • In master.cf specify "-o fallback_relay =" (i.e., empty) at +the end of the relay entry. + +
    • In transport maps, specify "relay:nexthop..." +as the right-hand side for backup or primary MX domain entries. + +
    + +

    Postfix version 2.2 and later will not use the fallback_relay feature +for destinations that it is MX host for. +

    + +%PARAM lmtp_fallback_relay + +

    Optional list of relay hosts for LMTP destinations that can't be +found or that are unreachable. In main.cf elements are separated by +whitespace or commas.

    + +

    By default, mail is returned to the sender when a destination is not +found, and delivery is deferred when a destination is unreachable.

    + +

    The fallback relays must be TCP destinations, specified without +a leading "inet:" prefix. Specify a host or host:port. Since MX +lookups do not apply with LMTP, there is no need to use the "[host]" or +"[host]:port" forms. If you specify multiple LMTP destinations, Postfix +will try them in the specified order.

    + +

    +This feature is available in Postfix 3.1 and later. +

    + +%PARAM fast_flush_domains $relay_domains + +

    +Optional list of destinations that are eligible for per-destination +logfiles with mail that is queued to those destinations. +

    + +

    +By default, Postfix maintains "fast flush" logfiles only for +destinations that the Postfix SMTP server is willing to relay to +(i.e. the default is: "fast_flush_domains = $relay_domains"; see +the relay_domains parameter in the postconf(5) manual). +

    + +

    Specify a list of hosts or domains, "/file/name" patterns or +"type:table" lookup tables, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. A +"/file/name" pattern is replaced by its contents; a "type:table" +lookup table is matched when the domain or its parent domain appears +as lookup key.

    + +

    Pattern matching of domain names is controlled by the presence +or absence of "fast_flush_domains" in the parent_domain_matches_subdomains +parameter value.

    + +

    +Specify "fast_flush_domains =" (i.e., empty) to disable the feature +altogether. +

    + +%PARAM fast_flush_purge_time 7d + +

    +The time after which an empty per-destination "fast flush" logfile +is deleted. +

    + +

    +You can specify the time as a number, or as a number followed by +a letter that indicates the time unit: s=seconds, m=minutes, h=hours, +d=days, w=weeks. The default time unit is days. +

    + +%PARAM fast_flush_refresh_time 12h + +

    +The time after which a non-empty but unread per-destination "fast +flush" logfile needs to be refreshed. The contents of a logfile +are refreshed by requesting delivery of all messages listed in the +logfile. +

    + +

    +You can specify the time as a number, or as a number followed by +a letter that indicates the time unit: s=seconds, m=minutes, h=hours, +d=days, w=weeks. The default time unit is hours. +

    + +%PARAM fork_attempts 5 + +

    The maximal number of attempts to fork() a child process.

    + +%PARAM fork_delay 1s + +

    The delay between attempts to fork() a child process.

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks). The default time unit is s (seconds).

    + +%PARAM execution_directory_expansion_filter see "postconf -d" output + +

    Restrict the characters that the local(8) delivery agent allows +in $name expansions of $command_execution_directory. Characters +outside the allowed set are replaced by underscores.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM command_execution_directory + +

    The local(8) delivery agent working directory for delivery to +external command. Failure to change directory causes the delivery +to be deferred.

    + +

    The command_execution_directory value is not subject to Postfix +configuration parameter $name expansion. Instead, the following +$name expansions are done on command_execution_directory before the +directory is used. Expansion happens in the context +of the delivery request. The result of $name expansion is filtered +with the character set that is specified with the +execution_directory_expansion_filter parameter.

    + +
    + +
    $user
    + +
    The recipient's username.
    + +
    $shell
    + +
    The recipient's login shell pathname.
    + +
    $home
    + +
    The recipient's home directory.
    + +
    $recipient
    + +
    The full recipient address.
    + +
    $extension
    + +
    The optional recipient address extension.
    + +
    $domain
    + +
    The recipient domain.
    + +
    $local
    + +
    The entire recipient localpart.
    + +
    $recipient_delimiter
    + +
    The address extension delimiter that was found in the recipient +address (Postfix 2.11 and later), or the system-wide recipient +address extension delimiter (Postfix 2.10 and earlier).
    + +
    ${name?value}
    + +
    Expands to value when $name is non-empty.
    + +
    ${name:value}
    + +
    Expands to value when $name is empty.
    + +
    + +

    +Instead of $name you can also specify ${name} or $(name). +

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM forward_path see "postconf -d" output + +

    The local(8) delivery agent search list for finding a .forward +file with user-specified delivery methods. The first file that is +found is used.

    + +

    The forward_path value is not subject to Postfix configuration +parameter $name expansion. Instead, the following $name expansions +are done on forward_path before the search actually happens. +The result of $name expansion is +filtered with the character set that is specified with the +forward_expansion_filter parameter.

    + +
    + +
    $user
    + +
    The recipient's username.
    + +
    $shell
    + +
    The recipient's login shell pathname.
    + +
    $home
    + +
    The recipient's home directory.
    + +
    $recipient
    + +
    The full recipient address.
    + +
    $extension
    + +
    The optional recipient address extension.
    + +
    $domain
    + +
    The recipient domain.
    + +
    $local
    + +
    The entire recipient localpart.
    + +
    $recipient_delimiter
    + +
    The address extension delimiter that was found in the recipient +address (Postfix 2.11 and later), or the system-wide recipient +address extension delimiter (Postfix 2.10 and earlier).
    + +
    ${name?value}
    + +
    Expands to value when $name is non-empty.
    + +
    ${name:value}
    + +
    Expands to value when $name is empty.
    + +
    + +

    +Instead of $name you can also specify ${name} or $(name). +

    + +

    +Examples: +

    + +
    +forward_path = /var/forward/$user
+forward_path =
+    /var/forward/$user/.forward$recipient_delimiter$extension,
+    /var/forward/$user/.forward
+
    + +%CLASS queue-hashing Queue directory hashing + +

    +Queue directory hashing is a performance feature. Splitting one +queue directory across multiple subdirectory levels can speed up +file access by reducing the number of files per directory. +

    + +

    +Unfortunately, deeply hashing the incoming or deferred queue can +actually slow down the mail system (with a depth of 2, mailq with +an empty queue can take several seconds). +

    + +

    +Hashing must NOT be used with a world-writable maildrop directory. +Hashing MUST be used for the defer logfile directory, to avoid poor +performance when handling lots of deferred mail. +

    + +%PARAM hash_queue_depth 1 + +

    +The number of subdirectory levels for queue directories listed with +the hash_queue_names parameter. Queue hashing is implemented by +creating one or more levels of directories with one-character names. +Originally, these directory names were equal to the first characters +of the queue file name, with the hexadecimal representation of the +file creation time in microseconds.

    + +

    With long queue file names, queue hashing produces the same +results as with short names. The file creation time in microseconds +is converted into hexadecimal form before the result is used for +queue hashing. The base 16 encoding gives finer control over the +number of subdirectories than is possible with the base 52 encoding +of long queue file names.

    + +

    +After changing the hash_queue_names or hash_queue_depth parameter, +execute the command "postfix reload". +

    + +%PARAM hash_queue_names deferred, defer + +

    +The names of queue directories that are split across multiple +subdirectory levels. +

    + +

    Before Postfix version 2.2, the default list of hashed queues +was significantly larger. Claims about improvements in file system +technology suggest that hashing of the incoming and active queues +is no longer needed. Fewer hashed directories speed up the time +needed to restart Postfix.

    + +

    +After changing the hash_queue_names or hash_queue_depth parameter, +execute the command "postfix reload". +

    + +%CLASS headerbody-checks Content inspection built-in features + +

    +The Postfix cleanup(8) server has a limited ability to inspect +message headers and body content for signs of trouble. This is not +meant to be a substitute for content filters that do complex +processing such attachment decoding and unzipping. +

    + +%PARAM header_checks + +

    +Optional lookup tables for content inspection of primary non-MIME +message headers, as specified in the header_checks(5) manual page. +

    + +%PARAM header_size_limit 102400 + +

    +The maximal amount of memory in bytes for storing a message header. +If a header is larger, the excess is discarded. The limit is +enforced by the cleanup(8) server. +

    + +%PARAM home_mailbox + +

    +Optional pathname of a mailbox file relative to a local(8) user's +home directory. +

    + +

    +Specify a pathname ending in "/" for qmail-style delivery. +

    + +

    The precedence of local(8) delivery features from high to low +is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, +mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, +fallback_transport_maps, fallback_transport and luser_relay.

    + +

    +Examples: +

    + +
    +home_mailbox = Mailbox
+home_mailbox = Maildir/
+
    + +%PARAM hopcount_limit 50 + +

    +The maximal number of Received: message headers that is allowed +in the primary message headers. A message that exceeds the limit +is bounced, in order to stop a mailer loop. +

    + +%PARAM ignore_mx_lookup_error no + +

    Ignore DNS MX lookups that produce no response. By default, +the Postfix SMTP client defers delivery and tries again after some +delay. This behavior is required by the SMTP standard.

    + +

    +Specify "ignore_mx_lookup_error = yes" to force a DNS A record +lookup instead. This violates the SMTP standard and can result in +mis-delivery of mail. +

    + +%PARAM import_environment see "postconf -d" output + +

    The list of environment parameters that a privileged Postfix +process will import from a non-Postfix parent process, or name=value +environment overrides. Unprivileged utilities will enforce the +name=value overrides, but otherwise will not change their process +environment. Examples of relevant parameters:

    + +
    + +
    TZ
    + +
    May be needed for sane time keeping on most System-V-ish systems. +
    + +
    DISPLAY
    + +
    Needed for debugging Postfix daemons with an X-windows debugger.
    + +
    XAUTHORITY
    + +
    Needed for debugging Postfix daemons with an X-windows debugger.
    + +
    MAIL_CONFIG
    + +
    Needed to make "postfix -c" work.
    + +
    + +

    Specify a list of names and/or name=value pairs, separated by +whitespace or comma. Specify "{ name=value }" to protect whitespace +or comma in parameter values (whitespace after the opening "{" and +before the closing "}" +is ignored). The form name=value is supported with Postfix version +2.1 and later; the use of {} is supported with Postfix 3.0 and +later.

    + +%PARAM in_flow_delay 1s + +

    Time to pause before accepting a new message, when the message +arrival rate exceeds the message delivery rate. This feature is +turned on by default (it's disabled on SCO UNIX due to an SCO bug). +

    + +

    +With the default 100 Postfix SMTP server process limit, "in_flow_delay += 1s" limits the mail inflow to 100 messages per second above the +number of messages delivered per second. +

    + +

    +Specify 0 to disable the feature. Valid delays are 0..10. +

    + +%PARAM inet_interfaces all + +

    The network interface addresses that this mail system receives +mail on. Specify "all" to receive mail on all network +interfaces (default), and "loopback-only" to receive mail +on loopback network interfaces only (Postfix version 2.2 and later). The +parameter also controls delivery of mail to user@[ip.address]. +

    + +

    +Note 1: you need to stop and start Postfix when this parameter changes. +

    + +

    Note 2: address information may be enclosed inside [], +but this form is not required here.

    + +

    When inet_interfaces specifies just one IPv4 and/or IPv6 address +that is not a loopback address, the Postfix SMTP client will use +this address as the IP source address for outbound mail. Support +for IPv6 is available in Postfix version 2.2 and later.

    + +

    +On a multi-homed firewall with separate Postfix instances listening on the +"inside" and "outside" interfaces, this can prevent each instance from +being able to reach remote SMTP servers on the "other side" of the +firewall. Setting +smtp_bind_address to 0.0.0.0 avoids the potential problem for +IPv4, and setting smtp_bind_address6 to :: solves the problem +for IPv6.

    + +

    +A better solution for multi-homed firewalls is to leave inet_interfaces +at the default value and instead use explicit IP addresses in +the master.cf SMTP server definitions. This preserves the Postfix +SMTP client's +loop detection, by ensuring that each side of the firewall knows that the +other IP address is still the same host. Setting $inet_interfaces to a +single IPv4 and/or IPV6 address is primarily useful with virtual +hosting of domains on +secondary IP addresses, when each IP address serves a different domain +(and has a different $myhostname setting).

    + +

    +See also the proxy_interfaces parameter, for network addresses that +are forwarded to Postfix by way of a proxy or address translator. +

    + +

    +Examples: +

    + +
    +inet_interfaces = all (DEFAULT)
+inet_interfaces = loopback-only (Postfix version 2.2 and later)
+inet_interfaces = 127.0.0.1
+inet_interfaces = 127.0.0.1, [::1] (Postfix version 2.2 and later)
+inet_interfaces = 192.168.1.2, 127.0.0.1
+
    + +%PARAM inet_protocols all + +

    The Internet protocols Postfix will attempt to use when making +or accepting connections. Specify one or more of "ipv4" +or "ipv6", separated by whitespace or commas. The form +"all" is equivalent to "ipv4, ipv6" or "ipv4", depending +on whether the operating system implements IPv6.

    + +

    With Postfix 2.8 and earlier the default is "ipv4". For backwards +compatibility with these releases, the Postfix 2.9 and later upgrade +procedure appends an explicit "inet_protocols = ipv4" setting to +main.cf when no explicit setting is present. This compatibility +workaround will be phased out as IPv6 deployment becomes more common. +

    + +

    This feature is available in Postfix 2.2 and later.

    + +

    Note: you MUST stop and start Postfix after changing this +parameter.

    + +

    On systems that pre-date IPV6_V6ONLY support (RFC 3493), an +IPv6 server will also accept IPv4 connections, even when IPv4 is +turned off with the inet_protocols parameter. On systems with +IPV6_V6ONLY support, Postfix will use separate server sockets for +IPv6 and IPv4, and each will accept only connections for the +corresponding protocol.

    + +

    When IPv4 support is enabled via the inet_protocols parameter, +Postfix will look up DNS type A records, and will convert +IPv4-in-IPv6 client IP addresses (::ffff:1.2.3.4) to their original +IPv4 form (1.2.3.4). The latter is needed on hosts that pre-date +IPV6_V6ONLY support (RFC 3493).

    + +

    When IPv6 support is enabled via the inet_protocols parameter, +Postfix will do DNS type AAAA record lookups.

    + +

    When both IPv4 and IPv6 support are enabled, the Postfix SMTP +client will choose the protocol as specified with the +smtp_address_preference parameter. Postfix versions before 2.8 +attempt to connect via IPv6 before attempting to use IPv4.

    + +

    +Examples: +

    + +
    +inet_protocols = ipv4
+inet_protocols = all (DEFAULT)
+inet_protocols = ipv6
+inet_protocols = ipv4, ipv6
+
    + +%PARAM initial_destination_concurrency 5 + +

    +The initial per-destination concurrency level for parallel delivery +to the same destination. +With per-destination recipient limit > 1, a destination is a domain, +otherwise it is a recipient. +

    + +

    Use transport_initial_destination_concurrency to specify +a transport-specific override, where transport is the master.cf +name of the message delivery transport (Postfix 2.5 and later).

    + +

    +Warning: with concurrency of 1, one bad message can be enough to +block all mail to a site. +

    + +%PARAM invalid_hostname_reject_code 501 + +

    +The numerical Postfix SMTP server response code when the client +HELO or EHLO command parameter is rejected by the reject_invalid_helo_hostname +restriction. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM ipc_idle version dependent + +

    +The time after which a client closes an idle internal communication +channel. The purpose is to allow Postfix daemon processes to +terminate voluntarily after they become idle. This is used, for +example, by the Postfix address resolving and rewriting clients. +

    + +

    With Postfix 2.4 the default value was reduced from 100s to 5s.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM ipc_timeout 3600s + +

    +The time limit for sending or receiving information over an internal +communication channel. The purpose is to break out of deadlock +situations. If the time limit is exceeded the software aborts with a +fatal error. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM ipc_ttl 1000s + +

    +The time after which a client closes an active internal communication +channel. The purpose is to allow Postfix daemon processes to +terminate voluntarily +after reaching their client limit. This is used, for example, by +the Postfix address resolving and rewriting clients. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM line_length_limit 2048 + +

    Upon input, long lines are chopped up into pieces of at most +this length; upon delivery, long lines are reconstructed.

    + +%PARAM lmtp_connect_timeout 0s + +

    The Postfix LMTP client time limit for completing a TCP connection, or +zero (use the operating system built-in time limit). When no +connection can be made within the deadline, the LMTP client tries +the next address on the mail exchanger list.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    +Example: +

    + +
    +lmtp_connect_timeout = 30s
+
    + +%PARAM lmtp_data_done_timeout 600s + +

    The Postfix LMTP client time limit for sending the LMTP ".", +and for receiving the remote LMTP server response. When no response +is received within the deadline, a warning is logged that the mail +may be delivered multiple times.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_data_init_timeout 120s + +

    +The Postfix LMTP client time limit for sending the LMTP DATA command, +and +for receiving the remote LMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_data_xfer_timeout 180s + +

    +The Postfix LMTP client time limit for sending the LMTP message +content. +When the connection stalls for more than $lmtp_data_xfer_timeout +the LMTP client terminates the transfer. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_lhlo_timeout 300s + +

    The Postfix LMTP client time limit for receiving the LMTP +greeting banner. When the remote LMTP server drops the connection +without sending a +greeting banner, or when it sends no greeting banner within the +deadline, the LMTP client tries the next address on the mail +exchanger list.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_mail_timeout 300s + +

    +The Postfix LMTP client time limit for sending the MAIL FROM command, +and for receiving the remote LMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_quit_timeout 300s + +

    +The Postfix LMTP client time limit for sending the QUIT command, +and for receiving the remote LMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_rcpt_timeout 300s + +

    +The Postfix LMTP client time limit for sending the RCPT TO command, +and for receiving the remote LMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_rset_timeout 20s + +

    The Postfix LMTP client time limit for sending the RSET command, +and for receiving the remote LMTP server response. The LMTP client +sends RSET in +order to finish a recipient address probe, or to verify that a +cached connection is still alive.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM lmtp_send_xforward_command no + +

    +Send an XFORWARD command to the remote LMTP server when the LMTP LHLO +server response announces XFORWARD support. This allows an lmtp(8) +delivery agent, used for content filter message injection, to +forward the name, address, protocol and HELO name of the original +client to the content filter and downstream queuing LMTP server. +Before you change the value to yes, it is best to make sure that +your content filter supports this command. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM lmtp_skip_quit_response no + +

    +Wait for the response to the LMTP QUIT command. +

    + +%PARAM lmtp_xforward_timeout 300s + +

    +The Postfix LMTP client time limit for sending the XFORWARD command, +and for receiving the remote LMTP server response. +

    + +

    +In case of problems the client does NOT try the next address on +the mail exchanger list. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM local_command_shell + +

    +Optional shell program for local(8) delivery to non-Postfix command. +By default, non-Postfix commands are executed directly; commands +are given to given to the default shell (typically, /bin/sh) only +when they contain shell meta characters or shell built-in commands. +

    + +

    "sendmail's restricted shell" (smrsh) is what most people will +use in order to restrict what programs can be run from e.g. .forward +files (smrsh is part of the Sendmail distribution).

    + +

    Note: when a shell program is specified, it is invoked even +when the command contains no shell built-in commands or meta +characters.

    + +

    +Example: +

    + +
    +local_command_shell = /some/where/smrsh -c
+local_command_shell = /bin/bash -c
+
    + +%PARAM local_destination_concurrency_limit 2 + +

    The maximal number of parallel deliveries via the local mail +delivery transport to the same recipient (when +"local_destination_recipient_limit = 1") or the maximal number of +parallel deliveries to the same local domain (when +"local_destination_recipient_limit > 1"). This limit is enforced by +the queue manager. The message delivery transport name is the first +field in the entry in the master.cf file.

    + +

    A low limit of 2 is recommended, just in case someone has an +expensive shell command in a .forward file or in an alias (e.g., +a mailing list manager). You don't want to run lots of those at +the same time.

    + +%PARAM local_destination_recipient_limit 1 + +

    The maximal number of recipients per message delivery via the +local mail delivery transport. This limit is enforced by the queue +manager. The message delivery transport name is the first field in +the entry in the master.cf file.

    + +

    Setting this parameter to a value > 1 changes the meaning of +local_destination_concurrency_limit from concurrency per recipient +into concurrency per domain.

    + +%PARAM local_recipient_maps proxy:unix:passwd.byname $alias_maps + +

    Lookup tables with all names or addresses of local recipients: +a recipient address is local when its domain matches $mydestination, +$inet_interfaces or $proxy_interfaces. Specify @domain as a +wild-card for domains that do not have a valid recipient list. +Technically, tables listed with $local_recipient_maps are used as +lists: Postfix needs to know only if a lookup string is found or +not, but it does not use the result from table lookup.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +If this parameter is non-empty (the default), then the Postfix SMTP +server will reject mail for unknown local users. +

    + +

    +To turn off local recipient checking in the Postfix SMTP server, +specify "local_recipient_maps =" (i.e. empty). +

    + +

    +The default setting assumes that you use the default Postfix local +delivery agent for local delivery. You need to update the +local_recipient_maps setting if: +

    + +
      + +
    • You redefine the local delivery agent in master.cf. + +
    • You redefine the "local_transport" setting in main.cf. + +
    • You use the "luser_relay", "mailbox_transport", or "fallback_transport" +feature of the Postfix local(8) delivery agent. + +
    + +

    +Details are described in the LOCAL_RECIPIENT_README file. +

    + +

    +Beware: if the Postfix SMTP server runs chrooted, you need to access +the passwd file via the proxymap(8) service, in order to overcome +chroot access restrictions. The alternative, maintaining a copy of +the system password file in the chroot jail is not practical. +

    + +

    +Examples: +

    + +
    +local_recipient_maps =
+
    + +%PARAM local_transport local:$myhostname + +

    The default mail delivery transport and next-hop destination +for final delivery to domains listed with mydestination, and for +[ipaddress] destinations that match $inet_interfaces or $proxy_interfaces. +This information can be overruled with the transport(5) table.

    + +

    +By default, local mail is delivered to the transport called "local", +which is just the name of a service that is defined the master.cf file. +

    + +

    +Specify a string of the form transport:nexthop, where transport +is the name of a mail delivery transport defined in master.cf. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. +

    + +

    +Beware: if you override the default local delivery agent then you +need to review the LOCAL_RECIPIENT_README document, otherwise the +SMTP server may reject mail for local recipients. +

    + +%PARAM luser_relay + +

    +Optional catch-all destination for unknown local(8) recipients. +By default, mail for unknown recipients in domains that match +$mydestination, $inet_interfaces or $proxy_interfaces is returned +as undeliverable. +

    + +

    +The luser_relay value is not subject to Postfix configuration +parameter $name expansion. Instead, the following $name expansions +are done: +

    + +
    + +
    $domain
    + +
    The recipient domain.
    + +
    $extension
    + +
    The recipient address extension.
    + +
    $home
    + +
    The recipient's home directory.
    + +
    $local
    + +
    The entire recipient address localpart.
    + +
    $recipient
    + +
    The full recipient address.
    + +
    $recipient_delimiter
    + +
    The address extension delimiter that was found in the recipient +address (Postfix 2.11 and later), or the system-wide recipient +address extension delimiter (Postfix 2.10 and earlier).
    + +
    $shell
    + +
    The recipient's login shell.
    + +
    $user
    + +
    The recipient username.
    + +
    ${name?value}
    + +
    Expands to value when $name has a non-empty value.
    + +
    ${name:value}
    + +
    Expands to value when $name has an empty value.
    + +
    + +

    +Instead of $name you can also specify ${name} or $(name). +

    + +

    +Note: luser_relay works only for the Postfix local(8) delivery agent. +

    + +

    +Note: if you use this feature for accounts not in the UNIX password +file, then you must specify "local_recipient_maps =" (i.e. empty) +in the main.cf file, otherwise the Postfix SMTP server will reject mail +for non-UNIX accounts with "User unknown in local recipient table". +

    + +

    +Examples: +

    + +
    +luser_relay = $user@other.host
+luser_relay = $local@other.host
+luser_relay = admin+$local
+
    + +%PARAM mail_name Postfix + +

    +The mail system name that is displayed in Received: headers, in +the SMTP greeting banner, and in bounced mail. +

    + +%PARAM mail_owner postfix + +

    +The UNIX system account that owns the Postfix queue and most Postfix +daemon processes. Specify the name of an unprivileged user account +that does not share a user or group ID with other accounts, and that +owns no other files +or processes on the system. In particular, don't specify nobody +or daemon. PLEASE USE A DEDICATED USER ID AND GROUP ID. +

    + +

    +When this parameter value is changed you need to re-run "postfix +set-permissions" (with Postfix version 2.0 and earlier: +"/etc/postfix/post-install set-permissions". +

    + +%PARAM mail_spool_directory see "postconf -d" output + +

    +The directory where local(8) UNIX-style mailboxes are kept. The +default setting depends on the system type. Specify a name ending +in / for maildir-style delivery. +

    + +

    +Note: maildir delivery is done with the privileges of the recipient. +If you use the mail_spool_directory setting for maildir style +delivery, then you must create the top-level maildir directory in +advance. Postfix will not create it. +

    + +

    +Examples: +

    + +
    +mail_spool_directory = /var/mail
+mail_spool_directory = /var/spool/mail
+
    + +%PARAM mail_version see "postconf -d" output + +

    +The version of the mail system. Stable releases are named +major.minor.patchlevel. Experimental releases +also include the release date. The version string can be used in, +for example, the SMTP greeting banner. +

    + +%PARAM mailbox_command + +

    +Optional external command that the local(8) delivery agent should +use for mailbox delivery. The command is run with the user ID and +the primary group ID privileges of the recipient. Exception: +command delivery for root executes with $default_privs privileges. +This is not a problem, because 1) mail for root should always be +aliased to a real user and 2) don't log in as root, use "su" instead. +

    + +

    +The following environment variables are exported to the command: +

    + +
    + +
    CLIENT_ADDRESS
    + +
    Remote client network address. Available in Postfix version 2.2 and +later.
    + +
    CLIENT_HELO
    + +
    Remote client EHLO command parameter. Available in Postfix version 2.2 +and later.
    + +
    CLIENT_HOSTNAME
    + +
    Remote client hostname. Available in Postfix version 2.2 and later. +
    + +
    CLIENT_PROTOCOL
    + +
    Remote client protocol. Available in Postfix version 2.2 and later. +
    + +
    DOMAIN
    + +
    The domain part of the recipient address.
    + +
    EXTENSION
    + +
    The optional address extension.
    + +
    HOME
    + +
    The recipient home directory.
    + +
    LOCAL
    + +
    The recipient address localpart.
    + +
    LOGNAME
    + +
    The recipient's username.
    + +
    ORIGINAL_RECIPIENT
    + +
    The entire recipient address, before any address rewriting or +aliasing.
    + +
    RECIPIENT
    + +
    The full recipient address.
    + +
    SASL_METHOD
    + +
    SASL authentication method specified in the remote client AUTH +command. Available in Postfix version 2.2 and later.
    + +
    SASL_SENDER
    + +
    SASL sender address specified in the remote client MAIL FROM +command. Available in Postfix version 2.2 and later.
    + +
    SASL_USER
    + +
    SASL username specified in the remote client AUTH command. +Available in Postfix version 2.2 and later.
    + +
    SENDER
    + +
    The full sender address.
    + +
    SHELL
    + +
    The recipient's login shell.
    + +
    USER
    + +
    The recipient username.
    + +
    + +

    +Unlike other Postfix configuration parameters, the mailbox_command +parameter is not subjected to $name substitutions. This is to make +it easier to specify shell syntax (see example below). +

    + +

    +If you can, avoid shell meta characters because they will force +Postfix to run an expensive shell process. If you're delivering +via "procmail" then running a shell won't make a noticeable difference +in the total cost. +

    + +

    +Note: if you use the mailbox_command feature to deliver mail +system-wide, you must set up an alias that forwards mail for root +to a real user. +

    + +

    The precedence of local(8) delivery features from high to low +is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, +mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, +fallback_transport_maps, fallback_transport and luser_relay.

    + +

    +Examples: +

    + +
    +mailbox_command = /some/where/procmail
+mailbox_command = /some/where/procmail -a "$EXTENSION"
+mailbox_command = /some/where/maildrop -d "$USER"
+        -f "$SENDER" "$EXTENSION"
+
    + +%PARAM mailbox_size_limit 51200000 + +

    The maximal size of any local(8) individual mailbox or maildir +file, or zero (no limit). In fact, this limits the size of any +file that is written to upon local delivery, including files written +by external commands that are executed by the local(8) delivery +agent.

    + +

    +This limit must not be smaller than the message size limit. +

    + +%PARAM maps_rbl_reject_code 554 + +

    +The numerical Postfix SMTP server response code when a remote SMTP +client request is blocked by the reject_rbl_client, reject_rhsbl_client, +reject_rhsbl_reverse_client, reject_rhsbl_sender or +reject_rhsbl_recipient restriction. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM masquerade_classes envelope_sender, header_sender, header_recipient + +

    +What addresses are subject to address masquerading. +

    + +

    +By default, address masquerading is limited to envelope sender +addresses, and to header sender and header recipient addresses. +This allows you to use address masquerading on a mail gateway while +still being able to forward mail to users on individual machines. +

    + +

    +Specify zero or more of: envelope_sender, envelope_recipient, +header_sender, header_recipient +

    + +%PARAM masquerade_domains + +

    +Optional list of domains whose subdomain structure will be stripped +off in email addresses. +

    + +

    +The list is processed left to right, and processing stops at the +first match. Thus, +

    + +
    +
    +masquerade_domains = foo.example.com example.com
+
    +
    + +

    +strips "user@any.thing.foo.example.com" to "user@foo.example.com", +but strips "user@any.thing.else.example.com" to "user@example.com". +

    + +

    +A domain name prefixed with ! means do not masquerade this domain +or its subdomains. Thus, +

    + +
    +
    +masquerade_domains = !foo.example.com example.com
+
    +
    + +

    +does not change "user@any.thing.foo.example.com" or "user@foo.example.com", +but strips "user@any.thing.else.example.com" to "user@example.com". +

    + +

    Note: with Postfix version 2.2, message header address masquerading +happens only when message header address rewriting is enabled:

    + +
      + +
    • The message is received with the Postfix sendmail(1) command, + +
    • The message is received from a network client that matches +$local_header_rewrite_clients, + +
    • The message is received from the network, and the +remote_header_rewrite_domain parameter specifies a non-empty value. + +
    + +

    To get the behavior before Postfix version 2.2, specify +"local_header_rewrite_clients = static:all".

    + + +

    +Example: +

    + +
    +masquerade_domains = $mydomain
+
    + +%PARAM masquerade_exceptions + +

    +Optional list of user names that are not subjected to address +masquerading, even when their addresses match $masquerade_domains. +

    + +

    +By default, address masquerading makes no exceptions. +

    + +

    +Specify a list of user names, "/file/name" or "type:table" patterns, +separated by commas and/or whitespace. The list is matched left to +right, and the search stops on the first match. A "/file/name" +pattern is replaced +by its contents; a "type:table" lookup table is matched when a name +matches a lookup key (the lookup result is ignored). Continue long +lines by starting the next line with whitespace. Specify "!pattern" +to exclude a name from the list. The form "!/file/name" is supported +only in Postfix version 2.4 and later.

    + +

    +Examples: +

    + +
    +masquerade_exceptions = root, mailer-daemon
+masquerade_exceptions = root
+
    + +%PARAM max_idle 100s + +

    +The maximum amount of time that an idle Postfix daemon process waits +for an incoming connection before terminating voluntarily. This +parameter +is ignored by the Postfix queue manager and by other long-lived +Postfix daemon processes. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM max_use 100 + +

    +The maximal number of incoming connections that a Postfix daemon +process will service before terminating voluntarily. This parameter +is ignored by the Postfix queue +manager and by other long-lived Postfix daemon processes. +

    + +%PARAM maximal_backoff_time 4000s + +

    +The maximal time between attempts to deliver a deferred message. +

    + +

    This parameter should be set to a value greater than or equal +to $minimal_backoff_time. See also $queue_run_delay.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM maximal_queue_lifetime 5d + +

    +Consider a message as undeliverable, when delivery fails with a +temporary error, and the time in the queue has reached the +maximal_queue_lifetime limit. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is d (days). +

    + +

    +Specify 0 when mail delivery should be tried only once. +

    + +%PARAM lmdb_map_size 16777216 + +

    +The initial OpenLDAP LMDB database size limit in bytes. Each time +a database becomes full, its size limit is doubled. +

    + +

    +This feature is available in Postfix 2.11 and later. +

    + +%PARAM message_size_limit 10240000 + +

    +The maximal size in bytes of a message, including envelope information. +

    + +

    Note: be careful when making changes. Excessively small values +will result in the loss of non-delivery notifications, when a bounce +message size exceeds the local or remote MTA's message size limit. +

    + +%PARAM minimal_backoff_time 300s + +

    +The minimal time between attempts to deliver a deferred message; +prior to Postfix 2.4 the default value was 1000s. +

    + +

    +This parameter also limits the time an unreachable destination is +kept in the short-term, in-memory, destination status cache. +

    + +

    This parameter should be set greater than or equal to +$queue_run_delay. See also $maximal_backoff_time.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM multi_recipient_bounce_reject_code 550 + +

    +The numerical Postfix SMTP server response code when a remote SMTP +client request is blocked by the reject_multi_recipient_bounce +restriction. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM mydestination $myhostname, localhost.$mydomain, localhost + +

    The list of domains that are delivered via the $local_transport +mail delivery transport. By default this is the Postfix local(8) +delivery agent which looks up all recipients in /etc/passwd and +/etc/aliases. The SMTP server validates recipient addresses with +$local_recipient_maps and rejects non-existent recipients. See also +the local domain class in the ADDRESS_CLASS_README file. +

    + +

    +The default mydestination value specifies names for the local +machine only. On a mail domain gateway, you should also include +$mydomain. +

    + +

    +The $local_transport delivery method is also selected for mail +addressed to user@[the.net.work.address] of the mail system (the +IP addresses specified with the inet_interfaces and proxy_interfaces +parameters). +

    + +

    +Warnings: +

    + +
      + +

    • Do not specify the names of virtual domains - those domains +are specified elsewhere. See VIRTUAL_README for more information.

      + +

    • Do not specify the names of domains that this machine is +backup MX host for. See STANDARD_CONFIGURATION_README for how to +set up backup MX hosts.

      + +

    • By default, the Postfix SMTP server rejects mail for recipients +not listed with the local_recipient_maps parameter. See the +postconf(5) manual for a description of the local_recipient_maps +and unknown_local_recipient_reject_code parameters.

      + +
    + +

    +Specify a list of host or domain names, "/file/name" or "type:table" +patterns, separated by commas and/or whitespace. A "/file/name" +pattern is replaced by its contents; a "type:table" lookup table +is matched when a name matches a lookup key (the lookup result is +ignored). Continue long lines by starting the next line with +whitespace.

    + +

    +Examples: +

    + +
    +mydestination = $myhostname, localhost.$mydomain $mydomain
+mydestination = $myhostname, localhost.$mydomain www.$mydomain, ftp.$mydomain
+
    + +%PARAM mydomain see "postconf -d" output + +

    +The internet domain name of this mail system. The default is to +use $myhostname minus the first component, or "localdomain" (Postfix +2.3 and later). $mydomain is used as +a default value for many other configuration parameters. +

    + +

    +Example: +

    + +
    +mydomain = domain.tld
+
    + +%PARAM myhostname see "postconf -d" output + +

    +The internet hostname of this mail system. The default is to use +the fully-qualified domain name (FQDN) from gethostname(), or to +use the non-FQDN result from gethostname() and append ".$mydomain". +$myhostname is used as a default value for many other configuration +parameters.

    + +

    +Example: +

    + +
    +myhostname = host.example.com
+
    + +%PARAM mynetworks see "postconf -d" output + +

    +The list of "trusted" remote SMTP clients that have more privileges than +"strangers". +

    + +

    +In particular, "trusted" SMTP clients are allowed to relay mail +through Postfix. See the smtpd_relay_restrictions parameter +description in the postconf(5) manual. +

    + +

    +You can specify the list of "trusted" network addresses by hand +or you can let Postfix do it for you (which is the default). +See the description of the mynetworks_style parameter for more +information. +

    + +

    +If you specify the mynetworks list by hand, +Postfix ignores the mynetworks_style setting. +

    + +

    Specify a list of network addresses or network/netmask patterns, +separated by commas and/or whitespace. Continue long lines by +starting the next line with whitespace.

    + +

    The netmask specifies the number of bits in the network part +of a host address. You can also specify "/file/name" or "type:table" +patterns. A "/file/name" pattern is replaced by its contents; a +"type:table" lookup table is matched when a table entry matches a +lookup string (the lookup result is ignored).

    + +

    The list is matched left to right, and the search stops on the +first match. Specify "!pattern" to exclude an address or network +block from the list. The form "!/file/name" is supported only +in Postfix version 2.4 and later.

    + +

    Note 1: Pattern matching of domain names is controlled by the +or absence of "mynetworks" in the parent_domain_matches_subdomains +parameter value.

    + +

    Note 2: IP version 6 address information must be specified inside +[] in the mynetworks value, and in files specified with +"/file/name". IP version 6 addresses contain the ":" character, +and would otherwise be confused with a "type:table" pattern.

    + +

    Examples:

    + +
     
+mynetworks = 127.0.0.0/8 168.100.189.0/28
+mynetworks = !192.168.0.1, 192.168.0.0/28
+mynetworks = 127.0.0.0/8 168.100.189.0/28 [::1]/128 [2001:240:587::]/64 
+mynetworks = $config_directory/mynetworks
+mynetworks = hash:/etc/postfix/network_table
+
    + +%PARAM myorigin $myhostname + +

    +The domain name that locally-posted mail appears to come +from, and that locally posted mail is delivered to. The default, +$myhostname, is adequate for small sites. If you run a domain with +multiple machines, you should (1) change this to $mydomain and (2) +set up a domain-wide alias database that aliases each user to +user@that.users.mailhost. +

    + +

    +Example: +

    + +
    +myorigin = $mydomain
+
    + +%PARAM notify_classes resource, software + +

    +The list of error classes that are reported to the postmaster. The +default is to report only the most serious problems. The paranoid +may wish to turn on the policy (UCE and mail relaying) and protocol +error (broken mail software) reports. +

    + +

    NOTE: postmaster notifications may contain confidential information +such as SASL passwords or message content. It is the system +administrator's responsibility to treat such information with care. +

    + +

    +The error classes are: +

    + +
    + +
    bounce (also implies 2bounce)
    + +
    Send the postmaster copies of the headers of bounced mail, and +send transcripts of SMTP sessions when Postfix rejects mail. The +notification is sent to the address specified with the +bounce_notice_recipient configuration parameter (default: postmaster). +
    + +
    2bounce
    + +
    Send undeliverable bounced mail to the postmaster. The notification +is sent to the address specified with the 2bounce_notice_recipient +configuration parameter (default: postmaster).
    + +
    data
    + +
    Send the postmaster a transcript of the SMTP session with an +error because a critical data file was unavailable. The notification +is sent to the address specified with the error_notice_recipient +configuration parameter (default: postmaster).
    This feature +is available in Postfix 2.9 and later.
    + +
    delay
    + +
    Send the postmaster copies of the headers of delayed mail (see +delay_warning_time). The +notification is sent to the address specified with the +delay_notice_recipient configuration parameter (default: postmaster). +
    + +
    policy
    + +
    Send the postmaster a transcript of the SMTP session when a +client request was rejected because of (UCE) policy. The notification +is sent to the address specified with the error_notice_recipient +configuration parameter (default: postmaster).
    + +
    protocol
    + +
    Send the postmaster a transcript of the SMTP session in case +of client or server protocol errors. 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. 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).
    + +
    + +

    +Examples: +

    + +
    +notify_classes = bounce, delay, policy, protocol, resource, software
+notify_classes = 2bounce, resource, software
+
    + +%PARAM parent_domain_matches_subdomains see "postconf -d" output + +

    +A list of Postfix features where the pattern "example.com" also +matches subdomains of example.com, +instead of requiring an explicit ".example.com" pattern. This is +planned backwards compatibility: eventually, all Postfix features +are expected to require explicit ".example.com" style patterns when +you really want to match subdomains. +

    + +

    The following Postfix feature names are supported.

    + +
    + +
    Postfix version 1.0 and later
    + +
    +debug_peer_list, +fast_flush_domains, +mynetworks, +permit_mx_backup_networks, +relay_domains, +transport_maps +
    + +
    Postfix version 1.1 and later
    + +
    +qmqpd_authorized_clients, +smtpd_access_maps, +
    + +
    Postfix version 2.8 and later
    + +
    +postscreen_access_list +
    + +
    Postfix version 3.0 and later
    + +
    +smtpd_client_event_limit_exceptions +
    + +
    + +%PARAM propagate_unmatched_extensions canonical, virtual + +

    +What address lookup tables copy an address extension from the lookup +key to the lookup result. +

    + +

    +For example, with a virtual(5) mapping of "joe@example.com => +joe.user@example.net", the address "joe+foo@example.com" +would rewrite to "joe.user+foo@example.net". +

    + +

    +Specify zero or more of canonical, virtual, alias, +forward, include or generic. These cause +address extension +propagation with canonical(5), virtual(5), and aliases(5) maps, +with local(8) .forward and :include: file lookups, and with smtp(8) +generic maps, respectively.

    + +

    +Note: enabling this feature for types other than canonical +and virtual is likely to cause problems when mail is forwarded +to other sites, especially with mail that is sent to a mailing list +exploder address. +

    + +

    +Examples: +

    + +
    +propagate_unmatched_extensions = canonical, virtual, alias,
+        forward, include
+propagate_unmatched_extensions = canonical, virtual
+
    + +%PARAM proxy_interfaces + +

    +The network interface addresses that this mail system receives mail +on by way of a proxy or network address translation unit. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +

    You must specify your "outside" proxy/NAT 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: +

    + +
    +proxy_interfaces = 1.2.3.4
+
    + +%PARAM qmgr_message_active_limit 20000 + +

    +The maximal number of messages in the active queue. +

    + +%PARAM qmgr_message_recipient_limit 20000 + +

    The maximal number of recipients held in memory by the Postfix +queue manager, and the maximal size of the short-term, +in-memory "dead" destination status cache.

    + +%PARAM qmgr_message_recipient_minimum 10 + +

    +The minimal number of in-memory recipients for any message. This +takes priority over any other in-memory recipient limits (i.e., +the global qmgr_message_recipient_limit and the per transport +_recipient_limit) if necessary. The minimum value allowed for this +parameter is 1. +

    + +%PARAM qmqpd_authorized_clients + +

    +What remote QMQP clients are allowed to connect to the Postfix QMQP +server port. +

    + +

    +By default, no client is allowed to use the service. This is +because the QMQP server will relay mail to any destination. +

    + +

    +Specify a list of client patterns. A list pattern specifies a host +name, a domain name, an internet address, or a network/mask pattern, +where the mask specifies the number of bits in the network part. +When a pattern specifies a file name, its contents are substituted +for the file name; when a pattern is a "type:table" table specification, +table lookup is used instead.

    + +

    +Patterns are separated by whitespace and/or commas. In order to +reverse the result, precede a pattern with an +exclamation point (!). The form "!/file/name" is supported only +in Postfix version 2.4 and later. +

    + +

    Pattern matching of domain names is controlled by the presence +or absence of "qmqpd_authorized_clients" in the +parent_domain_matches_subdomains parameter value.

    + +

    +Example: +

    + +
    +qmqpd_authorized_clients = !192.168.0.1, 192.168.0.0/24
+
    + +%PARAM qmqpd_error_delay 1s + +

    +How long the Postfix QMQP server will pause before sending a negative +reply to the remote QMQP client. The purpose is to slow down confused +or malicious clients. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM qmqpd_timeout 300s + +

    +The time limit for sending or receiving information over the network. +If a read or write operation blocks for more than $qmqpd_timeout +seconds the Postfix QMQP server gives up and disconnects. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM queue_minfree 0 + +

    +The minimal amount of free space in bytes in the queue file system +that is needed to receive mail. This is currently used by the +Postfix SMTP server to decide if it will accept any mail at all. +

    + +

    +By default, the Postfix SMTP server rejects MAIL FROM commands when +the amount of free space is less than 1.5*$message_size_limit +(Postfix version 2.1 and later). +To specify a higher minimum free space limit, specify a queue_minfree +value that is at least 1.5*$message_size_limit. +

    + +

    +With Postfix versions 2.0 and earlier, a queue_minfree value of +zero means there is no minimum required amount of free space. +

    + +%PARAM queue_run_delay 300s + +

    +The time between deferred queue scans by the queue manager; +prior to Postfix 2.4 the default value was 1000s. +

    + +

    This parameter should be set less than or equal to +$minimal_backoff_time. See also $maximal_backoff_time.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM rbl_reply_maps + +

    +Optional lookup tables with RBL response templates. The tables are +indexed by the RBL domain name. By default, Postfix uses the default +template as specified with the default_rbl_reply configuration +parameter. See there for a discussion of the syntax of RBL reply +templates. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM receive_override_options + +

    Enable or disable recipient validation, built-in content +filtering, or address mapping. Typically, these are specified in +master.cf as command-line arguments for the smtpd(8), qmqpd(8) or +pickup(8) daemons.

    + +

    Specify zero or more of the following options. The options +override main.cf settings and are either implemented by smtpd(8), +qmqpd(8), or pickup(8) themselves, or they are forwarded to the +cleanup server.

    + +
    + +
    no_unknown_recipient_checks
    + +
    Do not try to reject unknown recipients (SMTP server only). +This is typically specified AFTER an external content filter. +
    + +
    no_address_mappings
    + +
    Disable canonical address mapping, virtual alias map expansion, +address masquerading, and automatic BCC (blind carbon-copy) +recipients. This is typically specified BEFORE an external content +filter.
    + +
    no_header_body_checks
    + +
    Disable header/body_checks. This is typically specified AFTER +an external content filter.
    + +
    no_milters
    + +
    Disable Milter (mail filter) applications. This is typically +specified AFTER an external content filter.
    + +
    + +

    +Note: when the "BEFORE content filter" receive_override_options +setting is specified in the main.cf file, specify the "AFTER content +filter" receive_override_options setting in master.cf (and vice +versa). +

    + +

    +Examples: +

    + +
    +receive_override_options =
+    no_unknown_recipient_checks, no_header_body_checks
+receive_override_options = no_address_mappings
+
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM recipient_bcc_maps + +

    +Optional BCC (blind carbon-copy) address lookup tables, indexed by +recipient address. The BCC address (multiple results are not +supported) is added when mail enters from outside of Postfix. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +The table search order is as follows: +

    + +
      + +
    • Look up the "user+extension@domain.tld" address including the +optional address extension. + +
    • Look up the "user@domain.tld" address without the optional +address extension. + +
    • Look up the "user+extension" address local part when the +recipient domain equals $myorigin, $mydestination, $inet_interfaces +or $proxy_interfaces. + +
    • Look up the "user" address local part when the recipient domain +equals $myorigin, $mydestination, $inet_interfaces or $proxy_interfaces. + +
    • Look up the "@domain.tld" part. + +
    + +

    +Note: with Postfix 2.3 and later the BCC address is added as if it +was specified with NOTIFY=NONE. The sender will not be notified +when the BCC address is undeliverable, as long as all down-stream +software implements RFC 3461. +

    + +

    +Note: with Postfix 2.2 and earlier the sender will unconditionally +be notified when the BCC address is undeliverable. +

    + +

    Note: automatic BCC recipients are produced only for new mail. +To avoid mailer loops, automatic BCC recipients are not generated +after Postfix forwards mail internally, or after Postfix generates +mail itself.

    + +

    +Example: +

    + +
    +recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
+
    + +

    +After a change, run "postmap /etc/postfix/recipient_bcc". +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM recipient_canonical_maps + +

    +Optional address mapping lookup tables for envelope and header +recipient addresses. +The table format and lookups are documented in canonical(5). +

    + +

    +Note: $recipient_canonical_maps is processed before $canonical_maps. +

    + +

    +Example: +

    + +
    +recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
+
    + +%PARAM recipient_delimiter + +

    The set of characters that can separate a user name from its +extension (example: user+foo), or a .forward file name from its +extension (example: .forward+foo). Basically, the software tries +user+foo and .forward+foo before trying user and .forward. This +implementation recognizes one delimiter character and one extension +per email address or .forward file name.

    + +

    When the recipient_delimiter set contains multiple characters +(Postfix 2.11 and later), a user name or .forward file name is +separated from its extension by the first character that matches +the recipient_delimiter set.

    + +

    See canonical(5), local(8), relocated(5) and virtual(5) for the +effects of recipient_delimiter on lookups in aliases, canonical, +virtual, and relocated maps, and see the propagate_unmatched_extensions +parameter for propagating an extension from one email address to +another.

    + +

    When used in command_execution_directory, forward_path, or +luser_relay, ${recipient_delimiter} is replaced with the actual +recipient delimiter that was found in the recipient email address +(Postfix 2.11 and later), or it is replaced with the main.cf +recipient_delimiter parameter value (Postfix 2.10 and earlier). +

    + +

    The recipient_delimiter is not applied to the mailer-daemon +address, the postmaster address, or the double-bounce address. With +the default "owner_request_special = yes" setting, the recipient_delimiter +is also not applied to addresses with the special "owner-" prefix +or the special "-request" suffix.

    + +

    +Examples: +

    + +
    +# Handle Postfix-style extensions.
+recipient_delimiter = +
+
    + +
    +# Handle both Postfix and qmail extensions (Postfix 2.11 and later).
+recipient_delimiter = +-
+
    + +
    +# Use .forward for mail without address extension, and for mail with
+# an unrecognized address extension.
+forward_path = $home/.forward${recipient_delimiter}${extension},
+    $home/.forward
+
    + +%PARAM reject_code 554 + +

    +The numerical Postfix SMTP server response code when a remote SMTP +client request is rejected by the "reject" restriction. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM relay_domains Postfix ≥ 3.0: empty, Postfix < 3.0: $mydestination + +

    What destination domains (and subdomains thereof) this system +will relay mail to. For details about how +the relay_domains value is used, see the description of the +permit_auth_destination and reject_unauth_destination SMTP recipient +restrictions.

    + +

    Domains that match $relay_domains are delivered with the +$relay_transport mail delivery transport. The SMTP server validates +recipient addresses with $relay_recipient_maps and rejects non-existent +recipients. See also the relay domains address class in the +ADDRESS_CLASS_README file.

    + +

    Note: Postfix will not automatically forward mail for domains +that list this system as their primary or backup MX host. See the +permit_mx_backup restriction in the postconf(5) manual page.

    + +

    Specify a list of host or domain names, "/file/name" patterns +or "type:table" lookup tables, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. A +"/file/name" pattern is replaced by its contents; a "type:table" +lookup table is matched when a (parent) domain appears as lookup +key. Specify "!pattern" to exclude a domain from the list. The form +"!/file/name" is supported only in Postfix version 2.4 and later. +

    + +

    Pattern matching of domain names is controlled by the presence +or absence of "relay_domains" in the parent_domain_matches_subdomains +parameter value.

    + +%PARAM relay_domains_reject_code 554 + +

    +The numerical Postfix SMTP server response code when a client +request is rejected by the reject_unauth_destination recipient +restriction. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM relay_recipient_maps + +

    Optional lookup tables with all valid addresses in the domains +that match $relay_domains. Specify @domain as a wild-card for +domains that have no valid recipient list, and become a source of +backscatter mail: Postfix accepts spam for non-existent recipients +and then floods innocent people with undeliverable mail. Technically, +tables +listed with $relay_recipient_maps are used as lists: Postfix needs +to know only if a lookup string is found or not, but it does not +use the result from table lookup.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +If this parameter is non-empty, then the Postfix SMTP server will reject +mail to unknown relay users. This feature is off by default. +

    + +

    +See also the relay domains address class in the ADDRESS_CLASS_README +file. +

    + +

    +Example: +

    + +
    +relay_recipient_maps = hash:/etc/postfix/relay_recipients
+
    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM relayhost + +

    +The next-hop destination of non-local mail; overrides non-local +domains in recipient addresses. This information is overruled with +relay_transport, sender_dependent_default_transport_maps, +default_transport, sender_dependent_relayhost_maps +and with the transport(5) table. +

    + +

    +On an intranet, specify the organizational domain name. If your +internal DNS uses no MX records, specify the name of the intranet +gateway host instead. +

    + +

    +In the case of SMTP, specify a domain name, hostname, hostname:port, +[hostname]:port, [hostaddress] or [hostaddress]:port. The form +[hostname] turns off MX lookups. +

    + +

    +If you're connected via UUCP, see the UUCP_README file for useful +information. +

    + +

    +Examples: +

    + +
    +relayhost = $mydomain
+relayhost = [gateway.example.com]
+relayhost = uucphost
+relayhost = [an.ip.add.ress]
+
    + +%PARAM relocated_maps + +

    +Optional lookup tables with new contact information for users or +domains that no longer exist. The table format and lookups are +documented in relocated(5). +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +If you use this feature, run "postmap /etc/postfix/relocated" to +build the necessary DBM or DB file after change, then "postfix +reload" to make the changes visible. +

    + +

    +Examples: +

    + +
    +relocated_maps = dbm:/etc/postfix/relocated
+relocated_maps = hash:/etc/postfix/relocated
+
    + +%PARAM require_home_directory no + +

    +Require that a local(8) recipient's home directory exists +before mail delivery is attempted. By default this test is disabled. +It can be useful for environments that import home directories to +the mail server (IMPORTING HOME DIRECTORIES IS NOT RECOMMENDED). +

    + +%PARAM resolve_dequoted_address yes + +

    Resolve a recipient address safely instead of correctly, by +looking inside quotes.

    + +

    By default, the Postfix address resolver does not quote the +address localpart as per RFC 822, so that additional @ or % or ! +operators remain visible. This behavior is safe but it is also +technically incorrect.

    + +

    If you specify "resolve_dequoted_address = no", then +the Postfix +resolver will not know about additional @ etc. operators in the +address localpart. This opens opportunities for obscure mail relay +attacks with user@domain@domain addresses when Postfix provides +backup MX service for Sendmail systems.

    + +%PARAM resolve_null_domain no + +

    Resolve an address that ends in the "@" null domain as if the +local hostname were specified, instead of rejecting the address as +invalid.

    + +

    This feature is available in Postfix 2.1 and later. +Earlier versions always resolve the null domain as the local +hostname.

    + +

    The Postfix SMTP server uses this feature to reject mail from +or to addresses that end in the "@" null domain, and from addresses +that rewrite into a form that ends in the "@" null domain.

    + +%PARAM sender_bcc_maps + +

    Optional BCC (blind carbon-copy) address lookup tables, indexed +by sender address. The BCC address (multiple results are not +supported) is added when mail enters from outside of Postfix.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +The table search order is as follows: +

    + +
      + +
    • Look up the "user+extension@domain.tld" address including the +optional address extension. + +
    • Look up the "user@domain.tld" address without the optional +address extension. + +
    • Look up the "user+extension" address local part when the +sender domain equals $myorigin, $mydestination, $inet_interfaces +or $proxy_interfaces. + +
    • Look up the "user" address local part when the sender domain +equals $myorigin, $mydestination, $inet_interfaces or $proxy_interfaces. + +
    • Look up the "@domain.tld" part. + +
    + +

    +Note: with Postfix 2.3 and later the BCC address is added as if it +was specified with NOTIFY=NONE. The sender will not be notified +when the BCC address is undeliverable, as long as all down-stream +software implements RFC 3461. +

    + +

    +Note: with Postfix 2.2 and earlier the sender will be notified +when the BCC address is undeliverable. +

    + +

    Note: automatic BCC recipients are produced only for new mail. +To avoid mailer loops, automatic BCC recipients are not generated +after Postfix forwards mail internally, or after Postfix generates +mail itself.

    + +

    +Example: +

    + +
    +sender_bcc_maps = hash:/etc/postfix/sender_bcc
+
    + +

    +After a change, run "postmap /etc/postfix/sender_bcc". +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM sender_canonical_maps + +

    +Optional address mapping lookup tables for envelope and header +sender addresses. +The table format and lookups are documented in canonical(5). +

    + +

    +Example: you want to rewrite the SENDER address "user@ugly.domain" +to "user@pretty.domain", while still being able to send mail to +the RECIPIENT address "user@ugly.domain". +

    + +

    +Note: $sender_canonical_maps is processed before $canonical_maps. +

    + +

    +Example: +

    + +
    +sender_canonical_maps = hash:/etc/postfix/sender_canonical
+
    + +%PARAM smtp_always_send_ehlo yes + +

    +Always send EHLO at the start of an SMTP session. +

    + +

    +With "smtp_always_send_ehlo = no", the Postfix SMTP client sends +EHLO only when +the word "ESMTP" appears in the server greeting banner (example: +220 spike.porcupine.org ESMTP Postfix). +

    + +%PARAM smtp_bind_address + +

    +An optional numerical network address that the Postfix SMTP client +should bind to when making an IPv4 connection. +

    + +

    +This can be specified in the main.cf file for all SMTP clients, or +it can be specified in the master.cf file for a specific client, +for example: +

    + +
    +
    +/etc/postfix/master.cf:
+    smtp ... smtp -o smtp_bind_address=11.22.33.44
+
    +
    + +

    Note 1: when inet_interfaces specifies no more than one IPv4 +address, and that address is a non-loopback address, it is +automatically used as the smtp_bind_address. This supports virtual +IP hosting, but can be a problem on multi-homed firewalls. See the +inet_interfaces documentation for more detail.

    + +

    Note 2: address information may be enclosed inside [], +but this form is not required here.

    + +%PARAM smtp_bind_address6 + +

    +An optional numerical network address that the Postfix SMTP client +should bind to when making an IPv6 connection. +

    + +

    This feature is available in Postfix 2.2 and later.

    + +

    +This can be specified in the main.cf file for all SMTP clients, or +it can be specified in the master.cf file for a specific client, +for example: +

    + +
    +
    +/etc/postfix/master.cf:
+    smtp ... smtp -o smtp_bind_address6=1:2:3:4:5:6:7:8
+
    +
    + +

    Note 1: when inet_interfaces specifies no more than one IPv6 +address, and that address is a non-loopback address, it is +automatically used as the smtp_bind_address6. This supports virtual +IP hosting, but can be a problem on multi-homed firewalls. See the +inet_interfaces documentation for more detail.

    + +

    Note 2: address information may be enclosed inside [], +but this form is not recommended here.

    + +%PARAM smtp_connection_cache_time_limit 2s + +

    When SMTP connection caching is enabled, the amount of time that +an unused SMTP client socket is kept open before it is closed. Do +not specify larger values without permission from the remote sites. +

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_connection_reuse_time_limit 300s + +

    The amount of time during which Postfix will use an SMTP +connection repeatedly. The timer starts when the connection is +initiated (i.e. it includes the connect, greeting and helo latency, +in addition to the latencies of subsequent mail delivery transactions). +

    + +

    This feature addresses a performance stability problem with +remote SMTP servers. This problem is not specific to Postfix: it +can happen when any MTA sends large amounts of SMTP email to a site +that has multiple MX hosts.

    + +

    The problem starts when one of a set of MX hosts becomes slower +than the rest. Even though SMTP clients connect to fast and slow +MX hosts with equal probability, the slow MX host ends up with more +simultaneous inbound connections than the faster MX hosts, because +the slow MX host needs more time to serve each client request.

    + +

    The slow MX host becomes a connection attractor. If one MX +host becomes N times slower than the rest, it dominates mail delivery +latency unless there are more than N fast MX hosts to counter the +effect. And if the number of MX hosts is smaller than N, the mail +delivery latency becomes effectively that of the slowest MX host +divided by the total number of MX hosts.

    + +

    The solution uses connection caching in a way that differs from +Postfix version 2.2. By limiting the amount of time during which a connection +can be used repeatedly (instead of limiting the number of deliveries +over that connection), Postfix not only restores fairness in the +distribution of simultaneous connections across a set of MX hosts, +it also favors deliveries over connections that perform well, which +is exactly what we want.

    + +

    The default reuse time limit, 300s, is comparable to the various +smtp transaction timeouts which are fair estimates of maximum excess +latency for a slow delivery. Note that hosts may accept thousands +of messages over a single connection within the default connection +reuse time limit. This number is much larger than the default Postfix +version 2.2 limit of 10 messages per cached connection. It may prove necessary +to lower the limit to avoid interoperability issues with MTAs that +exhibit bugs when many messages are delivered via a single connection. +A lower reuse time limit risks losing the benefit of connection +reuse when the average connection and mail delivery latency exceeds +the reuse time limit.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_connection_cache_destinations + +

    Permanently enable SMTP connection caching for the specified +destinations. With SMTP connection caching, a connection is not +closed immediately after completion of a mail transaction. Instead, +the connection is kept open for up to $smtp_connection_cache_time_limit +seconds. This allows connections to be reused for other deliveries, +and can improve mail delivery performance.

    + +

    Specify a comma or white space separated list of destinations +or pseudo-destinations:

    + +
      + +
    • if mail is sent without a relay host: a domain name (the +right-hand side of an email address, without the [] around a numeric +IP address), + +
    • if mail is sent via a relay host: a relay host name (without +[] or non-default TCP port), as specified in main.cf or in the +transport map, + +
    • if mail is sent via a UNIX-domain socket: a pathname (without +the unix: prefix), + +
    • a /file/name with domain names and/or relay host names as +defined above, + +
    • a "type:table" with domain names and/or relay host names on +the left-hand side. The right-hand side result from "type:table" +lookups is ignored. + +
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_connection_cache_on_demand yes + +

    Temporarily enable SMTP connection caching while a destination +has a high volume of mail in the active queue. With SMTP connection +caching, a connection is not closed immediately after completion +of a mail transaction. Instead, the connection is kept open for +up to $smtp_connection_cache_time_limit seconds. This allows +connections to be reused for other deliveries, and can improve mail +delivery performance.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_connect_timeout 30s + +

    +The Postfix SMTP client time limit for completing a TCP connection, or +zero (use the operating system built-in time limit). +

    + +

    +When no connection can be made within the deadline, the Postfix +SMTP client +tries the next address on the mail exchanger list. Specify 0 to +disable the time limit (i.e. use whatever timeout is implemented by +the operating system). +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_data_done_timeout 600s + +

    +The Postfix SMTP client time limit for sending the SMTP ".", and +for receiving the remote SMTP server response. +

    + +

    +When no response is received within the deadline, a warning is +logged that the mail may be delivered multiple times. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_data_init_timeout 120s + +

    +The Postfix SMTP client time limit for sending the SMTP DATA command, +and for receiving the remote SMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_data_xfer_timeout 180s + +

    +The Postfix SMTP client time limit for sending the SMTP message content. +When the connection makes no progress for more than $smtp_data_xfer_timeout +seconds the Postfix SMTP client terminates the transfer. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_defer_if_no_mx_address_found no + +

    +Defer mail delivery when no MX record resolves to an IP address. +

    + +

    +The default (no) is to return the mail as undeliverable. With older +Postfix versions the default was to keep trying to deliver the mail +until someone fixed the MX record or until the mail was too old. +

    + +

    +Note: the Postfix SMTP client always ignores MX records with equal +or worse preference +than the local MTA itself. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM lmtp_destination_concurrency_limit $default_destination_concurrency_limit + +

    The maximal number of parallel deliveries to the same destination +via the lmtp message delivery transport. This limit is enforced by +the queue manager. The message delivery transport name is the first +field in the entry in the master.cf file.

    + +%PARAM lmtp_destination_recipient_limit $default_destination_recipient_limit + +

    The maximal number of recipients per message for the lmtp +message delivery transport. This limit is enforced by the queue +manager. The message delivery transport name is the first field in +the entry in the master.cf file.

    + +

    Setting this parameter to a value of 1 changes the meaning of +lmtp_destination_concurrency_limit from concurrency per domain into +concurrency per recipient.

    + +%PARAM relay_destination_concurrency_limit $default_destination_concurrency_limit + +

    The maximal number of parallel deliveries to the same destination +via the relay message delivery transport. This limit is enforced +by the queue manager. The message delivery transport name is the +first field in the entry in the master.cf file.

    + +

    This feature is available in Postfix 2.0 and later.

    + +%PARAM relay_destination_recipient_limit $default_destination_recipient_limit + +

    The maximal number of recipients per message for the relay +message delivery transport. This limit is enforced by the queue +manager. The message delivery transport name is the first field in +the entry in the master.cf file.

    + +

    Setting this parameter to a value of 1 changes the meaning of +relay_destination_concurrency_limit from concurrency per domain +into concurrency per recipient.

    + +

    This feature is available in Postfix 2.0 and later.

    + +%PARAM smtp_destination_concurrency_limit $default_destination_concurrency_limit + +

    The maximal number of parallel deliveries to the same destination +via the smtp message delivery transport. This limit is enforced by +the queue manager. The message delivery transport name is the first +field in the entry in the master.cf file.

    + +%PARAM smtp_destination_recipient_limit $default_destination_recipient_limit + +

    The maximal number of recipients per message for the smtp +message delivery transport. This limit is enforced by the queue +manager. The message delivery transport name is the first field in +the entry in the master.cf file.

    + +

    Setting this parameter to a value of 1 changes the meaning of +smtp_destination_concurrency_limit from concurrency per domain +into concurrency per recipient.

    + +%PARAM virtual_destination_concurrency_limit $default_destination_concurrency_limit + +

    The maximal number of parallel deliveries to the same destination +via the virtual message delivery transport. This limit is enforced +by the queue manager. The message delivery transport name is the +first field in the entry in the master.cf file.

    + +%PARAM virtual_destination_recipient_limit $default_destination_recipient_limit + +

    The maximal number of recipients per message for the virtual +message delivery transport. This limit is enforced by the queue +manager. The message delivery transport name is the first field in +the entry in the master.cf file.

    + +

    Setting this parameter to a value of 1 changes the meaning of +virtual_destination_concurrency_limit from concurrency per domain +into concurrency per recipient.

    + +%PARAM smtp_helo_name $myhostname + +

    +The hostname to send in the SMTP HELO or EHLO command. +

    + +

    +The default value is the machine hostname. Specify a hostname or +[ip.add.re.ss]. +

    + +

    +This information can be specified in the main.cf file for all SMTP +clients, or it can be specified in the master.cf file for a specific +client, for example: +

    + +
    +
    +/etc/postfix/master.cf:
+    mysmtp ... smtp -o smtp_helo_name=foo.bar.com
+
    +
    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM smtp_helo_timeout 300s + +

    +The Postfix SMTP client time limit for sending the HELO or EHLO command, +and for receiving the initial remote SMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_host_lookup dns + +

    +What mechanisms the Postfix SMTP client uses to look up a host's +IP address. This parameter is ignored when DNS lookups are disabled +(see: disable_dns_lookups and smtp_dns_support_level). The "dns" +mechanism is always tried before "native" if both are listed. +

    + +

    +Specify one of the following: +

    + +
    + +
    dns
    + +
    Hosts can be found in the DNS (preferred).
    + +
    native
    + +
    Use the native naming service only (nsswitch.conf, or equivalent +mechanism).
    + +
    dns, native
    + +
    Use the native service for hosts not found in the DNS.
    + +
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtp_line_length_limit 998 + +

    +The maximal length of message header and body lines that Postfix +will send via SMTP. This limit does not include the <CR><LF> +at the end of each line. Longer lines are broken by inserting +"<CR><LF><SPACE>", to minimize the damage to MIME +formatted mail. +

    + +

    +The Postfix limit of 998 characters not including <CR><LF> +is consistent with the SMTP limit of 1000 characters including +<CR><LF>. The Postfix limit was 990 with Postfix 2.8 +and earlier. +

    + +%PARAM smtp_mail_timeout 300s + +

    +The Postfix SMTP client time limit for sending the MAIL FROM command, +and for receiving the remote SMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_mx_address_limit 5 + +

    +The maximal number of MX (mail exchanger) IP addresses that can +result from Postfix SMTP client mail exchanger lookups, or zero (no +limit). Prior to +Postfix version 2.3, this limit was disabled by default. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtp_mx_session_limit 2 + +

    The maximal number of SMTP sessions per delivery request before +the Postfix SMTP client +gives up or delivers to a fall-back relay host, or zero (no +limit). This restriction ignores sessions that fail to complete the +SMTP initial handshake (Postfix version 2.2 and earlier) or that fail to +complete the EHLO and TLS handshake (Postfix version 2.3 and later).

    + +

    This feature is available in Postfix 2.1 and later.

    + +%PARAM smtp_never_send_ehlo no + +

    Never send EHLO at the start of an SMTP session. See also the +smtp_always_send_ehlo parameter.

    + +%PARAM smtp_pix_workaround_threshold_time 500s + +

    How long a message must be queued before the Postfix SMTP client +turns on the PIX firewall "<CR><LF>.<CR><LF>" +bug workaround for delivery through firewalls with "smtp fixup" +mode turned on.

    + +

    +By default, the workaround is turned off for mail that is queued +for less than 500 seconds. In other words, the workaround is normally +turned off for the first delivery attempt. +

    + +

    +Specify 0 to enable the PIX firewall +"<CR><LF>.<CR><LF>" bug workaround upon the +first delivery attempt. +

    + +%PARAM smtp_quit_timeout 300s + +

    +The Postfix SMTP client time limit for sending the QUIT command, +and for receiving the remote SMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_quote_rfc821_envelope yes + +

    +Quote addresses in Postfix SMTP client MAIL FROM and RCPT TO commands +as required +by RFC 5321. This includes putting quotes around an address localpart +that ends in ".". +

    + +

    +The default is to comply with RFC 5321. If you have to send mail to +a broken SMTP server, configure a special SMTP client in master.cf: +

    + +
    +
    +/etc/postfix/master.cf:
+    broken-smtp . . . smtp -o smtp_quote_rfc821_envelope=no
+
    +
    + +

    +and route mail for the destination in question to the "broken-smtp" +message delivery with a transport(5) table. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtp_rcpt_timeout 300s + +

    +The Postfix SMTP client time limit for sending the SMTP RCPT TO +command, and for receiving the remote SMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM smtp_sasl_auth_enable no + +

    +Enable SASL authentication in the Postfix SMTP client. By default, +the Postfix SMTP client uses no authentication. +

    + +

    +Example: +

    + +
    +smtp_sasl_auth_enable = yes
+
    + +%PARAM smtp_sasl_password_maps + +

    +Optional Postfix SMTP client lookup tables with one username:password +entry per sender, remote hostname or next-hop domain. Per-sender +lookup is done only when sender-dependent authentication is enabled. +If no username:password entry is found, then the Postfix SMTP client +will not attempt to authenticate to the remote host. +

    + +

    +The Postfix SMTP client opens the lookup table before going to +chroot jail, so you can leave the password file in /etc/postfix. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +%PARAM smtp_sasl_security_options noplaintext, noanonymous + +

    Postfix SMTP client SASL security options; as of Postfix 2.3 +the list of available +features depends on the SASL client implementation that is selected +with smtp_sasl_type.

    + +

    The following security features are defined for the cyrus +client SASL implementation:

    + +

    +Specify zero or more of the following: +

    + +
    + +
    noplaintext
    + +
    Disallow methods that use plaintext passwords.
    + +
    noactive
    + +
    Disallow methods subject to active (non-dictionary) attack. +
    + +
    nodictionary
    + +
    Disallow methods subject to passive (dictionary) attack.
    + +
    noanonymous
    + +
    Disallow methods that allow anonymous authentication.
    + +
    mutual_auth
    + +
    Only allow methods that provide mutual authentication (not +available with SASL version 1).
    + +
    + +

    +Example: +

    + +
    +smtp_sasl_security_options = noplaintext
+
    + +%PARAM smtp_sasl_mechanism_filter + +

    +If non-empty, a Postfix SMTP client filter for the remote SMTP +server's list of offered SASL mechanisms. Different client and +server implementations may support different mechanism lists; by +default, the Postfix SMTP client will use the intersection of the +two. smtp_sasl_mechanism_filter specifies an optional third mechanism +list to intersect with.

    + +

    Specify mechanism names, "/file/name" patterns or "type:table" +lookup tables. The right-hand side result from "type:table" lookups +is ignored. Specify "!pattern" to exclude a mechanism name from the +list. The form "!/file/name" is supported only in Postfix version +2.4 and later.

    + +

    This feature is available in Postfix 2.2 and later.

    + +

    +Examples: +

    + +
    +smtp_sasl_mechanism_filter = plain, login
+smtp_sasl_mechanism_filter = /etc/postfix/smtp_mechs
+smtp_sasl_mechanism_filter = !gssapi, !login, static:rest
+
    + +%PARAM smtp_send_xforward_command no + +

    +Send the non-standard XFORWARD command when the Postfix SMTP server +EHLO response announces XFORWARD support. +

    + +

    +This allows a Postfix SMTP delivery agent, used for injecting mail +into +a content filter, to forward the name, address, protocol and HELO +name of the original client to the content filter and downstream +queuing SMTP server. This can produce more useful logging than +localhost[127.0.0.1] etc. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtp_skip_4xx_greeting yes + +

    +Skip SMTP servers that greet with a 4XX status code (go away, try +again later). +

    + +

    +By default, the Postfix SMTP client moves on the next mail exchanger. +Specify +"smtp_skip_4xx_greeting = no" if Postfix should defer delivery +immediately. +

    + +

    This feature is available in Postfix 2.0 and earlier. +Later Postfix versions always skip remote SMTP servers that greet +with a +4XX status code.

    + +%PARAM smtp_skip_5xx_greeting yes + +

    +Skip remote SMTP servers that greet with a 5XX status code. +

    + +

    By default, the Postfix SMTP client moves on the next mail +exchanger. Specify "smtp_skip_5xx_greeting = no" if Postfix should +bounce the mail immediately. Caution: the latter behavior appears +to contradict RFC 2821.

    + +%PARAM smtp_skip_quit_response yes + +

    +Do not wait for the response to the SMTP QUIT command. +

    + +%PARAM smtp_xforward_timeout 300s + +

    +The Postfix SMTP client time limit for sending the XFORWARD command, +and for receiving the remote SMTP server response. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM authorized_verp_clients $mynetworks + +

    What remote SMTP clients are allowed to specify the XVERP command. +This command requests that mail be delivered one recipient at a +time with a per recipient return address.

    + +

    By default, only trusted clients are allowed to specify XVERP. +

    + +

    This parameter was introduced with Postfix version 1.1. Postfix +version 2.1 renamed this parameter to smtpd_authorized_verp_clients +and changed the default to none.

    + +

    Specify a list of network/netmask patterns, separated by commas +and/or whitespace. The mask specifies the number of bits in the +network part of a host address. You can also specify hostnames or +.domain names (the initial dot causes the domain to match any name +below it), "/file/name" or "type:table" patterns. A "/file/name" +pattern is replaced by its contents; a "type:table" lookup table +is matched when a table entry matches a lookup string (the lookup +result is ignored). Continue long lines by starting the next line +with whitespace. Specify "!pattern" to exclude an address or network +block from the list. The form "!/file/name" is supported only in +Postfix version 2.4 and later.

    + +

    Note: IP version 6 address information must be specified inside +[] in the authorized_verp_clients value, and in files +specified with "/file/name". IP version 6 addresses contain the +":" character, and would otherwise be confused with a "type:table" +pattern.

    + +%PARAM smtpd_authorized_verp_clients $authorized_verp_clients + +

    What remote SMTP clients are allowed to specify the XVERP command. +This command requests that mail be delivered one recipient at a +time with a per recipient return address.

    + +

    By default, no clients are allowed to specify XVERP.

    + +

    This parameter was renamed with Postfix version 2.1. The default value +is backwards compatible with Postfix version 2.0.

    + +

    Specify a list of network/netmask patterns, separated by commas +and/or whitespace. The mask specifies the number of bits in the +network part of a host address. You can also specify hostnames or +.domain names (the initial dot causes the domain to match any name +below it), "/file/name" or "type:table" patterns. A "/file/name" +pattern is replaced by its contents; a "type:table" lookup table +is matched when a table entry matches a lookup string (the lookup +result is ignored). Continue long lines by starting the next line +with whitespace. Specify "!pattern" to exclude an address or network +block from the list. The form "!/file/name" is supported only in +Postfix version 2.4 and later.

    + +

    Note: IP version 6 address information must be specified inside +[] in the smtpd_authorized_verp_clients value, and in +files specified with "/file/name". IP version 6 addresses contain +the ":" character, and would otherwise be confused with a "type:table" +pattern.

    + +%PARAM smtpd_authorized_xclient_hosts + +

    +What remote SMTP clients are allowed to use the XCLIENT feature. This +command overrides remote SMTP client information that is used for access +control. Typical use is for SMTP-based content filters, fetchmail-like +programs, or SMTP server access rule testing. See the XCLIENT_README +document for details. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +

    +By default, no clients are allowed to specify XCLIENT. +

    + +

    +Specify a list of network/netmask patterns, separated by commas +and/or whitespace. The mask specifies the number of bits in the +network part of a host address. You can also specify hostnames or +.domain names (the initial dot causes the domain to match any name +below it), "/file/name" or "type:table" patterns. A "/file/name" +pattern is replaced by its contents; a "type:table" lookup table +is matched when a table entry matches a lookup string (the lookup +result is ignored). Continue long lines by starting the next line +with whitespace. Specify "!pattern" to exclude an address or network +block from the list. The form "!/file/name" is supported only in +Postfix version 2.4 and later.

    + +

    Note: IP version 6 address information must be specified inside +[] in the smtpd_authorized_xclient_hosts value, and in +files specified with "/file/name". IP version 6 addresses contain +the ":" character, and would otherwise be confused with a "type:table" +pattern.

    + +%PARAM smtpd_authorized_xforward_hosts + +

    +What remote SMTP clients are allowed to use the XFORWARD feature. This +command forwards information that is used to improve logging after +SMTP-based content filters. See the XFORWARD_README document for +details. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +

    +By default, no clients are allowed to specify XFORWARD. +

    + +

    +Specify a list of network/netmask patterns, separated by commas +and/or whitespace. The mask specifies the number of bits in the +network part of a host address. You can also specify hostnames or +.domain names (the initial dot causes the domain to match any name +below it), "/file/name" or "type:table" patterns. A "/file/name" +pattern is replaced by its contents; a "type:table" lookup table +is matched when a table entry matches a lookup string (the lookup +result is ignored). Continue long lines by starting the next line +with whitespace. Specify "!pattern" to exclude an address or network +block from the list. The form "!/file/name" is supported only in +Postfix version 2.4 and later.

    + +

    Note: IP version 6 address information must be specified inside +[] in the smtpd_authorized_xforward_hosts value, and in +files specified with "/file/name". IP version 6 addresses contain +the ":" character, and would otherwise be confused with a "type:table" +pattern.

    + +%PARAM smtpd_banner $myhostname ESMTP $mail_name + +

    +The text that follows the 220 status code in the SMTP greeting +banner. Some people like to see the mail version advertised. By +default, Postfix shows no version. +

    + +

    +You MUST specify $myhostname at the start of the text. This is +required by the SMTP protocol. +

    + +

    +Example: +

    + +
    +smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
+
    + +%PARAM smtpd_client_connection_count_limit 50 + +

    +How many simultaneous connections any client is allowed to +make to this service. By default, the limit is set to half +the default process limit value. +

    + +

    +To disable this feature, specify a limit of 0. +

    + +

    +WARNING: The purpose of this feature is to limit abuse. It must +not be used to regulate legitimate mail traffic. +

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +%PARAM smtpd_client_event_limit_exceptions $mynetworks + +

    +Clients that are excluded from smtpd_client_*_count/rate_limit +restrictions. See the mynetworks parameter +description for the parameter value syntax. +

    + +

    +By default, clients in trusted networks are excluded. Specify a +list of network blocks, hostnames or .domain names (the initial +dot causes the domain to match any name below it). +

    + +

    Note: IP version 6 address information must be specified inside +[] in the smtpd_client_event_limit_exceptions value, and +in files specified with "/file/name". IP version 6 addresses +contain the ":" character, and would otherwise be confused with a +"type:table" pattern.

    + +

    Pattern matching of domain names is controlled by the presence +or absence of "smtpd_client_event_limit_exceptions" in the +parent_domain_matches_subdomains parameter value (postfix 3.0 and +later).

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +%PARAM smtpd_client_connection_rate_limit 0 + +

    +The maximal number of connection attempts any client is allowed to +make to this service per time unit. The time unit is specified +with the anvil_rate_time_unit configuration parameter. +

    + +

    +By default, a client can make as many connections per time unit as +Postfix can accept. +

    + +

    +To disable this feature, specify a limit of 0. +

    + +

    +WARNING: The purpose of this feature is to limit abuse. It must +not be used to regulate legitimate mail traffic. +

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +

    +Example: +

    + +
    +smtpd_client_connection_rate_limit = 1000
+
    + +%PARAM smtpd_client_message_rate_limit 0 + +

    +The maximal number of message delivery requests that any client is +allowed to make to this service per time unit, regardless of whether +or not Postfix actually accepts those messages. The time unit is +specified with the anvil_rate_time_unit configuration parameter. +

    + +

    +By default, a client can send as many message delivery requests +per time unit as Postfix can accept. +

    + +

    +To disable this feature, specify a limit of 0. +

    + +

    +WARNING: The purpose of this feature is to limit abuse. It must +not be used to regulate legitimate mail traffic. +

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +

    +Example: +

    + +
    +smtpd_client_message_rate_limit = 1000
+
    + +%PARAM smtpd_client_recipient_rate_limit 0 + +

    +The maximal number of recipient addresses that any client is allowed +to send to this service per time unit, regardless of whether or not +Postfix actually accepts those recipients. The time unit is specified +with the anvil_rate_time_unit configuration parameter. +

    + +

    +By default, a client can send as many recipient addresses per time +unit as Postfix can accept. +

    + +

    +To disable this feature, specify a limit of 0. +

    + +

    +WARNING: The purpose of this feature is to limit abuse. It must +not be used to regulate legitimate mail traffic. +

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +

    +Example: +

    + +
    +smtpd_client_recipient_rate_limit = 1000
+
    + +%PARAM smtpd_client_new_tls_session_rate_limit 0 + +

    +The maximal number of new (i.e., uncached) TLS sessions that a +remote SMTP client is allowed to negotiate with this service per +time unit. The time unit is specified with the anvil_rate_time_unit +configuration parameter. +

    + +

    +By default, a remote SMTP client can negotiate as many new TLS +sessions per time unit as Postfix can accept. +

    + +

    +To disable this feature, specify a limit of 0. Otherwise, specify +a limit that is at least the per-client concurrent session limit, +or else legitimate client sessions may be rejected. +

    + +

    +WARNING: The purpose of this feature is to limit abuse. It must +not be used to regulate legitimate mail traffic. +

    + +

    +This feature is available in Postfix 2.3 and later. +

    + +

    +Example: +

    + +
    +smtpd_client_new_tls_session_rate_limit = 100
+
    + +%PARAM smtpd_client_auth_rate_limit 0 + +

    +The maximal number of AUTH commands that any client is allowed to +send to this service per time unit, regardless of whether or not +Postfix actually accepts those commands. The time unit is specified +with the anvil_rate_time_unit configuration parameter. +

    + +

    +By default, there is no limit on the number AUTH commands that a +client may send. +

    + +

    +To disable this feature, specify a limit of 0. +

    + +

    +WARNING: The purpose of this feature is to limit abuse. It must +not be used to regulate legitimate mail traffic. +

    + +

    +This feature is available in Postfix 3.1 and later. +

    + +%PARAM smtpd_client_restrictions + +

    +Optional restrictions that the Postfix SMTP server applies in the +context of a client connection request. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    +The default is to allow all connection requests. +

    + +

    +Specify a list of restrictions, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. +Restrictions are applied in the order as specified; the first +restriction that matches wins. +

    + +

    +The following restrictions are specific to client hostname or +client network address information. +

    + +
    + +
    check_ccert_access type:table
    + +
    Use the remote SMTP client certificate fingerprint or the public key +fingerprint (Postfix 2.9 and later) as lookup key for the specified +access(5) database; with Postfix version 2.2, also require that the +remote SMTP client certificate is verified successfully. +The fingerprint digest algorithm is configurable via the +smtpd_tls_fingerprint_digest parameter (hard-coded as md5 prior to +Postfix version 2.5). This feature is available with Postfix version +2.2 and later.
    + +
    check_client_access type:table
    + +
    Search the specified access database for the client hostname, +parent domains, client IP address, or networks obtained by stripping +least significant octets. See the access(5) manual page for details.
    + +
    check_client_a_access type:table
    + +
    Search the specified access(5) database for the IP addresses for the +client hostname, and execute the corresponding action. Note: a result +of "OK" is not allowed for safety reasons. Instead, use DUNNO in order +to exclude specific hosts from blacklists. This feature is available +in Postfix 3.0 and later.
    + +
    check_client_mx_access type:table
    + +
    Search the specified access(5) database for the MX hosts for the +client hostname, and execute the corresponding action. Note: a result +of "OK" is not allowed for safety reasons. Instead, use DUNNO in order +to exclude specific hosts from blacklists. This feature is available +in Postfix 2.7 and later.
    + +
    check_client_ns_access type:table
    + +
    Search the specified access(5) database for the DNS servers for +the client hostname, and execute the corresponding action. Note: a +result of "OK" is not allowed for safety reasons. Instead, use DUNNO +in order to exclude specific hosts from blacklists. This feature is +available in Postfix 2.7 and later.
    + +
    check_reverse_client_hostname_access type:table
    + +
    Search the specified access database for the unverified reverse +client hostname, parent domains, client IP address, or networks +obtained by stripping least significant octets. See the access(5) +manual page for details. Note: a result of "OK" is not allowed for +safety reasons. Instead, use DUNNO in order to exclude specific +hosts from blacklists. This feature is available in Postfix 2.6 +and later.
    + +
    check_reverse_client_hostname_a_access type:table
    + +
    Search the specified access(5) database for the IP addresses for the +unverified reverse client hostname, and execute the corresponding +action. Note: a result of "OK" is not allowed for safety reasons. +Instead, use DUNNO in order to exclude specific hosts from blacklists. +This feature is available in Postfix 3.0 and later.
    + +
    check_reverse_client_hostname_mx_access type:table
    + +
    Search the specified access(5) database for the MX hosts for the +unverified reverse client hostname, and execute the corresponding +action. Note: a result of "OK" is not allowed for safety reasons. +Instead, use DUNNO in order to exclude specific hosts from blacklists. +This feature is available in Postfix 2.7 and later.
    + +
    check_reverse_client_hostname_ns_access type:table
    + +
    Search the specified access(5) database for the DNS servers for +the unverified reverse client hostname, and execute the corresponding +action. Note: a result of "OK" is not allowed for safety reasons. +Instead, use DUNNO in order to exclude specific hosts from blacklists. +This feature is available in Postfix 2.7 and later.
    + +
    check_sasl_access type:table
    + +
    Use the remote SMTP client SASL user name as lookup key for +the specified access(5) database. The lookup key has the form +"username@domainname" when the smtpd_sasl_local_domain parameter +value is non-empty. Unlike the check_client_access feature, +check_sasl_access does not perform matches of parent domains or IP +subnet ranges. This feature is available with Postfix version 2.11 +and later.
    + +
    permit_inet_interfaces
    + +
    Permit the request when the client IP address matches +$inet_interfaces.
    + +
    permit_mynetworks
    + +
    Permit the request when the client IP address matches any +network or network address listed in $mynetworks.
    + +
    permit_sasl_authenticated
    + +
    Permit the request when the client is successfully +authenticated via the RFC 4954 (AUTH) protocol.
    + + +
    permit_tls_all_clientcerts
    + +
    Permit the request when the remote SMTP client certificate is +verified successfully. This option must be used only if a special +CA issues the certificates and only this CA is listed as trusted +CA. Otherwise, clients with a third-party certificate would also +be allowed to relay. Specify "tls_append_default_CA = no" when the +trusted CA is specified with smtpd_tls_CAfile or smtpd_tls_CApath, +to prevent Postfix from appending the system-supplied default CAs. +This feature is available with Postfix version 2.2.
    + +
    permit_tls_clientcerts
    + +
    Permit the request when the remote SMTP client certificate +fingerprint or public key fingerprint (Postfix 2.9 and later) is +listed in $relay_clientcerts. +The fingerprint digest algorithm is configurable via the +smtpd_tls_fingerprint_digest parameter (hard-coded as md5 prior to +Postfix version 2.5). This feature is available with Postfix version +2.2.
    + +
    reject_rbl_client rbl_domain=d.d.d.d
    + +
    Reject the request when the reversed client network address is +listed with the A record "d.d.d.d" under rbl_domain +(Postfix version 2.1 and later only). Each "d" is a number, +or a pattern inside "[]" that contains one or more ";"-separated +numbers or number..number ranges (Postfix version 2.8 and later). +If no "=d.d.d.d" is specified, reject the request when the +reversed client network address is listed with any A record under +rbl_domain.
    +The maps_rbl_reject_code parameter specifies the response code for +rejected requests (default: 554), the default_rbl_reply parameter +specifies the default server reply, and the rbl_reply_maps parameter +specifies tables with server replies indexed by rbl_domain. +This feature is available in Postfix 2.0 and later.
    + +
    permit_dnswl_client dnswl_domain=d.d.d.d
    + +
    Accept the request when the reversed client network address is +listed with the A record "d.d.d.d" under dnswl_domain. +Each "d" is a number, or a pattern inside "[]" that contains +one or more ";"-separated numbers or number..number ranges. +If no "=d.d.d.d" is specified, accept the request when the +reversed client network address is listed with any A record under +dnswl_domain.
    For safety, permit_dnswl_client is silently +ignored when it would override reject_unauth_destination. The +result is DEFER_IF_REJECT when whitelist lookup fails. This feature +is available in Postfix 2.8 and later.
    + +
    reject_rhsbl_client rbl_domain=d.d.d.d
    + +
    Reject the request when the client hostname is listed with the +A record "d.d.d.d" under rbl_domain (Postfix version +2.1 and later only). Each "d" is a number, or a pattern +inside "[]" that contains one or more ";"-separated numbers or +number..number ranges (Postfix version 2.8 and later). If no +"=d.d.d.d" is specified, reject the request when the client +hostname is listed with +any A record under rbl_domain. See the reject_rbl_client +description above for additional RBL related configuration parameters. +This feature is available in Postfix 2.0 and later; with Postfix +version 2.8 and later, reject_rhsbl_reverse_client will usually +produce better results.
    + +
    permit_rhswl_client rhswl_domain=d.d.d.d
    + +
    Accept the request when the client hostname is listed with the +A record "d.d.d.d" under rhswl_domain. Each "d" +is a number, or a pattern inside "[]" that contains one or more +";"-separated numbers or number..number ranges. If no +"=d.d.d.d" is specified, accept the request when the client +hostname is listed with any A record under rhswl_domain. +
    Caution: client name whitelisting is fragile, since the client +name lookup can fail due to temporary outages. Client name +whitelisting should be used only to reduce false positives in e.g. +DNS-based blocklists, and not for making access rule exceptions. +
    For safety, permit_rhswl_client is silently ignored when it +would override reject_unauth_destination. The result is DEFER_IF_REJECT +when whitelist lookup fails. This feature is available in Postfix +2.8 and later.
    + +
    reject_rhsbl_reverse_client rbl_domain=d.d.d.d
    + +
    Reject the request when the unverified reverse client hostname +is listed with the A record "d.d.d.d" under rbl_domain. +Each "d" is a number, or a pattern inside "[]" that contains +one or more ";"-separated numbers or number..number ranges. +If no "=d.d.d.d" is specified, reject the request when the +unverified reverse client hostname is listed with any A record under +rbl_domain. See the reject_rbl_client description above for +additional RBL related configuration parameters. This feature is +available in Postfix 2.8 and later.
    + +
    reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client)
    + +
    Reject the request when 1) the client IP address->name mapping +fails, or 2) the name->address mapping fails, or 3) the name->address +mapping does not match the client IP address.
    This is a +stronger restriction than the reject_unknown_reverse_client_hostname +feature, which triggers only under condition 1) above.
    The +unknown_client_reject_code parameter specifies the response code +for rejected requests (default: 450). The reply is always 450 in +case the address->name or name->address lookup failed due to +a temporary problem.
    + +
    reject_unknown_reverse_client_hostname
    + +
    Reject the request when the client IP address has no address->name +mapping.
    This is a weaker restriction than the +reject_unknown_client_hostname feature, which requires not only +that the address->name and name->address mappings exist, but +also that the two mappings reproduce the client IP address.
    +The unknown_client_reject_code parameter specifies the response +code for rejected requests (default: 450). The reply is always 450 +in case the address->name lookup failed due to a temporary +problem.
    This feature is available in Postfix 2.3 and +later.
    + +#
    reject_unknown_forward_client_hostname
    +# +#
    Reject the request when the client IP address has no address->name +#or name ->address mapping.
    This is a weaker restriction +#than the reject_unknown_client_hostname feature, which requires not +#only that the address->name and name->address mappings exist, +#but also that the two mappings reproduce the client IP address. +#
    The unknown_client_reject_code parameter specifies the response +#code for rejected requests (default: 450). The reply is always 450 +#in case the address->name or name ->address lookup failed due +#to a temporary problem.
    This feature is available in Postfix +#version 2.3 and later.
    + +
    + +

    +In addition, you can use any of the following +generic restrictions. These restrictions are applicable in +any SMTP command context. +

    + +
    + +
    check_policy_service servername
    + +
    Query the specified policy server. See the SMTPD_POLICY_README +document for details. This feature is available in Postfix 2.1 +and later.
    + +
    defer
    + +
    Defer the request. The client is told to try again later. This +restriction is useful at the end of a restriction list, to make +the default policy explicit.
    The defer_code parameter specifies +the SMTP server reply code (default: 450).
    + +
    defer_if_permit
    + +
    Defer the request if some later restriction would result in an +explicit or implicit PERMIT action. This is useful when a blacklisting +feature fails due to a temporary problem. This feature is available +in Postfix version 2.1 and later.
    + +
    defer_if_reject
    + +
    Defer the request if some later restriction would result in a +REJECT action. This is useful when a whitelisting feature fails +due to a temporary problem. This feature is available in Postfix +version 2.1 and later.
    + +
    permit
    + +
    Permit the request. This restriction is useful at the end of +a restriction list, to make the default policy explicit.
    + +
    reject_multi_recipient_bounce
    + +
    Reject the request when the envelope sender is the null address, +and the message has multiple envelope recipients. This usage has +rare but legitimate applications: under certain conditions, +multi-recipient mail that was posted with the DSN option NOTIFY=NEVER +may be forwarded with the null sender address. +
    Note: this restriction can only work reliably +when used in smtpd_data_restrictions or +smtpd_end_of_data_restrictions, because the total number of +recipients is not known at an earlier stage of the SMTP conversation. +Use at the RCPT stage will only reject the second etc. recipient. +
    +The multi_recipient_bounce_reject_code parameter specifies the +response code for rejected requests (default: 550). This feature +is available in Postfix 2.1 and later.
    + +
    reject_plaintext_session
    + +
    Reject the request when the connection is not encrypted. This +restriction should not be used before the client has had a chance +to negotiate encryption with the AUTH or STARTTLS commands. +
    +The plaintext_reject_code parameter specifies the response +code for rejected requests (default: 450). This feature is available +in Postfix 2.3 and later.
    + +
    reject_unauth_pipelining
    + +
    Reject the request when the client sends SMTP commands ahead +of time where it is not allowed, or when the client sends SMTP +commands ahead of time without knowing that Postfix actually supports +ESMTP command pipelining. This stops mail from bulk mail software +that improperly uses ESMTP command pipelining in order to speed up +deliveries. +
    With Postfix 2.6 and later, the SMTP server sets a per-session +flag whenever it detects illegal pipelining, including pipelined +HELO or EHLO commands. The reject_unauth_pipelining feature simply +tests whether the flag was set at any point in time during the +session. +
    With older Postfix versions, reject_unauth_pipelining checks +the current status of the input read queue, and its usage is not +recommended in contexts other than smtpd_data_restrictions.
    + +
    reject
    + +
    Reject the request. This restriction is useful at the end of +a restriction list, to make the default policy explicit. The +reject_code configuration parameter specifies the response code for +rejected requests (default: 554).
    + +
    sleep seconds
    + +
    Pause for the specified number of seconds and proceed with +the next restriction in the list, if any. This may stop zombie +mail when used as: +
    +/etc/postfix/main.cf:
+    smtpd_client_restrictions = 
+        sleep 1, reject_unauth_pipelining
+    smtpd_delay_reject = no
+
    +This feature is available in Postfix 2.3.
    + +
    warn_if_reject
    + +
    A safety net for testing. When "warn_if_reject" is placed +before a reject-type restriction, access table query, or +check_policy_service query, this logs a "reject_warning" message +instead of rejecting a request (when a reject-type restriction fails +due to a temporary error, this logs a "reject_warning" message for +any implicit "defer_if_permit" actions that would normally prevent +mail from being accepted by some later access restriction). This +feature has no effect on defer_if_reject restrictions.
    + +
    + +

    +Other restrictions that are valid in this context: +

    + +
      + +
    • SMTP command specific restrictions that are described under +the smtpd_helo_restrictions, smtpd_sender_restrictions or +smtpd_recipient_restrictions parameters. When helo, sender or +recipient restrictions are listed under smtpd_client_restrictions, +they have effect only with "smtpd_delay_reject = yes", so that +$smtpd_client_restrictions is evaluated at the time of the RCPT TO +command. + +
    + +

    +Example: +

    + +
    +smtpd_client_restrictions = permit_mynetworks, reject_unknown_client_hostname
+
    + +%CLASS smtpd-tarpit Tarpit features + +

    +When a remote SMTP client makes errors, the Postfix SMTP server +can insert delays before responding. This can help to slow down +run-away software. The behavior is controlled by an error counter +that counts the number of errors within an SMTP session that a +client makes without delivering mail. +

    + +
      + +

    • When the error counter is less than $smtpd_soft_error_limit the +Postfix SMTP server replies immediately (Postfix version 2.0 and earlier +delay their 4xx or 5xx error response).

      + +

    • When the error counter reaches $smtpd_soft_error_limit, the Postfix +SMTP server delays all its responses.

      + +

    • When the error counter reaches $smtpd_hard_error_limit the Postfix +SMTP server breaks the connection.

      + +
    + +%PARAM smtpd_error_sleep_time 1s + +

    With Postfix version 2.1 and later: the SMTP server response delay after +a client has made more than $smtpd_soft_error_limit errors, and +fewer than $smtpd_hard_error_limit errors, without delivering mail. +

    + +

    With Postfix version 2.0 and earlier: the SMTP server delay before +sending a reject (4xx or 5xx) response, when the client has made +fewer than $smtpd_soft_error_limit errors without delivering +mail.

    + +%PARAM smtpd_soft_error_limit 10 + +

    +The number of errors a remote SMTP client is allowed to make without +delivering mail before the Postfix SMTP server slows down all its +responses. +

    + +
      + +

    • With Postfix version 2.1 and later, the Postfix SMTP server +delays all responses by $smtpd_error_sleep_time seconds.

      + +

    • With Postfix versions 2.0 and earlier, the Postfix SMTP +server delays all responses by (number of errors) seconds.

      + +
    + +%PARAM smtpd_hard_error_limit normal: 20, overload: 1 + +

    +The maximal number of errors a remote SMTP client is allowed to +make without delivering mail. The Postfix SMTP server disconnects +when the limit is exceeded. Normally the default limit is 20, but +it changes under overload to just 1. With Postfix 2.5 and earlier, +the SMTP server always allows up to 20 errors by default. + +

    + +%PARAM smtpd_junk_command_limit normal: 100, overload: 1 + +

    +The number of junk commands (NOOP, VRFY, ETRN or RSET) that a remote +SMTP client can send before the Postfix SMTP server starts to +increment the error counter with each junk command. The junk +command count is reset after mail is delivered. See also the +smtpd_error_sleep_time and smtpd_soft_error_limit configuration +parameters. Normally the default limit is 100, but it changes under +overload to just 1. With Postfix 2.5 and earlier, the SMTP server +always allows up to 100 junk commands by default.

    + +%PARAM smtpd_recipient_overshoot_limit 1000 + +

    The number of recipients that a remote SMTP client can send in +excess of the limit specified with $smtpd_recipient_limit, before +the Postfix SMTP server increments the per-session error count +for each excess recipient.

    + +%PARAM smtpd_etrn_restrictions + +

    +Optional restrictions that the Postfix SMTP server applies in the +context of a client ETRN command. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    +The Postfix ETRN implementation accepts only destinations that are +eligible for the Postfix "fast flush" service. See the ETRN_README +file for details. +

    + +

    +Specify a list of restrictions, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. +Restrictions are applied in the order as specified; the first +restriction that matches wins. +

    + +

    +The following restrictions are specific to the domain name information +received with the ETRN command. +

    + +
    + +
    check_etrn_access type:table
    + +
    Search the specified access database for the ETRN domain name +or its parent domains. See the access(5) manual page for details. +
    + +
    + +

    +Other restrictions that are valid in this context: +

    + +
      + +
    • Generic restrictions that can be used +in any SMTP command context, described under smtpd_client_restrictions. + +
    • SMTP command specific restrictions described under +smtpd_client_restrictions and smtpd_helo_restrictions. + +
    + +

    +Example: +

    + +
    +smtpd_etrn_restrictions = permit_mynetworks, reject
+
    + +%PARAM smtpd_expansion_filter see "postconf -d" output + +

    +What characters are allowed in $name expansions of RBL reply +templates. Characters not in the allowed set are replaced by "_". +Use C like escapes to specify special characters such as whitespace. +

    + +

    +The smtpd_expansion_filter value is not subject to Postfix configuration +parameter $name expansion. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM smtpd_forbidden_commands CONNECT, GET, POST + +

    +List of commands that cause the Postfix SMTP server to immediately +terminate the session with a 221 code. This can be used to disconnect +clients that obviously attempt to abuse the system. In addition to the +commands listed in this parameter, commands that follow the "Label:" +format of message headers will also cause a disconnect. +

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +%PARAM smtpd_helo_required no + +

    +Require that a remote SMTP client introduces itself with the HELO +or EHLO command before sending the MAIL command or other commands +that require EHLO negotiation. +

    + +

    +Example: +

    + +
    +smtpd_helo_required = yes
+
    + +%PARAM smtpd_helo_restrictions + +

    +Optional restrictions that the Postfix SMTP server applies in the +context of a client HELO command. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    +The default is to permit everything. +

    + +

    Note: specify "smtpd_helo_required = yes" to fully enforce this +restriction (without "smtpd_helo_required = yes", a client can +simply skip smtpd_helo_restrictions by not sending HELO or EHLO). +

    + +

    +Specify a list of restrictions, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. +Restrictions are applied in the order as specified; the first +restriction that matches wins. +

    + +

    +The following restrictions are specific to the hostname information +received with the HELO or EHLO command. +

    + +
    + +
    check_helo_access type:table
    + +
    Search the specified access(5) database for the HELO or EHLO +hostname or parent domains, and execute the corresponding action. +Note: specify "smtpd_helo_required = yes" to fully enforce this +restriction (without "smtpd_helo_required = yes", a client can +simply skip check_helo_access by not sending HELO or EHLO).
    + +
    check_helo_a_access type:table
    + +
    Search the specified access(5) database for the IP addresses for +the HELO or EHLO hostname, and execute the corresponding action. +Note 1: a result of "OK" is not allowed for safety reasons. Instead, +use DUNNO in order to exclude specific hosts from blacklists. Note +2: specify "smtpd_helo_required = yes" to fully enforce this +restriction (without "smtpd_helo_required = yes", a client can +simply skip check_helo_a_access by not sending HELO or EHLO). This +feature is available in Postfix 3.0 and later. +
    + +
    check_helo_mx_access type:table
    + +
    Search the specified access(5) database for the MX hosts for +the HELO or EHLO hostname, and execute the corresponding action. +Note 1: a result of "OK" is not allowed for safety reasons. Instead, +use DUNNO in order to exclude specific hosts from blacklists. Note +2: specify "smtpd_helo_required = yes" to fully enforce this +restriction (without "smtpd_helo_required = yes", a client can +simply skip check_helo_mx_access by not sending HELO or EHLO). This +feature is available in Postfix 2.1 and later. +
    + +
    check_helo_ns_access type:table
    + +
    Search the specified access(5) database for the DNS servers +for the HELO or EHLO hostname, and execute the corresponding action. +Note 1: a result of "OK" is not allowed for safety reasons. Instead, +use DUNNO in order to exclude specific hosts from blacklists. Note +2: specify "smtpd_helo_required = yes" to fully enforce this +restriction (without "smtpd_helo_required = yes", a client can +simply skip check_helo_ns_access by not sending HELO or EHLO). This +feature is available in Postfix 2.1 and later. +
    + +
    reject_invalid_helo_hostname (with Postfix < 2.3: reject_invalid_hostname)
    + +
    Reject the request when the HELO or EHLO hostname is malformed. +Note: specify "smtpd_helo_required = yes" to fully enforce +this restriction (without "smtpd_helo_required = yes", a client can simply +skip reject_invalid_helo_hostname by not sending HELO or EHLO). +
    The invalid_hostname_reject_code specifies the response code +for rejected requests (default: 501).
    + +
    reject_non_fqdn_helo_hostname (with Postfix < 2.3: reject_non_fqdn_hostname)
    + +
    Reject the request when the HELO or EHLO hostname is not in +fully-qualified domain or address literal form, as required by the +RFC. Note: specify +"smtpd_helo_required = yes" to fully enforce this restriction +(without "smtpd_helo_required = yes", a client can simply skip +reject_non_fqdn_helo_hostname by not sending HELO or EHLO).
    +The non_fqdn_reject_code parameter specifies the response code for +rejected requests (default: 504).
    + +
    reject_rhsbl_helo rbl_domain=d.d.d.d
    + +
    Reject the request when the HELO or EHLO hostname is +listed with the A record "d.d.d.d" under rbl_domain +(Postfix version 2.1 and later only). Each "d" is a number, +or a pattern inside "[]" that contains one or more ";"-separated +numbers or number..number ranges (Postfix version 2.8 and later). +If no "=d.d.d.d" is +specified, reject the request when the HELO or EHLO hostname is +listed with any A record under rbl_domain. See the +reject_rbl_client description for additional RBL related configuration +parameters. Note: specify "smtpd_helo_required = yes" to fully +enforce this restriction (without "smtpd_helo_required = yes", a +client can simply skip reject_rhsbl_helo by not sending HELO or +EHLO). This feature is available in Postfix 2.0 +and later.
    + +
    reject_unknown_helo_hostname (with Postfix < 2.3: reject_unknown_hostname)
    + +
    Reject the request when the HELO or EHLO hostname has no DNS A +or MX record.
    The reply is specified with the +unknown_hostname_reject_code parameter (default: 450) or +unknown_helo_hostname_tempfail_action (default: defer_if_permit). +See the respective parameter descriptions for details.
    +Note: specify "smtpd_helo_required = yes" to fully +enforce this restriction (without "smtpd_helo_required = yes", a +client can simply skip reject_unknown_helo_hostname by not sending +HELO or EHLO).
    + +
    + +

    +Other restrictions that are valid in this context: +

    + +
      + +
    • Generic restrictions that can be used +in any SMTP command context, described under smtpd_client_restrictions. + +
    • Client hostname or network address specific restrictions +described under smtpd_client_restrictions. + +
    • SMTP command specific restrictions described under +smtpd_sender_restrictions or smtpd_recipient_restrictions. When +sender or recipient restrictions are listed under smtpd_helo_restrictions, +they have effect only with "smtpd_delay_reject = yes", so that +$smtpd_helo_restrictions is evaluated at the time of the RCPT TO +command. + +
    + +

    +Examples: +

    + +
    +smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname
+smtpd_helo_restrictions = permit_mynetworks, reject_unknown_helo_hostname
+
    + +%PARAM smtpd_history_flush_threshold 100 + +

    +The maximal number of lines in the Postfix SMTP server command history +before it is flushed upon receipt of EHLO, RSET, or end of DATA. +

    + +%PARAM smtpd_noop_commands + +

    +List of commands that the Postfix SMTP server replies to with "250 +Ok", without doing any syntax checks and without changing state. +This list overrides any commands built into the Postfix SMTP server. +

    + +%PARAM smtpd_proxy_ehlo $myhostname + +

    +How the Postfix SMTP server announces itself to the proxy filter. +By default, the Postfix hostname is used. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_proxy_options + +

    +List of options that control how the Postfix SMTP server +communicates with a before-queue content filter. Specify zero or +more of the following, separated by comma or whitespace.

    + +
    + +
    speed_adjust
    + +

    Do not connect to a before-queue content filter until an entire +message has been received. This reduces the number of simultaneous +before-queue content filter processes.

    + +

    NOTE 1: A filter must not selectively reject recipients +of a multi-recipient message. Rejecting all recipients is OK, as +is accepting all recipients.

    + +

    NOTE 2: This feature increases the minimum amount of free queue +space by $message_size_limit. The extra space is needed to save the +message to a temporary file.

    + +
    + +

    +This feature is available in Postfix 2.7 and later. +

    + +%CLASS smtpd-proxy SMTP Proxy filter + +

    +As of Postfix version 2.1, the SMTP server can forward all incoming +mail to a content filtering proxy server that inspects all mail +BEFORE it is stored in the Postfix mail queue. +

    + +

    +WARNING: the proxy filter must reply within a fixed deadline or +else the remote SMTP client times out and mail duplication happens. +This becomes a problem as mail load increases so that fewer and +fewer CPU cycles remain available to mead the fixed deadline. +

    + +%PARAM smtpd_proxy_filter + +

    The hostname and TCP port of the mail filtering proxy server. +The proxy receives all mail from the Postfix SMTP server, and is +supposed to give the result to another Postfix SMTP server process. +

    + +

    Specify "host:port" or "inet:host:port" for a TCP endpoint, or +"unix:pathname" for a UNIX-domain endpoint. The host can be specified +as an IP address or as a symbolic name; no MX lookups are done. +When no "host" or "host:" are specified, the local machine is +assumed. Pathname interpretation is relative to the Postfix queue +directory.

    + +

    This feature is available in Postfix 2.1 and later.

    + +

    The "inet:" and "unix:" prefixes are available in Postfix 2.3 +and later.

    + +%PARAM smtpd_proxy_timeout 100s + +

    +The time limit for connecting to a proxy filter and for sending or +receiving information. When a connection fails the client gets a +generic error message while more detailed information is logged to +the maillog file. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_recipient_limit 1000 + +

    +The maximal number of recipients that the Postfix SMTP server +accepts per message delivery request. +

    + +%PARAM smtpd_recipient_restrictions see "postconf -d" output + +

    +Optional restrictions that the Postfix SMTP server applies in the +context of a client RCPT TO command, after smtpd_relay_restrictions. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    With Postfix versions before 2.10, the rules for relay permission +and spam blocking were combined under smtpd_recipient_restrictions, +resulting in error-prone configuration. As of Postfix 2.10, relay +permission rules are preferably implemented with smtpd_relay_restrictions, +so that a permissive spam blocking policy under +smtpd_recipient_restrictions will no longer result in a permissive +mail relay policy.

    + +

    For backwards compatibility, sites that migrate from Postfix +versions before 2.10 can set smtpd_relay_restrictions to the empty +value, and use smtpd_recipient_restrictions exactly as before.

    + +

    +IMPORTANT: Either the smtpd_relay_restrictions or the +smtpd_recipient_restrictions parameter must specify +at least one of the following restrictions. Otherwise Postfix will +refuse to receive mail: +

    + +
    +
    +reject, reject_unauth_destination
+
    +
    + +
    +
    +defer, defer_if_permit, defer_unauth_destination
+
    +
    + +

    +Specify a list of restrictions, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. +Restrictions are applied in the order as specified; the first +restriction that matches wins. +

    + +

    +The following restrictions are specific to the recipient address +that is received with the RCPT TO command. +

    + +
    + +
    check_recipient_access type:table
    + +
    Search the specified access(5) database for the resolved RCPT +TO address, domain, parent domains, or localpart@, and execute the +corresponding action.
    + +
    check_recipient_a_access type:table
    + +
    Search the specified access(5) database for the IP addresses for +the RCPT TO domain, and execute the corresponding action. Note: +a result of "OK" is not allowed for safety reasons. Instead, use +DUNNO in order to exclude specific hosts from blacklists. This +feature is available in Postfix 3.0 and later.
    + +
    check_recipient_mx_access type:table
    + +
    Search the specified access(5) database for the MX hosts for +the RCPT TO domain, and execute the corresponding action. Note: +a result of "OK" is not allowed for safety reasons. Instead, use +DUNNO in order to exclude specific hosts from blacklists. This +feature is available in Postfix 2.1 and later.
    + +
    check_recipient_ns_access type:table
    + +
    Search the specified access(5) database for the DNS servers +for the RCPT TO domain, and execute the corresponding action. +Note: a result of "OK" is not allowed for safety reasons. Instead, +use DUNNO in order to exclude specific hosts from blacklists. This +feature is available in Postfix 2.1 and later.
    + +
    permit_auth_destination
    + +
    Permit the request when one of the following is true: + +
      + +
    • Postfix is mail forwarder: the resolved RCPT TO domain matches +$relay_domains or a subdomain thereof, and the address contains no +sender-specified routing (user@elsewhere@domain), + +
    • Postfix is the final destination: the resolved RCPT TO domain +matches $mydestination, $inet_interfaces, $proxy_interfaces, +$virtual_alias_domains, or $virtual_mailbox_domains, and the address +contains no sender-specified routing (user@elsewhere@domain). + +
    + +
    permit_mx_backup
    + +
    Permit the request when the local mail system is backup MX for +the RCPT TO domain, or when the domain is an authorized destination +(see permit_auth_destination for definition). + +
      + +
    • Safety: permit_mx_backup does not accept addresses that have +sender-specified routing information (example: user@elsewhere@domain). + +
    • Safety: permit_mx_backup can be vulnerable to mis-use when +access is not restricted with permit_mx_backup_networks. + +
    • Safety: as of Postfix version 2.3, permit_mx_backup no longer +accepts the address when the local mail system is primary MX for +the recipient domain. Exception: permit_mx_backup accepts the address +when it specifies an authorized destination (see permit_auth_destination +for definition). + +
    • Limitation: mail may be rejected in case of a temporary DNS +lookup problem with Postfix prior to version 2.0. + +
    + +
    reject_non_fqdn_recipient
    + +
    Reject the request when the RCPT TO address specifies a +domain that is not in +fully-qualified domain form, as required by the RFC.
    The +non_fqdn_reject_code parameter specifies the response code for +rejected requests (default: 504).
    + +
    reject_rhsbl_recipient rbl_domain=d.d.d.d
    + +
    Reject the request when the RCPT TO domain is listed with the +A record "d.d.d.d" under rbl_domain (Postfix version +2.1 and later only). Each "d" is a number, or a pattern +inside "[]" that contains one or more ";"-separated numbers or +number..number ranges (Postfix version 2.8 and later). If no +"=d.d.d.d" is specified, reject +the request when the RCPT TO domain is listed with +any A record under rbl_domain.
    The maps_rbl_reject_code +parameter specifies the response code for rejected requests (default: +554); the default_rbl_reply parameter specifies the default server +reply; and the rbl_reply_maps parameter specifies tables with server +replies indexed by rbl_domain. This feature is available +in Postfix version 2.0 and later.
    + +
    reject_unauth_destination
    + +
    Reject the request unless one of the following is true: + +
      + +
    • Postfix is mail forwarder: the resolved RCPT TO domain matches +$relay_domains or a subdomain thereof, and contains no sender-specified +routing (user@elsewhere@domain), + +
    • Postfix is the final destination: the resolved RCPT TO domain +matches $mydestination, $inet_interfaces, $proxy_interfaces, +$virtual_alias_domains, or $virtual_mailbox_domains, and contains +no sender-specified routing (user@elsewhere@domain). + +
    The relay_domains_reject_code parameter specifies the response +code for rejected requests (default: 554).
    + +
    defer_unauth_destination
    + +
    Reject the same requests as reject_unauth_destination, with a +non-permanent error code. This feature is available in Postfix +2.10 and later.
    + +
    reject_unknown_recipient_domain
    + +
    Reject the request when Postfix is not final destination for +the recipient domain, and the RCPT TO domain has 1) no DNS MX and +no DNS A +record or 2) a malformed MX record such as a record with +a zero-length MX hostname (Postfix version 2.3 and later).
    The +reply is specified with the unknown_address_reject_code parameter +(default: 450), unknown_address_tempfail_action (default: +defer_if_permit), or 556 (nullmx, Postfix 3.0 and +later). See the respective parameter descriptions for details. +
    + +
    reject_unlisted_recipient (with Postfix version 2.0: check_recipient_maps)
    + +
    Reject the request when the RCPT TO address is not listed in +the list of valid recipients for its domain class. See the +smtpd_reject_unlisted_recipient parameter description for details. +This feature is available in Postfix 2.1 and later.
    + +
    reject_unverified_recipient
    + +
    Reject the request when mail to the RCPT TO address is known +to bounce, or when the recipient address destination is not reachable. +Address verification information is managed by the verify(8) server; +see the ADDRESS_VERIFICATION_README file for details.
    The +unverified_recipient_reject_code parameter specifies the numerical +response code when an address is known to bounce (default: 450, +change into 550 when you are confident that it is safe to do so). +
    The unverified_recipient_defer_code parameter specifies the +numerical response code when an address probe failed due to a +temporary problem (default: 450).
    The +unverified_recipient_tempfail_action parameter specifies the action +after address probe failure due to a temporary problem (default: +defer_if_permit).
    This feature breaks for aliased addresses +with "enable_original_recipient = no" (Postfix ≤ 3.2).
    +This feature is available in Postfix 2.1 and later.
    + +
    + +

    +Other restrictions that are valid in this context: +

    + +
      + +
    • Generic restrictions that can be used +in any SMTP command context, described under smtpd_client_restrictions. + +
    • SMTP command specific restrictions described under +smtpd_client_restrictions, smtpd_helo_restrictions and +smtpd_sender_restrictions. + +
    + +

    +Example: +

    + +
    +# The Postfix before 2.10 default mail relay policy. Later Postfix
+# versions implement this preferably with smtpd_relay_restrictions.
+smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
+
    + +%PARAM smtpd_relay_restrictions permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination + +

    Access restrictions for mail relay control that the Postfix +SMTP server applies in the context of the RCPT TO command, before +smtpd_recipient_restrictions. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    With Postfix versions before 2.10, the rules for relay permission +and spam blocking were combined under smtpd_recipient_restrictions, +resulting in error-prone configuration. As of Postfix 2.10, relay +permission rules are preferably implemented with smtpd_relay_restrictions, +so that a permissive spam blocking policy under +smtpd_recipient_restrictions will no longer result in a permissive +mail relay policy.

    + +

    For backwards compatibility, sites that migrate from Postfix +versions before 2.10 can set smtpd_relay_restrictions to the empty +value, and use smtpd_recipient_restrictions exactly as before.

    + +

    +By default, the Postfix SMTP server accepts: +

    + +
      + +
    • Mail from clients whose IP address matches $mynetworks, or: + +
    • Mail to remote destinations that match $relay_domains, except +for addresses that contain sender-specified routing +(user@elsewhere@domain), or: + +
    • Mail to local destinations that match $inet_interfaces +or $proxy_interfaces, $mydestination, $virtual_alias_domains, or +$virtual_mailbox_domains. + +
    + +

    +IMPORTANT: Either the smtpd_relay_restrictions or the +smtpd_recipient_restrictions parameter must specify +at least one of the following restrictions. Otherwise Postfix will +refuse to receive mail: +

    + +
    +
    +reject, reject_unauth_destination
+
    +
    + +
    +
    +defer, defer_if_permit, defer_unauth_destination
+
    +
    + +

    +Specify a list of restrictions, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. +The same restrictions are available as documented under +smtpd_recipient_restrictions. +

    + +

    This feature is available in Postix 2.10 and later.

    + +%CLASS sasl-auth SASL Authentication + +

    +Postfix SASL support (RFC 4954) can be used to authenticate remote +SMTP clients to the Postfix SMTP server, and to authenticate the +Postfix SMTP client to a remote SMTP server. +See the SASL_README document for details. +

    + +%PARAM smtpd_sasl_auth_enable no + +

    +Enable SASL authentication in the Postfix SMTP server. By default, +the Postfix SMTP server does not use authentication. +

    + +

    +If a remote SMTP client is authenticated, the permit_sasl_authenticated +access restriction can be used to permit relay access, like this: +

    + +
    +
    +# With Postfix 2.10 and later, the mail relay policy is
+# preferably specified under smtpd_relay_restrictions.
+smtpd_relay_restrictions =
+    permit_mynetworks, permit_sasl_authenticated, ...
+
    + +
    +# With Postfix before 2.10, the relay policy can be
+# specified only under smtpd_recipient_restrictions.
+smtpd_recipient_restrictions =
+    permit_mynetworks, permit_sasl_authenticated, ...
+
    +
    + +

    To reject all SMTP connections from unauthenticated clients, +specify "smtpd_delay_reject = yes" (which is the default) and use: +

    + +
    +
    +smtpd_client_restrictions = permit_sasl_authenticated, reject
+
    +
    + +

    +See the SASL_README file for SASL configuration and operation details. +

    + +%PARAM smtpd_sasl_authenticated_header no + +

    Report the SASL authenticated user name in the smtpd(8) Received +message header.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_sasl_exceptions_networks + +

    +What remote SMTP clients the Postfix SMTP server will not offer +AUTH support to. +

    + +

    +Some clients (Netscape 4 at least) have a bug that causes them to +require a login and password whenever AUTH is offered, whether it's +necessary or not. To work around this, specify, for example, +$mynetworks to prevent Postfix from offering AUTH to local clients. +

    + +

    +Specify a list of network/netmask patterns, separated by commas +and/or whitespace. The mask specifies the number of bits in the +network part of a host address. You can also "/file/name" or +"type:table" patterns. A "/file/name" pattern is replaced by its +contents; a "type:table" lookup table is matched when a table entry +matches a lookup string (the lookup result is ignored). Continue +long lines by starting the next line with whitespace. Specify +"!pattern" to exclude an address or network block from the list. +The form "!/file/name" is supported only in Postfix version 2.4 and +later.

    + +

    Note: IP version 6 address information must be specified inside +[] in the smtpd_sasl_exceptions_networks value, and in +files specified with "/file/name". IP version 6 addresses contain +the ":" character, and would otherwise be confused with a "type:table" +pattern.

    + +

    +Example: +

    + +
    +smtpd_sasl_exceptions_networks = $mynetworks
+
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_sasl_local_domain + +

    +The name of the Postfix SMTP server's local SASL authentication +realm. +

    + +

    +By default, the local authentication realm name is the null string. +

    + +

    +Examples: +

    + +
    +smtpd_sasl_local_domain = $mydomain
+smtpd_sasl_local_domain = $myhostname
+
    + +%PARAM smtpd_sasl_security_options noanonymous + +

    Postfix SMTP server SASL security options; as of Postfix 2.3 +the list of available +features depends on the SASL server implementation that is selected +with smtpd_sasl_type.

    + +

    The following security features are defined for the cyrus +server SASL implementation:

    + +

    +Restrict what authentication mechanisms the Postfix SMTP server +will offer to the client. The list of available authentication +mechanisms is system dependent. +

    + +

    +Specify zero or more of the following: +

    + +
    + +
    noplaintext
    + +
    Disallow methods that use plaintext passwords.
    + +
    noactive
    + +
    Disallow methods subject to active (non-dictionary) attack.
    + +
    nodictionary
    + +
    Disallow methods subject to passive (dictionary) attack.
    + +
    noanonymous
    + +
    Disallow methods that allow anonymous authentication.
    + +
    forward_secrecy
    + +
    Only allow methods that support forward secrecy (Dovecot only). +
    + +
    mutual_auth
    + +
    Only allow methods that provide mutual authentication (not available +with Cyrus SASL version 1).
    + +
    + +

    +By default, the Postfix SMTP server accepts plaintext passwords but +not anonymous logins. +

    + +

    +Warning: it appears that clients try authentication methods in the +order as advertised by the server (e.g., PLAIN ANONYMOUS CRAM-MD5) +which means that if you disable plaintext passwords, clients will +log in anonymously, even when they should be able to use CRAM-MD5. +So, if you disable plaintext logins, disable anonymous logins too. +Postfix treats anonymous login as no authentication. +

    + +

    +Example: +

    + +
    +smtpd_sasl_security_options = noanonymous, noplaintext
+
    + +%PARAM smtpd_sender_login_maps + +

    +Optional lookup table with the SASL login names that own the sender +(MAIL FROM) addresses. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. With lookups from +indexed files such as DB or DBM, or from networked tables such as +NIS, LDAP or SQL, the following search operations are done with a +sender address of user@domain:

    + +
    + +
    1) user@domain
    + +
    This table lookup is always done and has the highest precedence.
    + +
    2) user
    + +
    This table lookup is done only when the domain part of the +sender address matches $myorigin, $mydestination, $inet_interfaces +or $proxy_interfaces.
    + +
    3) @domain
    + +
    This table lookup is done last and has the lowest precedence.
    + +
    + +

    +In all cases the result of table lookup must be either "not found" +or a list of SASL login names separated by comma and/or whitespace. +

    + +%PARAM smtpd_sender_restrictions + +

    +Optional restrictions that the Postfix SMTP server applies in the +context of a client MAIL FROM command. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    +The default is to permit everything. +

    + +

    +Specify a list of restrictions, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. +Restrictions are applied in the order as specified; the first +restriction that matches wins. +

    + +

    +The following restrictions are specific to the sender address +received with the MAIL FROM command. +

    + +
    + +
    check_sender_access type:table
    + +
    Search the specified access(5) database for the MAIL FROM +address, domain, parent domains, or localpart@, and execute the +corresponding action.
    + +
    check_sender_a_access type:table
    + +
    Search the specified access(5) database for the IP addresses for +the MAIL FROM domain, and execute the corresponding action. Note: +a result of "OK" is not allowed for safety reasons. Instead, use +DUNNO in order to exclude specific hosts from blacklists. This +feature is available in Postfix 3.0 and later.
    + +
    check_sender_mx_access type:table
    + +
    Search the specified access(5) database for the MX hosts for +the MAIL FROM domain, and execute the corresponding action. Note: +a result of "OK" is not allowed for safety reasons. Instead, use +DUNNO in order to exclude specific hosts from blacklists. This +feature is available in Postfix 2.1 and later.
    + +
    check_sender_ns_access type:table
    + +
    Search the specified access(5) database for the DNS servers +for the MAIL FROM domain, and execute the corresponding action. +Note: a result of "OK" is not allowed for safety reasons. Instead, +use DUNNO in order to exclude specific hosts from blacklists. This +feature is available in Postfix 2.1 and later.
    + +
    reject_authenticated_sender_login_mismatch
    + +
    Enforces the reject_sender_login_mismatch restriction for +authenticated clients only. This feature is available in +Postfix version 2.1 and later.
    + +
    reject_known_sender_login_mismatch
    + +
    Apply the reject_sender_login_mismatch restriction only to MAIL +FROM addresses that are known in $smtpd_sender_login_maps. This +feature is available in Postfix version 2.11 and later.
    + +
    reject_non_fqdn_sender
    + +
    Reject the request when the MAIL FROM address specifies a +domain that is not in +fully-qualified domain form as required by the RFC.
    The +non_fqdn_reject_code parameter specifies the response code for +rejected requests (default: 504).
    + +
    reject_rhsbl_sender rbl_domain=d.d.d.d
    + +
    Reject the request when the MAIL FROM domain is listed with +the A record "d.d.d.d" under rbl_domain (Postfix +version 2.1 and later only). Each "d" is a number, or a +pattern inside "[]" that contains one or more ";"-separated numbers +or number..number ranges (Postfix version 2.8 and later). If no +"=d.d.d.d" is specified, +reject the request when the MAIL FROM domain is +listed with any A record under rbl_domain.
    The +maps_rbl_reject_code parameter specifies the response code for +rejected requests (default: 554); the default_rbl_reply parameter +specifies the default server reply; and the rbl_reply_maps parameter +specifies tables with server replies indexed by rbl_domain. +This feature is available in Postfix 2.0 and later.
    + +
    reject_sender_login_mismatch
    + +
    Reject the request when $smtpd_sender_login_maps specifies an +owner for the MAIL FROM address, but the client is not (SASL) logged +in as that MAIL FROM address owner; or when the client is (SASL) +logged in, but the client login name doesn't own the MAIL FROM +address according to $smtpd_sender_login_maps.
    + +
    reject_unauthenticated_sender_login_mismatch
    + +
    Enforces the reject_sender_login_mismatch restriction for +unauthenticated clients only. This feature is available in +Postfix version 2.1 and later.
    + +
    reject_unknown_sender_domain
    + +
    Reject the request when Postfix is not final destination for +the sender address, and the MAIL FROM domain has 1) no DNS MX and +no DNS A +record, or 2) a malformed MX record such as a record with +a zero-length MX hostname (Postfix version 2.3 and later).
    The +reply is specified with the unknown_address_reject_code parameter +(default: 450), unknown_address_tempfail_action (default: +defer_if_permit), or 550 (nullmx, Postfix 3.0 and +later). See the respective parameter descriptions for details. +
    + +
    reject_unlisted_sender
    + +
    Reject the request when the MAIL FROM address is not listed in +the list of valid recipients for its domain class. See the +smtpd_reject_unlisted_sender parameter description for details. +This feature is available in Postfix 2.1 and later.
    + +
    reject_unverified_sender
    + +
    Reject the request when mail to the MAIL FROM address is known to +bounce, or when the sender address destination is not reachable. +Address verification information is managed by the verify(8) server; +see the ADDRESS_VERIFICATION_README file for details.
    The +unverified_sender_reject_code parameter specifies the numerical +response code when an address is known to bounce (default: 450, +change into 550 when you are confident that it is safe to do so). +
    The unverified_sender_defer_code specifies the numerical response +code when an address probe failed due to a temporary problem +(default: 450).
    The unverified_sender_tempfail_action parameter +specifies the action after address probe failure due to a temporary +problem (default: defer_if_permit).
    This feature breaks for +aliased addresses with "enable_original_recipient = no" (Postfix +≤ 3.2).
    This feature is available in Postfix 2.1 and later. +
    + +
    + +

    +Other restrictions that are valid in this context: +

    + +
      + +
    • Generic restrictions that can be used +in any SMTP command context, described under smtpd_client_restrictions. + +
    • SMTP command specific restrictions described under +smtpd_client_restrictions and smtpd_helo_restrictions. + +
    • SMTP command specific restrictions described under +smtpd_recipient_restrictions. When recipient restrictions are listed +under smtpd_sender_restrictions, they have effect only with +"smtpd_delay_reject = yes", so that $smtpd_sender_restrictions is +evaluated at the time of the RCPT TO command. + +
    + +

    +Examples: +

    + +
    +smtpd_sender_restrictions = reject_unknown_sender_domain
+smtpd_sender_restrictions = reject_unknown_sender_domain,
+    check_sender_access hash:/etc/postfix/access
+
    + +%PARAM smtpd_timeout normal: 300s, overload: 10s + +

    +The time limit for sending a Postfix SMTP server response and for +receiving a remote SMTP client request. Normally the default limit +is 300s, but it changes under overload to just 10s. With Postfix +2.5 and earlier, the SMTP server always uses a time limit of 300s +by default. +

    + +

    +Note: if you set SMTP time limits to very large values you may have +to update the global ipc_timeout parameter. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM soft_bounce no + +

    +Safety net to keep mail queued that would otherwise be returned to +the sender. This parameter disables locally-generated bounces, +changes the handling of negative responses from remote servers, +content filters or plugins, +and prevents the Postfix SMTP server from rejecting mail permanently +by changing 5xx reply codes into 4xx. However, soft_bounce is no +cure for address rewriting mistakes or mail routing mistakes. +

    + +

    +Note: "soft_bounce = yes" is in some cases implemented by modifying +server responses. Therefore, the response that Postfix logs may +differ from the response that Postfix actually sends or receives. +

    + +

    +Example: +

    + +
    +soft_bounce = yes
+
    + +%PARAM stale_lock_time 500s + +

    +The time after which a stale exclusive mailbox lockfile is removed. +This is used for delivery to file or mailbox. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM strict_rfc821_envelopes no + +

    +Require that addresses received in SMTP MAIL FROM and RCPT TO +commands are enclosed with <>, and that those addresses do +not contain RFC 822 style comments or phrases. This stops mail +from poorly written software. +

    + +

    +By default, the Postfix SMTP server accepts RFC 822 syntax in MAIL +FROM and RCPT TO addresses. +

    + +%PARAM swap_bangpath yes + +

    +Enable the rewriting of "site!user" into "user@site". This is +necessary if your machine is connected to UUCP networks. It is +enabled by default. +

    + +

    Note: with Postfix version 2.2, message header address rewriting +happens only when one of the following conditions is true:

    + +
      + +
    • The message is received with the Postfix sendmail(1) command, + +
    • The message is received from a network client that matches +$local_header_rewrite_clients, + +
    • The message is received from the network, and the +remote_header_rewrite_domain parameter specifies a non-empty value. + +
    + +

    To get the behavior before Postfix version 2.2, specify +"local_header_rewrite_clients = static:all".

    + +

    +Example: +

    + +
    +swap_bangpath = no
+
    + +%PARAM syslog_facility mail + +

    +The syslog facility of Postfix logging. Specify a facility as +defined in syslog.conf(5). The default facility is "mail". +

    + +

    +Warning: a non-default syslog_facility setting takes effect only +after a Postfix process has completed initialization. Errors during +process initialization will be logged with the default facility. +Examples are errors while parsing the command line arguments, and +errors while accessing the Postfix main.cf configuration file. +

    + +%PARAM syslog_name see "postconf -d" output + +

    +A prefix that is prepended to the process name in syslog +records, so that, for example, "smtpd" becomes "prefix/smtpd". +

    + +

    +Warning: a non-default syslog_name setting takes effect only after +a Postfix process has completed initialization. Errors during +process initialization will be logged with the default name. Examples +are errors while parsing the command line arguments, and errors +while accessing the Postfix main.cf configuration file. +

    + +%PARAM transport_maps + +

    +Optional lookup tables with mappings from recipient address to +(message delivery transport, next-hop destination). See transport(5) +for details. +

    + +

    +Specify zero or more "type:table" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. If you use this +feature with local files, run "postmap /etc/postfix/transport" +after making a change.

    + +

    Pattern matching of domain names is controlled by the presence +or absence of "transport_maps" in the parent_domain_matches_subdomains +parameter value.

    + +

    For safety reasons, as of Postfix 2.3 this feature does not +allow $number substitutions in regular expression maps.

    + +

    +Examples: +

    + +
    +transport_maps = dbm:/etc/postfix/transport
+transport_maps = hash:/etc/postfix/transport
+
    + +%PARAM transport_retry_time 60s + +

    +The time between attempts by the Postfix queue manager to contact +a malfunctioning message delivery transport. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM trigger_timeout 10s + +

    +The time limit for sending a trigger to a Postfix daemon (for +example, the pickup(8) or qmgr(8) daemon). This time limit prevents +programs from getting stuck when the mail system is under heavy +load. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM unknown_address_reject_code 450 + +

    +The numerical response code when the Postfix SMTP server rejects a +sender or recipient address because its domain is unknown. This +is one of the possible replies from the restrictions +reject_unknown_sender_domain and reject_unknown_recipient_domain. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM unknown_client_reject_code 450 + +

    +The numerical Postfix SMTP server response code when a client +without valid address <=> name mapping is rejected by the +reject_unknown_client_hostname restriction. The SMTP server always replies +with 450 when the mapping failed due to a temporary error condition. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM unknown_hostname_reject_code 450 + +

    +The numerical Postfix SMTP server response code when the hostname +specified with the HELO or EHLO command is rejected by the +reject_unknown_helo_hostname restriction. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +%PARAM unknown_local_recipient_reject_code 550 + +

    +The numerical Postfix SMTP server response code when a recipient +address is local, and $local_recipient_maps specifies a list of +lookup tables that does not match the recipient. A recipient +address is local when its domain matches $mydestination, +$proxy_interfaces or $inet_interfaces. +

    + +

    +The default setting is 550 (reject mail) but it is safer to initially +use 450 (try again later) so you have time to find out if your +local_recipient_maps settings are OK. +

    + +

    +Example: +

    + +
    +unknown_local_recipient_reject_code = 450
+
    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM unverified_recipient_reject_code 450 + +

    +The numerical Postfix SMTP server response when a recipient address +is rejected by the reject_unverified_recipient restriction. +

    + +

    +Unlike elsewhere in Postfix, you can specify 250 in order to +accept the address anyway. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM unverified_recipient_defer_code 450 + +

    +The numerical Postfix SMTP server response when a recipient address +probe fails due to a temporary error condition. +

    + +

    +Unlike elsewhere in Postfix, you can specify 250 in order to +accept the address anyway. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +

    +This feature is available in Postfix 2.6 and later. +

    + +%PARAM unverified_sender_reject_code 450 + +

    +The numerical Postfix SMTP server response code when a recipient +address is rejected by the reject_unverified_sender restriction. +

    + +

    +Unlike elsewhere in Postfix, you can specify 250 in order to +accept the address anyway. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM unverified_sender_defer_code 450 + +

    +The numerical Postfix SMTP server response code when a sender address +probe fails due to a temporary error condition. +

    + +

    +Unlike elsewhere in Postfix, you can specify 250 in order to +accept the address anyway. +

    + +

    +Do not change this unless you have a complete understanding of RFC 5321. +

    + +

    +This feature is available in Postfix 2.6 and later. +

    + +%PARAM virtual_alias_domains $virtual_alias_maps + +

    Postfix is final destination for the specified list of virtual +alias domains, that is, domains for which all addresses are aliased +to addresses in other local or remote domains. The SMTP server +validates recipient addresses with $virtual_alias_maps and rejects +non-existent recipients. See also the virtual alias domain class +in the ADDRESS_CLASS_README file

    + +

    +This feature is available in Postfix 2.0 and later. The default +value is backwards compatible with Postfix version 1.1. +

    + +

    +The default value is $virtual_alias_maps so that you can keep all +information about virtual alias domains in one place. If you have +many users, it is better to separate information that changes more +frequently (virtual address -> local or remote address mapping) +from information that changes less frequently (the list of virtual +domain names). +

    + +

    Specify a list of host or domain names, "/file/name" or +"type:table" patterns, separated by commas and/or whitespace. A +"/file/name" pattern is replaced by its contents; a "type:table" +lookup table is matched when a table entry matches a lookup string +(the lookup result is ignored). Continue long lines by starting +the next line with whitespace. Specify "!pattern" to exclude a host +or domain name from the list. The form "!/file/name" is supported +only in Postfix version 2.4 and later.

    + +

    +See also the VIRTUAL_README and ADDRESS_CLASS_README documents +for further information. +

    + +

    +Example: +

    + +
    +virtual_alias_domains = virtual1.tld virtual2.tld
+
    + +%PARAM virtual_alias_expansion_limit 1000 + +

    +The maximal number of addresses that virtual alias expansion produces +from each original recipient. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM virtual_alias_maps $virtual_maps + +

    +Optional lookup tables that alias specific mail addresses or domains +to other local or remote address. The table format and lookups +are documented in virtual(5). For an overview of Postfix address +manipulations see the ADDRESS_REWRITING_README document. +

    + +

    +This feature is available in Postfix 2.0 and later. The default +value is backwards compatible with Postfix version 1.1. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +Note: these lookups are recursive. +

    + +

    +If you use this feature with indexed files, run "postmap +/etc/postfix/virtual" after changing the file. +

    + +

    +Examples: +

    + +
    +virtual_alias_maps = dbm:/etc/postfix/virtual
+virtual_alias_maps = hash:/etc/postfix/virtual
+
    + +%PARAM virtual_alias_recursion_limit 1000 + +

    +The maximal nesting depth of virtual alias expansion. Currently +the recursion limit is applied only to the left branch of the +expansion graph, so the depth of the tree can in the worst case +reach the sum of the expansion and recursion limits. This may +change in the future. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%CLASS trouble-shooting Trouble shooting + +

    +The DEBUG_README document describes how to debug parts of the +Postfix mail system. The methods vary from making the software log +a lot of detail, to running some daemon processes under control of +a call tracer or debugger. +

    + +%PARAM debugger_command + +

    +The external command to execute when a Postfix daemon program is +invoked with the -D option. +

    + +

    +Use "command .. & sleep 5" so that the debugger can attach before +the process marches on. If you use an X-based debugger, be sure to +set up your XAUTHORITY environment variable before starting Postfix. +

    + +

    +Note: the command is subject to $name expansion, before it is +passed to the default command interpreter. Specify "$$" to +produce a single "$" character. +

    + +

    +Example: +

    + +
    +debugger_command =
+    PATH=/usr/bin:/usr/X11R6/bin
+    ddd $daemon_directory/$process_name $process_id & sleep 5
+
    + +%PARAM 2bounce_notice_recipient postmaster + +

    The recipient of undeliverable mail that cannot be returned to +the sender. This feature is enabled with the notify_classes +parameter.

    + +%PARAM address_verify_service_name verify + +

    +The name of the verify(8) address verification service. This service +maintains the status of sender and/or recipient address verification +probes, and generates probes on request by other Postfix processes. +

    + +%PARAM alternate_config_directories + +

    +A list of non-default Postfix configuration directories that may +be specified with "-c config_directory" on the command line (in the +case of sendmail(1), with the "-C" option), or via the MAIL_CONFIG +environment parameter. +

    + +

    +This list must be specified in the default Postfix main.cf file, +and will be used by set-gid Postfix commands such as postqueue(1) +and postdrop(1). +

    + +

    +Specify absolute pathnames, separated by comma or space. Note: $name +expansion is not supported. +

    + +%PARAM append_at_myorigin yes + +

    +With locally submitted mail, append the string "@$myorigin" to mail +addresses without domain information. With remotely submitted mail, +append the string "@$remote_header_rewrite_domain" instead. +

    + +

    +Note 1: this feature is enabled by default and must not be turned off. +Postfix does not support domain-less addresses. +

    + +

    Note 2: with Postfix version 2.2, message header address rewriting +happens only when one of the following conditions is true:

    + +
      + +
    • The message is received with the Postfix sendmail(1) command, + +
    • The message is received from a network client that matches +$local_header_rewrite_clients, + +
    • The message is received from the network, and the +remote_header_rewrite_domain parameter specifies a non-empty value. + +
    + +

    To get the behavior before Postfix version 2.2, specify +"local_header_rewrite_clients = static:all".

    + +%PARAM append_dot_mydomain Postfix ≥ 3.0: no, Postfix < 3.0: yes + +

    +With locally submitted mail, append the string ".$mydomain" to +addresses that have no ".domain" information. With remotely submitted +mail, append the string ".$remote_header_rewrite_domain" +instead. +

    + +

    +Note 1: this feature is enabled by default. If disabled, users will not be +able to send mail to "user@partialdomainname" but will have to +specify full domain names instead. +

    + +

    Note 2: with Postfix version 2.2, message header address rewriting +happens only when one of the following conditions is true:

    + +
      + +
    • The message is received with the Postfix sendmail(1) command, + +
    • The message is received from a network client that matches +$local_header_rewrite_clients, + +
    • The message is received from the network, and the +remote_header_rewrite_domain parameter specifies a non-empty value. + +
    + +

    To get the behavior before Postfix version 2.2, specify +"local_header_rewrite_clients = static:all".

    + +%PARAM application_event_drain_time 100s + +

    +How long the postkick(1) command waits for a request to enter the +Postfix daemon process input buffer before giving up. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM authorized_flush_users static:anyone + +

    +List of users who are authorized to flush the queue. +

    + +

    +By default, all users are allowed to flush the queue. Access is +always granted if the invoking user is the super-user or the +$mail_owner user. Otherwise, the real UID of the process is looked +up in the system password file, and access is granted only if the +corresponding login name is on the access list. The username +"unknown" is used for processes whose real UID is not found in the +password file.

    + +

    +Specify a list of user names, "/file/name" or "type:table" patterns, +separated by commas and/or whitespace. The list is matched left to +right, and the search stops on the first match. A "/file/name" +pattern is replaced +by its contents; a "type:table" lookup table is matched when a name +matches a lookup key (the lookup result is ignored). Continue long +lines by starting the next line with whitespace. Specify "!pattern" +to exclude a name from the list. The form "!/file/name" is supported +only in Postfix version 2.4 and later.

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +%PARAM authorized_mailq_users static:anyone + +

    +List of users who are authorized to view the queue. +

    + +

    +By default, all users are allowed to view the queue. Access is +always granted if the invoking user is the super-user or the +$mail_owner user. Otherwise, the real UID of the process is looked +up in the system password file, and access is granted only if the +corresponding login name is on the access list. The username +"unknown" is used for processes whose real UID is not found in the +password file.

    + +

    +Specify a list of user names, "/file/name" or "type:table" patterns, +separated by commas and/or whitespace. The list is matched left to +right, and the search stops on the first match. A "/file/name" +pattern is replaced +by its contents; a "type:table" lookup table is matched when a name +matches a lookup key (the lookup result is ignored). Continue long +lines by starting the next line with whitespace. Specify "!pattern" +to exclude a user name from the list. The form "!/file/name" is +supported only in Postfix version 2.4 and later.

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +%PARAM authorized_submit_users static:anyone + +

    +List of users who are authorized to submit mail with the sendmail(1) +command (and with the privileged postdrop(1) helper command). +

    + +

    +By default, all users are allowed to submit mail. Otherwise, the +real UID of the process is looked up in the system password file, +and access is granted only if the corresponding login name is on +the access list. The username "unknown" is used for processes +whose real UID is not found in the password file. To deny mail +submission access to all users specify an empty list.

    + +

    +Specify a list of user names, "/file/name" or "type:table" patterns, +separated by commas and/or whitespace. The list is matched left to right, +and the search stops on the first match. A "/file/name" pattern is +replaced by its contents; +a "type:table" lookup table is matched when a name matches a lookup key +(the lookup result is ignored). Continue long lines by starting the +next line with whitespace. Specify "!pattern" to exclude a user +name from the list. The form "!/file/name" is supported only in +Postfix version 2.4 and later.

    + +

    +Example: +

    + +
    +authorized_submit_users = !www, static:all
+
    + +

    +This feature is available in Postfix 2.2 and later. +

    + +%PARAM backwards_bounce_logfile_compatibility yes + +

    +Produce additional bounce(8) logfile records that can be read by +Postfix versions before 2.0. The current and more extensible "name = +value" format is needed in order to implement more sophisticated +functionality. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM bounce_notice_recipient postmaster + +

    +The recipient of postmaster notifications with the message headers +of mail that Postfix did not deliver and of SMTP conversation +transcripts of mail that Postfix did not receive. This feature is +enabled with the notify_classes parameter.

    + +%PARAM bounce_service_name bounce + +

    +The name of the bounce(8) service. This service maintains a record +of failed delivery attempts and generates non-delivery notifications. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM broken_sasl_auth_clients no + +

    +Enable interoperability with remote SMTP clients that implement an obsolete +version of the AUTH command (RFC 4954). Examples of such clients +are MicroSoft Outlook Express version 4 and MicroSoft Exchange +version 5.0. +

    + +

    +Specify "broken_sasl_auth_clients = yes" to have Postfix advertise +AUTH support in a non-standard way. +

    + +%PARAM cleanup_service_name cleanup + +

    +The name of the cleanup(8) service. This service rewrites addresses +into the standard form, and performs canonical(5) address mapping +and virtual(5) aliasing. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM anvil_status_update_time 600s + +

    +How frequently the anvil(8) connection and rate limiting server +logs peak usage information. +

    + +

    +This feature is available in Postfix 2.2 and later. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM enable_errors_to no + +

    Report mail delivery errors to the address specified with the +non-standard Errors-To: message header, instead of the envelope +sender address (this feature is removed with Postfix version 2.2, is +turned off by default with Postfix version 2.1, and is always turned on +with older Postfix versions).

    + +%PARAM extract_recipient_limit 10240 + +

    +The maximal number of recipient addresses that Postfix will extract +from message headers when mail is submitted with "sendmail -t". +

    + +

    +This feature was removed in Postfix version 2.1. +

    + +%PARAM anvil_rate_time_unit 60s + +

    +The time unit over which client connection rates and other rates +are calculated. +

    + +

    +This feature is implemented by the anvil(8) service which is available +in Postfix version 2.2 and later. +

    + +

    +The default interval is relatively short. Because of the high +frequency of updates, the anvil(8) server uses volatile memory +only. Thus, information is lost whenever the process terminates. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM command_expansion_filter see "postconf -d" output + +

    +Restrict the characters that the local(8) delivery agent allows in +$name expansions of $mailbox_command and $command_execution_directory. +Characters outside the +allowed set are replaced by underscores. +

    + +%PARAM content_filter + +

    After the message is queued, send the entire message to the +specified transport:destination. The transport name +specifies the first field of a mail delivery agent definition in +master.cf; the syntax of the next-hop destination is described +in the manual page of the corresponding delivery agent. More +information about external content filters is in the Postfix +FILTER_README file.

    + +

    Notes:

    + +
      + +

    • This setting has lower precedence than a FILTER action +that is specified in an access(5), header_checks(5) or body_checks(5) +table.

      + +

    • The meaning of an empty next-hop filter destination +is version dependent. Postfix 2.7 and later will use the recipient +domain; earlier versions will use $myhostname. Specify +"default_filter_nexthop = $myhostname" for compatibility with Postfix +2.6 or earlier, or specify a content_filter value with an explicit +next-hop destination.

      + +
    + +%PARAM default_delivery_slot_discount 50 + +

    +The default value for transport-specific _delivery_slot_discount +settings. +

    + +

    +This parameter speeds up the moment when a message preemption can +happen. Instead of waiting until the full amount of delivery slots +required is available, the preemption can happen when +transport_delivery_slot_discount percent of the required amount +plus transport_delivery_slot_loan still remains to be accumulated. +Note that the full amount will still have to be accumulated before +another preemption can take place later. +

    + +

    Use transport_delivery_slot_discount to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +%PARAM default_delivery_slot_loan 3 + +

    +The default value for transport-specific _delivery_slot_loan +settings. +

    + +

    +This parameter speeds up the moment when a message preemption can +happen. Instead of waiting until the full amount of delivery slots +required is available, the preemption can happen when +transport_delivery_slot_discount percent of the required amount +plus transport_delivery_slot_loan still remains to be accumulated. +Note that the full amount will still have to be accumulated before +another preemption can take place later. +

    + +

    Use transport_delivery_slot_loan to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +%CLASS verp VERP Support + +

    +With VERP style delivery, each recipient of a message receives a +customized copy of the message with his/her own recipient address +encoded in the envelope sender address. The VERP_README file +describes configuration and operation details of Postfix support +for variable envelope return path addresses. VERP style delivery +is requested with the SMTP XVERP command or with the "sendmail +-V" command-line option and is available in Postfix +1.1 and later. +

    + +%PARAM default_verp_delimiters += + +

    The two default VERP delimiter characters. These are used when +no explicit delimiters are specified with the SMTP XVERP command +or with the "sendmail -V" command-line option. Specify +characters that are allowed by the verp_delimiter_filter setting. +

    + +

    +This feature is available in Postfix 1.1 and later. +

    + +%PARAM defer_service_name defer + +

    +The name of the defer service. This service is implemented by the +bounce(8) daemon and maintains a record +of failed delivery attempts and generates non-delivery notifications. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM delay_notice_recipient postmaster + +

    +The recipient of postmaster notifications with the message headers +of mail that cannot be delivered within $delay_warning_time time +units.

    + +

    +See also: delay_warning_time, notify_classes. +

    + +%PARAM delay_warning_time 0h + +

    +The time after which the sender receives a copy of the message +headers of mail that is still queued. The confirm_delay_cleared +parameter controls sender notification when the delay clears up. +

    + +

    +To enable this feature, specify a non-zero time value (an integral +value plus an optional one-letter suffix that specifies the time +unit). +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is h (hours). +

    + +

    +See also: delay_notice_recipient, notify_classes, confirm_delay_cleared. +

    + +%PARAM confirm_delay_cleared no + +

    After sending a "your message is delayed" notification, inform +the sender when the delay clears up. This can result in a sudden +burst of notifications at the end of a prolonged network outage, +and is therefore disabled by default.

    + +

    See also: delay_warning_time.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM disable_dns_lookups no + +

    +Disable DNS lookups in the Postfix SMTP and LMTP clients. When +disabled, hosts are looked up with the getaddrinfo() system +library routine which normally also looks in /etc/hosts. As of +Postfix 2.11, this parameter is deprecated; use smtp_dns_support_level +instead. +

    + +

    +DNS lookups are enabled by default. +

    + +%CLASS mime MIME Processing + +

    +MIME processing is available in Postfix as of version 2.0. Older +Postfix versions do not recognize MIME headers inside the message +body. +

    + +%PARAM disable_mime_input_processing no + +

    +Turn off MIME processing while receiving mail. This means that no +special treatment is given to Content-Type: message headers, and +that all text after the initial message headers is considered to +be part of the message body. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +

    +Mime input processing is enabled by default, and is needed in order +to recognize MIME headers in message content. +

    + +%PARAM disable_mime_output_conversion no + +

    +Disable the conversion of 8BITMIME format to 7BIT format. Mime +output conversion is needed when the destination does not advertise +8BITMIME support. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM disable_verp_bounces no + +

    +Disable sending one bounce report per recipient. +

    + +

    +The default, one per recipient, is what ezmlm needs. +

    + +

    +This feature is available in Postfix 1.1 and later. +

    + +%PARAM dont_remove 0 + +

    +Don't remove queue files and save them to the "saved" mail queue. +This is a debugging aid. To inspect the envelope information and +content of a Postfix queue file, use the postcat(1) command. +

    + +%PARAM empty_address_recipient MAILER-DAEMON + +

    +The recipient of mail addressed to the null address. Postfix does +not accept such addresses in SMTP commands, but they may still be +created locally as the result of configuration or software error. +

    + +%PARAM error_notice_recipient postmaster + +

    The recipient of postmaster notifications about mail delivery +problems that are caused by policy, resource, software or protocol +errors. These notifications are enabled with the notify_classes +parameter.

    + +%PARAM error_service_name error + +

    +The name of the error(8) pseudo delivery agent. This service always +returns mail as undeliverable. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM expand_owner_alias no + +

    +When delivering to an alias "aliasname" that has an +"owner-aliasname" companion alias, set the envelope sender +address to the expansion of the "owner-aliasname" alias. +Normally, Postfix sets the envelope sender address to the name of +the "owner-aliasname" alias. +

    + +%PARAM fallback_transport + +

    +Optional message delivery transport that the local(8) delivery +agent should use for names that are not found in the aliases(5) +or UNIX password database. +

    + +

    The precedence of local(8) delivery features from high to low +is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, +mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, +fallback_transport_maps, fallback_transport and luser_relay.

    + +%PARAM fault_injection_code 0 + +

    +Force specific internal tests to fail, to test the handling of +errors that are difficult to reproduce otherwise. +

    + +%PARAM flush_service_name flush + +

    +The name of the flush(8) service. This service maintains per-destination +logfiles with the queue file names of mail that is queued for those +destinations. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM forward_expansion_filter see "postconf -d" output + +

    +Restrict the characters that the local(8) delivery agent allows in +$name expansions of $forward_path. Characters outside the +allowed set are replaced by underscores. +

    + +%PARAM header_address_token_limit 10240 + +

    +The maximal number of address tokens are allowed in an address +message header. Information that exceeds the limit is discarded. +The limit is enforced by the cleanup(8) server. +

    + +%PARAM helpful_warnings yes + +

    +Log warnings about problematic configuration settings, and provide +helpful suggestions. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM lmtp_cache_connection yes + +

    +Keep Postfix LMTP client connections open for up to $max_idle +seconds. When the LMTP client receives a request for the same +connection the connection is reused. +

    + +

    This parameter is available in Postfix version 2.2 and earlier. +With Postfix version 2.3 and later, see lmtp_connection_cache_on_demand, +lmtp_connection_cache_destinations, or lmtp_connection_reuse_time_limit. +

    + +

    +The effectiveness of cached connections will be determined by the +number of remote LMTP servers in use, and the concurrency limit specified +for the Postfix LMTP client. Cached connections are closed under any of +the following conditions: +

    + +
      + +
    • The Postfix LMTP client idle time limit is reached. This limit is +specified with the Postfix max_idle configuration parameter. + +
    • A delivery request specifies a different destination than the +one currently cached. + +
    • The per-process limit on the number of delivery requests is +reached. This limit is specified with the Postfix max_use +configuration parameter. + +
    • Upon the onset of another delivery request, the remote LMTP server +associated with the current session does not respond to the RSET +command. + +
    + +

    +Most of these limitations have been with the Postfix +a connection cache that is shared among multiple LMTP client +programs. +

    + +%PARAM lmtp_sasl_auth_enable no + +

    +Enable SASL authentication in the Postfix LMTP client. +

    + +%PARAM lmtp_sasl_password_maps + +

    +Optional Postfix LMTP client lookup tables with one username:password entry +per host or domain. If a remote host or domain has no username:password +entry, then the Postfix LMTP client will not attempt to authenticate +to the remote host. +

    + +%PARAM lmtp_sasl_security_options noplaintext, noanonymous + +

    SASL security options; as of Postfix 2.3 the list of available +features depends on the SASL client implementation that is selected +with lmtp_sasl_type.

    + +

    The following security features are defined for the cyrus +client SASL implementation:

    + +
    + +
    noplaintext
    + +
    Disallow authentication methods that use plaintext passwords.
    + +
    noactive
    + +
    Disallow authentication methods that are vulnerable to non-dictionary +active attacks.
    + +
    nodictionary
    + +
    Disallow authentication methods that are vulnerable to passive +dictionary attack.
    + +
    noanonymous
    + +
    Disallow anonymous logins.
    + +
    + +

    +Example: +

    + +
    +lmtp_sasl_security_options = noplaintext
+
    + +%PARAM lmtp_tcp_port 24 + +

    +The default TCP port that the Postfix LMTP client connects to. +Specify a symbolic name (see services(5)) or a numeric port. +

    + +%PARAM smtp_tcp_port smtp + +

    +The default TCP port that the Postfix SMTP client connects to. +Specify a symbolic name (see services(5)) or a numeric port. +

    + +%PARAM mail_release_date see "postconf -d" output + +

    +The Postfix release date, in "YYYYMMDD" format. +

    + +%PARAM mailbox_command_maps + +

    +Optional lookup tables with per-recipient external commands to use +for local(8) mailbox delivery. Behavior is as with mailbox_command. +

    + +

    The precedence of local(8) delivery features from high to low +is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, +mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, +fallback_transport_maps, fallback_transport and luser_relay.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +%PARAM mailbox_delivery_lock see "postconf -d" output + +

    +How to lock a UNIX-style local(8) mailbox before attempting delivery. +For a list of available file locking methods, use the "postconf +-l" command. +

    + +

    +This setting is ignored with maildir style delivery, +because such deliveries are safe without explicit locks. +

    + +

    +Note: The dotlock method requires that the recipient UID or +GID has write access to the parent directory of the mailbox file. +

    + +

    +Note: the default setting of this parameter is system dependent. +

    + +%PARAM mailbox_transport + +

    +Optional message delivery transport that the local(8) delivery +agent should use for mailbox delivery to all local recipients, +whether or not they are found in the UNIX passwd database. +

    + +

    The precedence of local(8) delivery features from high to low +is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, +mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, +fallback_transport_maps, fallback_transport and luser_relay.

    + +%PARAM mailq_path see "postconf -d" output + +

    +Sendmail compatibility feature that specifies where the Postfix +mailq(1) command is installed. This command can be used to +list the Postfix mail queue. +

    + +%PARAM manpage_directory see "postconf -d" output + +

    +Where the Postfix manual pages are installed. +

    + +%PARAM maps_rbl_domains + +

    +Obsolete feature: use the reject_rbl_client feature instead. +

    + +%PARAM mime_boundary_length_limit 2048 + +

    +The maximal length of MIME multipart boundary strings. The MIME +processor is unable to distinguish between boundary strings that +do not differ in the first $mime_boundary_length_limit characters. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM mime_header_checks $header_checks + +

    +Optional lookup tables for content inspection of MIME related +message headers, as described in the header_checks(5) manual page. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM mime_nesting_limit 100 + +

    +The maximal recursion level that the MIME processor will handle. +Postfix refuses mail that is nested deeper than the specified limit. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM mynetworks_style Postfix ≥ 3.0: host, Postfix < 3.0: subnet + +

    +The method to generate the default value for the mynetworks parameter. +This is the list of trusted networks for relay access control etc. +

    + +
      + +

    • Specify "mynetworks_style = host" when Postfix should +"trust" only the local machine.

      + +

    • Specify "mynetworks_style = subnet" when Postfix +should "trust" remote 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 +"trust" remote SMTP clients in the same IP class A/B/C networks as the +local machine. Caution: this may cause +Postfix to "trust" your entire provider's network. Instead, specify +an explicit mynetworks list by hand, as described with the mynetworks +configuration parameter.

      + +
    + +%PARAM nested_header_checks $header_checks + +

    +Optional lookup tables for content inspection of non-MIME message +headers in attached messages, as described in the header_checks(5) +manual page. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM newaliases_path see "postconf -d" output + +

    +Sendmail compatibility feature that specifies the location of the +newaliases(1) command. This command can be used to rebuild the +local(8) aliases(5) database. +

    + +%PARAM non_fqdn_reject_code 504 + +

    +The numerical Postfix SMTP server reply code when a client request +is rejected by the reject_non_fqdn_helo_hostname, reject_non_fqdn_sender +or reject_non_fqdn_recipient restriction. +

    + +%PARAM owner_request_special yes + +

    +Enable special treatment for owner-listname entries in the +aliases(5) file, and don't split owner-listname and +listname-request address localparts when the recipient_delimiter +is set to "-". This feature is useful for mailing lists. +

    + +%PARAM permit_mx_backup_networks + +

    +Restrict the use of the permit_mx_backup SMTP access feature to +only domains whose primary MX hosts match the listed networks. +The parameter value syntax is the same as with the mynetworks +parameter; note, however, that the default value is empty.

    + +

    Pattern matching of domain names is controlled by the presence +or absence of "permit_mx_backup_networks" in the +parent_domain_matches_subdomains parameter value.

    + +%PARAM pickup_service_name pickup + +

    +The name of the pickup(8) service. This service picks up local mail +submissions from the Postfix maildrop queue. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM prepend_delivered_header command, file, forward + +

    The message delivery contexts where the Postfix local(8) delivery +agent prepends a Delivered-To: message header with the address +that the mail was delivered to. This information is used for mail +delivery loop detection.

    + +

    +By default, the Postfix local delivery agent prepends a Delivered-To: +header when forwarding mail and when delivering to file (mailbox) +and command. Turning off the Delivered-To: header when forwarding +mail is not recommended. +

    + +

    +Specify zero or more of forward, file, or command. +

    + +

    +Example: +

    + +
    +prepend_delivered_header = forward
+
    + +%PARAM process_name read-only + +

    +The process name of a Postfix command or daemon process. +

    + +%PARAM service_name read-only + +

    The master.cf service name of a Postfix daemon process. This +can be used to distinguish the logging from different services that +use the same program name.

    + +

    Example master.cf entries:

    + +
    +# Distinguish inbound MTA logging from submission and smtps logging.
+smtp      inet  n       -       n       -       -       smtpd
+submission inet n       -       n       -       -       smtpd
+    -o syslog_name=postfix/$service_name
+smtps     inet  n       -       n       -       -       smtpd
+    -o syslog_name=postfix/$service_name
+
    + +
    +# Distinguish outbound MTA logging from inbound relay logging.
+smtp      unix  -       -       n       -       -       smtp
+relay     unix  -       -       n       -       -       smtp
+    -o syslog_name=postfix/$service_name
+
    + +%PARAM process_id read-only + +

    +The process ID of a Postfix command or daemon process. +

    + +%PARAM process_id_directory pid + +

    +The location of Postfix PID files relative to $queue_directory. +This is a read-only parameter. +

    + +%PARAM proxy_read_maps see "postconf -d" output + +

    +The lookup tables that the proxymap(8) server is allowed to +access for the read-only service. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. +Table references that don't begin with proxy: are ignored. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM proxy_write_maps see "postconf -d" output + +

    The lookup tables that the proxymap(8) server is allowed to +access for the read-write service. Postfix-owned local database +files should be stored under the Postfix-owned data_directory. +Table references that don't begin with proxy: are ignored.

    + +

    +This feature is available in Postfix 2.5 and later. +

    + +%PARAM qmgr_clog_warn_time 300s + +

    +The minimal delay between warnings that a specific destination is +clogging up the Postfix active queue. Specify 0 to disable. +

    + +

    +This feature is enabled with the helpful_warnings parameter. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM qmgr_fudge_factor 100 + +

    +Obsolete feature: the percentage of delivery resources that a busy +mail system will use up for delivery of a large mailing list +message. +

    + +

    +This feature exists only in the oqmgr(8) old queue manager. The +current queue manager solves the problem in a better way. +

    + +%PARAM queue_directory see "postconf -d" output + +

    +The location of the Postfix top-level queue directory. This is the +root directory of Postfix daemon processes that run chrooted. +

    + +%PARAM queue_file_attribute_count_limit 100 + +

    +The maximal number of (name=value) attributes that may be stored +in a Postfix queue file. The limit is enforced by the cleanup(8) +server. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM queue_service_name qmgr + +

    +The name of the qmgr(8) service. This service manages the Postfix +queue and schedules delivery requests. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM html_directory see "postconf -d" output + +

    +The location of Postfix HTML files that describe how to build, +configure or operate a specific Postfix subsystem or feature. +

    + +%PARAM readme_directory see "postconf -d" output + +

    +The location of Postfix README files that describe how to build, +configure or operate a specific Postfix subsystem or feature. +

    + +%PARAM relay_transport relay + +

    +The default mail delivery transport and next-hop destination for +remote delivery to domains listed with $relay_domains. In order of +decreasing precedence, the nexthop destination is taken from +$relay_transport, $sender_dependent_relayhost_maps, $relayhost, or +from the recipient domain. This information can be overruled with +the transport(5) table. +

    + +

    +Specify a string of the form transport:nexthop, where transport +is the name of a mail delivery transport defined in master.cf. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. +

    + +

    +See also the relay domains address class in the ADDRESS_CLASS_README +file. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM rewrite_service_name rewrite + +

    +The name of the address rewriting service. This service rewrites +addresses to standard form and resolves them to a (delivery method, +next-hop host, recipient) triple. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM sample_directory /etc/postfix + +

    +The name of the directory with example Postfix configuration files. +Starting with Postfix 2.1, these files have been replaced with the +postconf(5) manual page. +

    + +%PARAM sender_based_routing no + +

    +This parameter should not be used. It was replaced by sender_dependent_relayhost_maps +in Postfix version 2.3. +

    + +%PARAM sendmail_path see "postconf -d" output + +

    +A Sendmail compatibility feature that specifies the location of +the Postfix sendmail(1) command. This command can be used to +submit mail into the Postfix queue. +

    + +%PARAM service_throttle_time 60s + +

    +How long the Postfix master(8) waits before forking a server that +appears to be malfunctioning. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +%PARAM setgid_group postdrop + +

    +The group ownership of set-gid Postfix commands and of group-writable +Postfix directories. When this parameter value is changed you need +to re-run "postfix set-permissions" (with Postfix version 2.0 and +earlier: "/etc/postfix/post-install set-permissions". +

    + +%PARAM show_user_unknown_table_name yes + +

    +Display the name of the recipient table in the "User unknown" +responses. The extra detail makes troubleshooting easier but also +reveals information that is nobody else's business. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM showq_service_name showq + +

    +The name of the showq(8) service. This service produces mail queue +status reports. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM smtp_pix_workaround_delay_time 10s + +

    +How long the Postfix SMTP client pauses before sending +".<CR><LF>" in order to work around the PIX firewall +"<CR><LF>.<CR><LF>" bug. +

    + +

    +Choosing a too short time makes this workaround ineffective when +sending large messages over slow network connections. +

    + +%PARAM smtp_randomize_addresses yes + +

    +Randomize the order of equal-preference MX host addresses. This +is a performance feature of the Postfix SMTP client. +

    + +%PARAM smtp_rset_timeout 20s + +

    The Postfix SMTP client time limit for sending the RSET command, +and for receiving the remote SMTP server response. The SMTP client +sends RSET in +order to finish a recipient address probe, or to verify that a +cached session is still usable.

    + +

    This feature is available in Postfix 2.1 and later.

    + +%PARAM smtpd_data_restrictions + +

    +Optional access restrictions that the Postfix SMTP server applies +in the context of the SMTP DATA command. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +

    +Specify a list of restrictions, separated by commas and/or whitespace. +Continue long lines by starting the next line with whitespace. +Restrictions are applied in the order as specified; the first +restriction that matches wins. +

    + +

    +The following restrictions are valid in this context: +

    + +
      + +
    • Generic restrictions that can be used +in any SMTP command context, described under smtpd_client_restrictions. + +
    • SMTP command specific restrictions described under +smtpd_client_restrictions, smtpd_helo_restrictions, +smtpd_sender_restrictions or smtpd_recipient_restrictions. + +
    • However, no recipient information is available in the case of +multi-recipient mail. Acting on only one recipient would be misleading, +because any decision will affect all recipients equally. Acting on +all recipients would require a possibly very large amount of memory, +and would also be misleading for the reasons mentioned before. + +
    + +

    +Examples: +

    + +
    +smtpd_data_restrictions = reject_unauth_pipelining
+smtpd_data_restrictions = reject_multi_recipient_bounce
+
    + +%PARAM smtpd_end_of_data_restrictions + +

    Optional access restrictions that the Postfix SMTP server +applies in the context of the SMTP END-OF-DATA command. +See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access +restriction lists" for a discussion of evaluation context and time. +

    + +

    This feature is available in Postfix 2.2 and later.

    + +

    See smtpd_data_restrictions for details and limitations.

    + +%PARAM smtpd_delay_reject yes + +

    +Wait until the RCPT TO command before evaluating +$smtpd_client_restrictions, $smtpd_helo_restrictions and +$smtpd_sender_restrictions, or wait until the ETRN command before +evaluating $smtpd_client_restrictions and $smtpd_helo_restrictions. +

    + +

    +This feature is turned on by default because some clients apparently +mis-behave when the Postfix SMTP server rejects commands before +RCPT TO. +

    + +

    +The default setting has one major benefit: it allows Postfix to log +recipient address information when rejecting a client name/address +or sender address, so that it is possible to find out whose mail +is being rejected. +

    + +%PARAM smtpd_null_access_lookup_key <> + +

    +The lookup key to be used in SMTP access(5) tables instead of the +null sender address. +

    + +%CLASS smtpd-policy SMTP server policy delegation + +

    +The Postfix SMTP server has a number of built-in mechanisms to +block or accept mail at specific SMTP protocol stages. As of version +2.1 Postfix can be configured to delegate policy decisions to an +external server that runs outside Postfix. See the file +SMTPD_POLICY_README for more information. +

    + +%PARAM smtpd_policy_service_max_idle 300s + +

    +The time after which an idle SMTPD policy service connection is +closed. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_policy_service_max_ttl 1000s + +

    +The time after which an active SMTPD policy service connection is +closed. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_policy_service_timeout 100s + +

    +The time limit for connecting to, writing to, or receiving from a +delegated SMTPD policy server. +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_policy_service_request_limit 0 + +

    +The maximal number of requests per SMTPD policy service connection, +or zero (no limit). Once a connection reaches this limit, the +connection is closed and the next request will be sent over a new +connection. This is a workaround to avoid error-recovery delays +with policy servers that cannot maintain a persistent connection. +

    + +

    +This feature is available in Postfix 3.0 and later. +

    + +%PARAM smtpd_reject_unlisted_recipient yes + +

    +Request that the Postfix SMTP server rejects mail for unknown +recipient addresses, even when no explicit reject_unlisted_recipient +access restriction is specified. This prevents the Postfix queue +from filling up with undeliverable MAILER-DAEMON messages. +

    + +

    An address is always considered "known" when it matches a +virtual(5) alias or a canonical(5) mapping. + +

      + +
    • The recipient domain matches $mydestination, $inet_interfaces +or $proxy_interfaces, but the recipient is not listed in +$local_recipient_maps, and $local_recipient_maps is not null. + +
    • The recipient domain matches $virtual_alias_domains but the +recipient is not listed in $virtual_alias_maps. + +
    • The recipient domain matches $virtual_mailbox_domains but the +recipient is not listed in $virtual_mailbox_maps, and $virtual_mailbox_maps +is not null. + +
    • The recipient domain matches $relay_domains but the recipient +is not listed in $relay_recipient_maps, and $relay_recipient_maps +is not null. + +
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_reject_unlisted_sender no + +

    Request that the Postfix SMTP server rejects mail from unknown +sender addresses, even when no explicit reject_unlisted_sender +access restriction is specified. This can slow down an explosion +of forged mail from worms or viruses.

    + +

    An address is always considered "known" when it matches a +virtual(5) alias or a canonical(5) mapping. + +

      + +
    • The sender domain matches $mydestination, $inet_interfaces or +$proxy_interfaces, but the sender is not listed in +$local_recipient_maps, and $local_recipient_maps is not null. + +
    • The sender domain matches $virtual_alias_domains but the sender +is not listed in $virtual_alias_maps. + +
    • The sender domain matches $virtual_mailbox_domains but the +sender is not listed in $virtual_mailbox_maps, and $virtual_mailbox_maps +is not null. + +
    • The sender domain matches $relay_domains but the sender is +not listed in $relay_recipient_maps, and $relay_recipient_maps is +not null. + +
    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM smtpd_restriction_classes + +

    +User-defined aliases for groups of access restrictions. The aliases +can be specified in smtpd_recipient_restrictions etc., and on the +right-hand side of a Postfix access(5) table. +

    + +

    +One major application is for implementing per-recipient UCE control. +See the RESTRICTION_CLASS_README document for other examples. +

    + +%PARAM smtpd_sasl_application_name smtpd + +

    +The application name that the Postfix SMTP server uses for SASL +server initialization. This +controls the name of the SASL configuration file. The default value +is smtpd, corresponding to a SASL configuration file named +smtpd.conf. +

    + +

    +This feature is available in Postfix 2.1 and 2.2. With Postfix 2.3 +it was renamed to smtpd_sasl_path. +

    + +%PARAM strict_7bit_headers no + +

    +Reject mail with 8-bit text in message headers. This blocks mail +from poorly written applications. +

    + +

    +This feature should not be enabled on a general purpose mail server, +because it is likely to reject legitimate email. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM strict_8bitmime no + +

    +Enable both strict_7bit_headers and strict_8bitmime_body. +

    + +

    +This feature should not be enabled on a general purpose mail server, +because it is likely to reject legitimate email. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM strict_8bitmime_body no + +

    +Reject 8-bit message body text without 8-bit MIME content encoding +information. This blocks mail from poorly written applications. +

    + +

    +Unfortunately, this also rejects majordomo approval requests when +the included request contains valid 8-bit MIME mail, and it rejects +bounces from mailers that do not MIME encapsulate 8-bit content +(for example, bounces from qmail or from old versions of Postfix). +

    + +

    +This feature should not be enabled on a general purpose mail server, +because it is likely to reject legitimate email. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM strict_mime_encoding_domain no + +

    +Reject mail with invalid Content-Transfer-Encoding: information +for the message/* or multipart/* MIME content types. This blocks +mail from poorly written software. +

    + +

    +This feature should not be enabled on a general purpose mail server, +because it will reject mail after a single violation. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM sun_mailtool_compatibility no + +

    +Obsolete SUN mailtool compatibility feature. Instead, use +"mailbox_delivery_lock = dotlock". +

    + +%PARAM trace_service_name trace + +

    +The name of the trace service. This service is implemented by the +bounce(8) daemon and maintains a record +of mail deliveries and produces a mail delivery report when verbose +delivery is requested with "sendmail -v". +

    + +

    +This feature is available in Postfix 2.1 and later. +

    + +%PARAM undisclosed_recipients_header see "postconf -d" output + +

    +Message header that the Postfix cleanup(8) server inserts when a +message contains no To: or Cc: message header. With Postfix 2.8 +and later, the default value is empty. With Postfix 2.4-2.7, +specify an empty value to disable this feature.

    + +

    Example:

    + +
    +# Default value before Postfix 2.8.
+# Note: the ":" and ";" are both required.
+undisclosed_recipients_header = To: undisclosed-recipients:;
+
    + +%PARAM unknown_relay_recipient_reject_code 550 + +

    +The numerical Postfix SMTP server reply code when a recipient +address matches $relay_domains, and relay_recipient_maps specifies +a list of lookup tables that does not match the recipient address. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM unknown_virtual_alias_reject_code 550 + +

    +The Postfix SMTP server reply code when a recipient address matches +$virtual_alias_domains, and $virtual_alias_maps specifies a list +of lookup tables that does not match the recipient address. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM unknown_virtual_mailbox_reject_code 550 + +

    +The Postfix SMTP server reply code when a recipient address matches +$virtual_mailbox_domains, and $virtual_mailbox_maps specifies a list +of lookup tables that does not match the recipient address. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM verp_delimiter_filter -=+ + +

    +The characters Postfix accepts as VERP delimiter characters on the +Postfix sendmail(1) command line and in SMTP commands. +

    + +

    +This feature is available in Postfix 1.1 and later. +

    + +%PARAM virtual_gid_maps + +

    +Lookup tables with the per-recipient group ID for virtual(8) mailbox +delivery. +

    + +

    This parameter is specific to the virtual(8) delivery agent. +It does not apply when mail is delivered with a different mail +delivery program.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +In a lookup table, specify a left-hand side of "@domain.tld" to +match any user in the specified domain that does not have a specific +"user@domain.tld" entry. +

    + +

    +When a recipient address has an optional address extension +(user+foo@domain.tld), the virtual(8) delivery agent looks up +the full address first, and when the lookup fails, it looks up the +unextended address (user@domain.tld). +

    + +

    +Note 1: for security reasons, the virtual(8) delivery agent disallows +regular expression substitution of $1 etc. in regular expression +lookup tables, because that would open a security hole. +

    + +

    +Note 2: for security reasons, the virtual(8) delivery agent will +silently ignore requests to use the proxymap(8) server. Instead +it will open the table directly. Before Postfix version 2.2, the +virtual(8) delivery agent will terminate with a fatal error. +

    + +%PARAM virtual_mailbox_base + +

    +A prefix that the virtual(8) delivery agent prepends to all pathname +results from $virtual_mailbox_maps table lookups. This is a safety +measure to ensure that an out of control map doesn't litter the +file system with mailboxes. While virtual_mailbox_base could be +set to "/", this setting isn't recommended. +

    + +

    This parameter is specific to the virtual(8) delivery agent. +It does not apply when mail is delivered with a different mail +delivery program.

    + +

    +Example: +

    + +
    +virtual_mailbox_base = /var/mail
+
    + +%PARAM virtual_mailbox_domains $virtual_mailbox_maps + +

    Postfix is final destination for the specified list of domains; +mail is delivered via the $virtual_transport mail delivery transport. +By default this is the Postfix virtual(8) delivery agent. The SMTP +server validates recipient addresses with $virtual_mailbox_maps +and rejects mail for non-existent recipients. See also the virtual +mailbox domain class in the ADDRESS_CLASS_README file.

    + +

    This parameter expects the same syntax as the mydestination +configuration parameter.

    + +

    +This feature is available in Postfix 2.0 and later. The default +value is backwards compatible with Postfix version 1.1. +

    + +%PARAM virtual_mailbox_limit 51200000 + +

    +The maximal size in bytes of an individual virtual(8) mailbox or +maildir file, or zero (no limit).

    + +

    This parameter is specific to the virtual(8) delivery agent. +It does not apply when mail is delivered with a different mail +delivery program.

    + +%PARAM virtual_mailbox_lock see "postconf -d" output + +

    +How to lock a UNIX-style virtual(8) mailbox before attempting +delivery. For a list of available file locking methods, use the +"postconf -l" command. +

    + +

    This parameter is specific to the virtual(8) delivery agent. +It does not apply when mail is delivered with a different mail +delivery program.

    + +

    +This setting is ignored with maildir style delivery, because +such deliveries are safe without application-level locks. +

    + +

    +Note 1: the dotlock method requires that the recipient UID +or GID has write access to the parent directory of the recipient's +mailbox file. +

    + +

    +Note 2: the default setting of this parameter is system dependent. +

    + +%PARAM virtual_mailbox_maps + +

    +Optional lookup tables with all valid addresses in the domains that +match $virtual_mailbox_domains. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +In a lookup table, specify a left-hand side of "@domain.tld" to +match any user in the specified domain that does not have a specific +"user@domain.tld" entry. +

    + +

    The remainder of this text is specific to the virtual(8) delivery +agent. It does not apply when mail is delivered with a different +mail delivery program.

    + +

    +The virtual(8) delivery agent uses this table to look up the +per-recipient mailbox or maildir pathname. If the lookup result +ends in a slash ("/"), maildir-style delivery is carried out, +otherwise the path is assumed to specify a UNIX-style mailbox file. +Note that $virtual_mailbox_base is unconditionally prepended to +this path. +

    + +

    +When a recipient address has an optional address extension +(user+foo@domain.tld), the virtual(8) delivery agent looks up +the full address first, and when the lookup fails, it looks up the +unextended address (user@domain.tld). +

    + +

    +Note 1: for security reasons, the virtual(8) delivery agent disallows +regular expression substitution of $1 etc. in regular expression +lookup tables, because that would open a security hole. +

    + +

    +Note 2: for security reasons, the virtual(8) delivery agent will +silently ignore requests to use the proxymap(8) server. Instead +it will open the table directly. Before Postfix version 2.2, the +virtual(8) delivery agent will terminate with a fatal error. +

    + +%PARAM virtual_minimum_uid 100 + +

    +The minimum user ID value that the virtual(8) delivery agent accepts +as a result from $virtual_uid_maps table lookup. Returned +values less than this will be rejected, and the message will be +deferred. +

    + +

    This parameter is specific to the virtual(8) delivery agent. +It does not apply when mail is delivered with a different mail +delivery program.

    + +%PARAM virtual_transport virtual + +

    +The default mail delivery transport and next-hop destination for +final delivery to domains listed with $virtual_mailbox_domains. +This information can be overruled with the transport(5) table. +

    + +

    +Specify a string of the form transport:nexthop, where transport +is the name of a mail delivery transport defined in master.cf. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. +

    + +

    +This feature is available in Postfix 2.0 and later. +

    + +%PARAM virtual_uid_maps + +

    +Lookup tables with the per-recipient user ID that the virtual(8) +delivery agent uses while writing to the recipient's mailbox. +

    + +

    This parameter is specific to the virtual(8) delivery agent. +It does not apply when mail is delivered with a different mail +delivery program.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    +In a lookup table, specify a left-hand side of "@domain.tld" +to match any user in the specified domain that does not have a +specific "user@domain.tld" entry. +

    + +

    +When a recipient address has an optional address extension +(user+foo@domain.tld), the virtual(8) delivery agent looks up +the full address first, and when the lookup fails, it looks up the +unextended address (user@domain.tld). +

    + +

    +Note 1: for security reasons, the virtual(8) delivery agent disallows +regular expression substitution of $1 etc. in regular expression +lookup tables, because that would open a security hole. +

    + +

    +Note 2: for security reasons, the virtual(8) delivery agent will +silently ignore requests to use the proxymap(8) server. Instead +it will open the table directly. Before Postfix version 2.2, the +virtual(8) delivery agent will terminate with a fatal error. +

    + +%PARAM config_directory see "postconf -d" output + +

    The default location of the Postfix main.cf and master.cf +configuration files. This can be overruled via the following +mechanisms:

    + +
      + +

    • The MAIL_CONFIG environment variable (daemon processes +and commands).

      + +

    • The "-c" command-line option (commands only).

      + +
    + +

    With Postfix command that run with set-gid privileges, a +config_directory override requires either root privileges, or it +requires that the directory is listed with the alternate_config_directories +parameter in the default main.cf file.

    + +%PARAM virtual_maps + +

    Optional lookup tables with a) names of domains for which all +addresses are aliased to addresses in other local or remote domains, +and b) addresses that are aliased to addresses in other local or +remote domains. Available before Postfix version 2.0. With Postfix +version 2.0 and later, this is replaced by separate controls: virtual_alias_domains +and virtual_alias_maps.

    + +%PARAM smtp_discard_ehlo_keywords + +

    A case insensitive list of EHLO keywords (pipelining, starttls, +auth, etc.) that the Postfix SMTP client will ignore in the EHLO +response from a remote SMTP server.

    + +

    This feature is available in Postfix 2.2 and later.

    + +

    Notes:

    + +
      + +

    • Specify the silent-discard pseudo keyword to prevent +this action from being logged.

      + +

    • Use the smtp_discard_ehlo_keyword_address_maps feature to +discard EHLO keywords selectively.

      + +
    + +%PARAM smtpd_discard_ehlo_keywords + +

    A case insensitive list of EHLO keywords (pipelining, starttls, +auth, etc.) that the Postfix SMTP server will not send in the EHLO +response +to a remote SMTP client.

    + +

    This feature is available in Postfix 2.2 and later.

    + +

    Notes:

    + +
      + +

    • Specify the silent-discard pseudo keyword to prevent +this action from being logged.

      + +

    • Use the smtpd_discard_ehlo_keyword_address_maps feature +to discard EHLO keywords selectively.

      + +
    + +%PARAM smtp_discard_ehlo_keyword_address_maps + +

    Lookup tables, indexed by the remote SMTP server address, with +case insensitive lists of EHLO keywords (pipelining, starttls, auth, +etc.) that the Postfix SMTP client will ignore in the EHLO response from a +remote SMTP server. See smtp_discard_ehlo_keywords for details. The +table is not indexed by hostname for consistency with +smtpd_discard_ehlo_keyword_address_maps.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_discard_ehlo_keyword_address_maps + +

    Lookup tables, indexed by the remote SMTP client address, with +case insensitive lists of EHLO keywords (pipelining, starttls, auth, +etc.) that the Postfix SMTP server will not send in the EHLO response +to a +remote SMTP client. See smtpd_discard_ehlo_keywords for details. +The tables are not searched by hostname for robustness reasons.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM connection_cache_service_name scache + +

    The name of the scache(8) connection cache service. This service +maintains a limited pool of cached sessions.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM connection_cache_ttl_limit 2s + +

    The maximal time-to-live value that the scache(8) connection +cache server +allows. Requests that specify a larger TTL will be stored with the +maximum allowed TTL. The purpose of this additional control is to +protect the infrastructure against careless people. The cache TTL +is already bounded by $max_idle.

    + +%PARAM connection_cache_status_update_time 600s + +

    How frequently the scache(8) server logs usage statistics with +connection cache hit and miss rates for logical destinations and for +physical endpoints.

    + +%PARAM remote_header_rewrite_domain + +

    Don't rewrite message headers from remote clients at all when +this parameter is empty; otherwise, rewrite message headers and +append the specified domain name to incomplete addresses. The +local_header_rewrite_clients parameter controls what clients Postfix +considers local.

    + +

    Examples:

    + +

    The safe setting: append "domain.invalid" to incomplete header +addresses from remote SMTP clients, so that those addresses cannot +be confused with local addresses.

    + +
    +
     
+remote_header_rewrite_domain = domain.invalid
+
    +
    + +

    The default, purist, setting: don't rewrite headers from remote +clients at all.

    + +
    +
    +remote_header_rewrite_domain =
+
    +
    + +%PARAM local_header_rewrite_clients permit_inet_interfaces + +

    Rewrite message header addresses in mail from these clients and +update incomplete addresses with the domain name in $myorigin or +$mydomain; either don't rewrite message headers from other clients +at all, or rewrite message headers and update incomplete addresses +with the domain specified in the remote_header_rewrite_domain +parameter.

    + +

    See the append_at_myorigin and append_dot_mydomain parameters +for details of how domain names are appended to incomplete addresses. +

    + +

    Specify a list of zero or more of the following:

    + +
    + +
    permit_inet_interfaces
    + +
    Append the domain name in $myorigin or $mydomain when the +client IP address matches $inet_interfaces. This is enabled by +default.
    + +
    permit_mynetworks
    + +
    Append the domain name in $myorigin or $mydomain when the +client IP address matches any network or network address listed in +$mynetworks. This setting will not prevent remote mail header +address rewriting when mail from a remote client is forwarded by +a neighboring system.
    + +
    permit_sasl_authenticated
    + +
    Append the domain name in $myorigin or $mydomain when the +client is successfully authenticated via the RFC 4954 (AUTH) +protocol.
    + +
    permit_tls_clientcerts
    + +
    Append the domain name in $myorigin or $mydomain when the +remote SMTP client TLS certificate fingerprint or public key fingerprint +(Postfix 2.9 and later) is listed in $relay_clientcerts. +The fingerprint digest algorithm is configurable via the +smtpd_tls_fingerprint_digest parameter (hard-coded as md5 prior to +Postfix version 2.5).
    + +
    permit_tls_all_clientcerts
    + +
    Append the domain name in $myorigin or $mydomain when the +remote SMTP client TLS certificate is successfully verified, regardless of +whether it is listed on the server, and regardless of the certifying +authority.
    + +
    check_address_map type:table
    + +
    type:table
    + +
    Append the domain name in $myorigin or $mydomain when the +client IP address matches the specified lookup table. +The lookup result is ignored, and no subnet lookup is done. This +is suitable for, e.g., pop-before-smtp lookup tables.
    + +
    + +

    Examples:

    + +

    The Postfix < 2.2 backwards compatible setting: always rewrite +message headers, and always append my own domain to incomplete +header addresses.

    + +
    +
     
+local_header_rewrite_clients = static:all
+
    +
    + +

    The purist (and default) setting: rewrite headers only in mail +from Postfix sendmail and in SMTP mail from this machine.

    + +
    +
    +local_header_rewrite_clients = permit_inet_interfaces
+
    +
    + +

    The intermediate setting: rewrite header addresses and append +$myorigin or $mydomain information only with mail from Postfix +sendmail, from local clients, or from authorized SMTP clients.

    + +

    Note: this setting will not prevent remote mail header address +rewriting when mail from a remote client is forwarded by a neighboring +system.

    + +
    +
    +local_header_rewrite_clients = permit_mynetworks, 
+    permit_sasl_authenticated permit_tls_clientcerts
+    check_address_map hash:/etc/postfix/pop-before-smtp 
+
    +
    + +%PARAM smtpd_tls_cert_file + +

    File with the Postfix SMTP server RSA certificate in PEM format. +This file may also contain the Postfix SMTP server private RSA key. +With Postfix ≥ 3.4 the preferred way to configure server keys and +certificates is via the "smtpd_tls_chain_files" parameter.

    + +

    Public Internet MX hosts without certificates signed by a "reputable" +CA must generate, and be prepared to present to most clients, a +self-signed or private-CA signed certificate. The client will not be +able to authenticate the server, but unless it is running Postfix 2.3 or +similar software, it will still insist on a server certificate.

    + +

    For servers that are not public Internet MX hosts, Postfix +supports configurations with no certificates. This entails the use of +just the anonymous TLS ciphers, which are not supported by typical SMTP +clients. Since some clients may not fall back to plain text after a TLS +handshake failure, a certificate-less Postfix SMTP server will be unable +to receive email from some TLS-enabled clients. To avoid accidental +configurations with no certificates, Postfix enables certificate-less +operation only when the administrator explicitly sets +"smtpd_tls_cert_file = none". This ensures that new Postfix SMTP server +configurations will not accidentally enable TLS without certificates.

    + +

    Note that server certificates are not optional in TLS 1.3. To run +without certificates you'd have to disable the TLS 1.3 protocol by +including '!TLSv1.3' in "smtpd_tls_protocols" and perhaps also +"smtpd_tls_mandatory_protocols". It is simpler instead to just +configure a certificate chain. Certificate-less operation is not +recommended.

    + +

    Both RSA and DSA certificates are supported. When both types +are present, the cipher used determines which certificate will be +presented to the client. For Netscape and OpenSSL clients without +special cipher choices the RSA certificate is preferred.

    + +

    To enable a remote SMTP client to verify the Postfix SMTP server +certificate, the issuing CA certificates must be made available to the +client. You should include the required certificates in the server +certificate file, the server certificate first, then the issuing +CA(s) (bottom-up order).

    + +

    Example: the certificate for "server.example.com" was issued by +"intermediate CA" which itself has a certificate of "root CA". +Create the server.pem file with "cat server_cert.pem intermediate_CA.pem +root_CA.pem > server.pem".

    + +

    If you also want to verify client certificates issued by these +CAs, you can add the CA certificates to the smtpd_tls_CAfile, in which +case it is not necessary to have them in the smtpd_tls_cert_file, +smtpd_tls_dcert_file (obsolete) or smtpd_tls_eccert_file.

    + +

    A certificate supplied here must be usable as an SSL server certificate +and hence pass the "openssl verify -purpose sslserver ..." test.

    + +

    Example:

    + +
    +smtpd_tls_cert_file = /etc/postfix/server.pem
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_key_file $smtpd_tls_cert_file + +

    File with the Postfix SMTP server RSA private key in PEM format. +This file may be combined with the Postfix SMTP server RSA certificate +file specified with $smtpd_tls_cert_file. With Postfix ≥ 3.4 the +preferred way to configure server keys and certificates is via the +"smtpd_tls_chain_files" parameter.

    + +

    The private key must be accessible without a pass-phrase, i.e. it +must not be encrypted. File permissions should grant read-only +access to the system superuser account ("root"), and no access +to anyone else.

    + +%PARAM smtpd_tls_dcert_file + +

    File with the Postfix SMTP server DSA certificate in PEM format. +This file may also contain the Postfix SMTP server private DSA key. +The DSA algorithm is obsolete and should not be used.

    + +

    See the discussion under smtpd_tls_cert_file for more details. +

    + +

    Example:

    + +
    +smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_dkey_file $smtpd_tls_dcert_file + +

    File with the Postfix SMTP server DSA private key in PEM format. +This file may be combined with the Postfix SMTP server DSA certificate +file specified with $smtpd_tls_dcert_file. The DSA algorithm is obsolete +and should not be used.

    + +

    The private key must be accessible without a pass-phrase, i.e. it +must not be encrypted. File permissions should grant read-only +access to the system superuser account ("root"), and no access +to anyone else.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_CAfile + +

    A file containing (PEM format) CA certificates of root CAs trusted +to sign either remote SMTP client certificates or intermediate CA +certificates. These are loaded into memory before the smtpd(8) server +enters the chroot jail. If the number of trusted roots is large, consider +using smtpd_tls_CApath instead, but note that the latter directory must +be present in the chroot jail if the smtpd(8) server is chrooted. This +file may also be used to augment the server certificate trust chain, +but it is best to include all the required certificates directly in the +server certificate file.

    + +

    Specify "smtpd_tls_CAfile = /path/to/system_CA_file" to use ONLY +the system-supplied default Certification Authority certificates. +

    + +

    Specify "tls_append_default_CA = no" to prevent Postfix from +appending the system-supplied default CAs and trusting third-party +certificates.

    + +

    By default (see smtpd_tls_ask_ccert), client certificates are not +requested, and smtpd_tls_CAfile should remain empty. If you do make use +of client certificates, the distinguished names (DNs) of the Certification +Authorities listed in smtpd_tls_CAfile are sent to the remote SMTP client +in the client certificate request message. MUAs with multiple client +certificates may use the list of preferred Certification Authorities +to select the correct client certificate. You may want to put your +"preferred" CA or CAs in this file, and install other trusted CAs in +$smtpd_tls_CApath.

    + +

    Example:

    + +
    +smtpd_tls_CAfile = /etc/postfix/CAcert.pem
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_CApath + +

    A directory containing (PEM format) CA certificates of root CAs +trusted to sign either remote SMTP client certificates or intermediate CA +certificates. Do not forget to create the necessary "hash" links with, +for example, "$OPENSSL_HOME/bin/c_rehash /etc/postfix/certs". To use +smtpd_tls_CApath in chroot mode, this directory (or a copy) must be +inside the chroot jail.

    + +

    Specify "smtpd_tls_CApath = /path/to/system_CA_directory" to +use ONLY the system-supplied default Certification Authority certificates. +

    + +

    Specify "tls_append_default_CA = no" to prevent Postfix from +appending the system-supplied default CAs and trusting third-party +certificates.

    + +

    By default (see smtpd_tls_ask_ccert), client certificates are +not requested, and smtpd_tls_CApath should remain empty. In contrast +to smtpd_tls_CAfile, DNs of Certification Authorities installed +in $smtpd_tls_CApath are not included in the client certificate +request message. MUAs with multiple client certificates may use the +list of preferred Certification Authorities to select the correct +client certificate. You may want to put your "preferred" CA or +CAs in $smtpd_tls_CAfile, and install the remaining trusted CAs in +$smtpd_tls_CApath.

    + +

    Example:

    + +
    +smtpd_tls_CApath = /etc/postfix/certs
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_loglevel 0 + +

    Enable additional Postfix SMTP server logging of TLS activity. +Each logging level also includes the information that is logged at +a lower logging level.

    + +
    + +
    0 Disable logging of TLS activity.
    + +
    1 Log only a summary message on TLS handshake completion +— no logging of client certificate trust-chain verification errors +if client certificate verification is not required. With Postfix 2.8 and +earlier, log the summary message, peer certificate summary information +and unconditionally log trust-chain verification errors.
    + +
    2 Also log levels during TLS negotiation.
    + +
    3 Also log hexadecimal and ASCII dump of TLS negotiation +process.
    + +
    4 Also log hexadecimal and ASCII dump of complete +transmission after STARTTLS.
    + +
    + +

    Do not use "smtpd_tls_loglevel = 2" or higher except in case +of problems. Use of loglevel 4 is strongly discouraged.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_received_header no + +

    Request that the Postfix SMTP server produces Received: message +headers that include information about the protocol and cipher used, +as well as the remote SMTP client CommonName and client certificate issuer +CommonName. This is disabled by default, as the information may +be modified in transit through other mail servers. Only information +that was recorded by the final destination can be trusted.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_use_tls no + +

    Opportunistic TLS: announce STARTTLS support to remote SMTP clients, +but do not require that clients use TLS encryption.

    + +

    Note: when invoked via "sendmail -bs", Postfix will never offer +STARTTLS due to insufficient privileges to access the server private +key. This is intended behavior.

    + +

    This feature is available in Postfix 2.2 and later. With +Postfix 2.3 and later use smtpd_tls_security_level instead.

    + +%PARAM smtpd_enforce_tls no + +

    Mandatory TLS: announce STARTTLS support to remote SMTP clients, +and require that clients use TLS encryption. According to RFC 2487 +this MUST NOT be applied in case of a publicly-referenced SMTP +server. This option is therefore off by default.

    + +

    Note 1: "smtpd_enforce_tls = yes" implies "smtpd_tls_auth_only = yes".

    + +

    Note 2: when invoked via "sendmail -bs", Postfix will never offer +STARTTLS due to insufficient privileges to access the server private +key. This is intended behavior.

    + +

    This feature is available in Postfix 2.2 and later. With +Postfix 2.3 and later use smtpd_tls_security_level instead.

    + +%PARAM smtpd_tls_wrappermode no + +

    Run the Postfix SMTP server in the non-standard "wrapper" mode, +instead of using the STARTTLS command.

    + +

    If you want to support this service, enable a special port in +master.cf, and specify "-o smtpd_tls_wrappermode=yes" on the SMTP +server's command line. Port 465 (smtps) was once chosen for this +purpose.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_ask_ccert no + +

    Ask a remote SMTP client for a client certificate. This +information is needed for certificate based mail relaying with, +for example, the permit_tls_clientcerts feature.

    + +

    Some clients such as Netscape will either complain if no +certificate is available (for the list of CAs in $smtpd_tls_CAfile) +or will offer multiple client certificates to choose from. This +may be annoying, so this option is "off" by default.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_req_ccert no + +

    With mandatory TLS encryption, require a trusted remote SMTP client +certificate in order to allow TLS connections to proceed. This +option implies "smtpd_tls_ask_ccert = yes".

    + +

    When TLS encryption is optional, this setting is ignored with +a warning written to the mail log.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_ccert_verifydepth 9 + +

    The verification depth for remote SMTP client certificates. A +depth of 1 is sufficient if the issuing CA is listed in a local CA +file.

    + +

    The default verification depth is 9 (the OpenSSL default) for +compatibility with earlier Postfix behavior. Prior to Postfix 2.5, +the default value was 5, but the limit was not actually enforced. If +you have set this to a lower non-default value, certificates with longer +trust chains may now fail to verify. Certificate chains with 1 or 2 +CAs are common, deeper chains are more rare and any number between 5 +and 9 should suffice in practice. You can choose a lower number if, +for example, you trust certificates directly signed by an issuing CA +but not any CAs it delegates to.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_auth_only no + +

    When TLS encryption is optional in the Postfix SMTP server, do +not announce or accept SASL authentication over unencrypted +connections.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_session_cache_database + +

    Name of the file containing the optional Postfix SMTP server +TLS session cache. Specify a database type that supports enumeration, +such as btree or sdbm; there is no need to support +concurrent access. The file is created if it does not exist. The smtpd(8) +daemon does not use this parameter directly, rather the cache is +implemented indirectly in the tlsmgr(8) daemon. This means that +per-smtpd-instance master.cf overrides of this parameter are not +effective. Note, that each of the cache databases supported by tlsmgr(8) +daemon: $smtpd_tls_session_cache_database, $smtp_tls_session_cache_database +(and with Postfix 2.3 and later $lmtp_tls_session_cache_database), needs to be +stored separately. It is not at this time possible to store multiple +caches in a single database.

    + +

    Note: dbm databases are not suitable. TLS +session objects are too large.

    + +

    As of version 2.5, Postfix no longer uses root privileges when +opening this file. The file should now be stored under the Postfix-owned +data_directory. As a migration aid, an attempt to open the file +under a non-Postfix directory is redirected to the Postfix-owned +data_directory, and a warning is logged.

    + + +

    As of Postfix 2.11 the preferred mechanism for session resumption +is RFC 5077 TLS session tickets, which don't require server-side +storage. Consequently, for Postfix ≥ 2.11 this parameter should +generally be left empty. TLS session tickets require an OpenSSL +library (at least version 0.9.8h) that provides full support for +this TLS extension. See also smtpd_tls_session_cache_timeout.

    + +

    Example:

    + +
    +smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_tls_session_cache_timeout 3600s + +

    The expiration time of Postfix SMTP server TLS session cache +information. A cache cleanup is performed periodically +every $smtpd_tls_session_cache_timeout seconds. As with +$smtpd_tls_session_cache_database, this parameter is implemented in the +tlsmgr(8) daemon and therefore per-smtpd-instance master.cf overrides +are not possible.

    + +

    As of Postfix 2.11 this setting cannot exceed 100 days. If set +≤ 0, session caching is disabled, not just via the database, but +also via RFC 5077 TLS session tickets, which don't require server-side +storage. If set to a positive value less than 2 minutes, the minimum +value of 2 minutes is used instead. TLS session tickets require +an OpenSSL library (at least version 0.9.8h) that provides full +support for this TLS extension.

    + +

    This feature is available in Postfix 2.2 and later, and updated +for TLS session ticket support in Postfix 2.11.

    + +%PARAM relay_clientcerts + +

    List of tables with remote SMTP client-certificate fingerprints or +public key fingerprints (Postfix 2.9 and later) for which the Postfix +SMTP server will allow access with the permit_tls_clientcerts +feature. The fingerprint digest algorithm is configurable via the +smtpd_tls_fingerprint_digest parameter (hard-coded as md5 prior to +Postfix version 2.5).

    + +

    Postfix lookup tables are in the form of (key, value) pairs. +Since we only need the key, the value can be chosen freely, e.g. +the name of the user or host: +D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home

    + +

    Example:

    + +
    +relay_clientcerts = hash:/etc/postfix/relay_clientcerts
+
    + +

    For more fine-grained control, use check_ccert_access to select +an appropriate access(5) policy for each client. +See RESTRICTION_CLASS_README.

    + +

    Note: Postfix 2.9.0–2.9.5 computed the public key +fingerprint incorrectly. To use public-key fingerprints, upgrade +to Postfix 2.9.6 or later.

    + +

    This feature is available with Postfix version 2.2.

    + +%PARAM smtpd_tls_cipherlist + +

    Obsolete Postfix < 2.3 control for the Postfix SMTP server TLS +cipher list. It is easy to create interoperability problems by choosing +a non-default cipher list. Do not use a non-default TLS cipherlist for +MX hosts on the public Internet. Clients that begin the TLS handshake, +but are unable to agree on a common cipher, may not be able to send any +email to the SMTP server. Using a restricted cipher list may be more +appropriate for a dedicated MSA or an internal mailhub, where one can +exert some control over the TLS software and settings of the connecting +clients.

    + +

    Note: do not use "" quotes around the parameter value.

    + +

    This feature is available with Postfix version 2.2. It is not used with +Postfix 2.3 and later; use smtpd_tls_mandatory_ciphers instead.

    + +%PARAM smtpd_tls_dh1024_param_file + +

    File with DH parameters that the Postfix SMTP server should +use with non-export EDH ciphers.

    + +

    Instead of using the exact same parameter sets as distributed +with other TLS packages, it is more secure to generate your own +set of parameters with something like the following commands:

    + +
    +
    +openssl dhparam -out /etc/postfix/dh512.pem 512
+openssl dhparam -out /etc/postfix/dh1024.pem 1024
+openssl dhparam -out /etc/postfix/dh2048.pem 2048
+
    +
    + +

    It is safe to share the same DH parameters between multiple +Postfix instances. If you prefer, you can generate separate +parameters for each instance.

    + +

    If you want to take maximal advantage of ciphers that offer forward secrecy see +the Getting +started section of FORWARD_SECRECY_README. The +full document conveniently presents all information about Postfix +"perfect" forward secrecy support in one place: what forward secrecy +is, how to tweak settings, and what you can expect to see when +Postfix uses ciphers with forward secrecy.

    + +

    Example:

    + +
    +smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
+
    + +

    This feature is available with Postfix version 2.2.

    + +%PARAM smtpd_tls_dh512_param_file + +

    File with DH parameters that the Postfix SMTP server should +use with export-grade EDH ciphers. The default SMTP server cipher +grade is "medium" with Postfix releases after the middle of 2015, +and as a result export-grade cipher suites are by default not used. +

    + +

    See also the discussion under the smtpd_tls_dh1024_param_file +configuration parameter.

    + +

    Example:

    + +
    +smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
+
    + +

    This feature is available with Postfix version 2.2.

    + +%PARAM smtpd_starttls_timeout see "postconf -d" output + +

    The time limit for Postfix SMTP server write and read operations +during TLS startup and shutdown handshake procedures. The current +default value is stress-dependent. Before Postfix version 2.8, it +was fixed at 300s.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_cert_file + +

    File with the Postfix SMTP client RSA certificate in PEM format. +This file may also contain the Postfix SMTP client private RSA key, and +these may be the same as the Postfix SMTP server RSA certificate and key +file. With Postfix ≥ 3.4 the preferred way to configure client keys +and certificates is via the "smtp_tls_chain_files" parameter.

    + +

    Do not configure client certificates unless you must present +client TLS certificates to one or more servers. Client certificates are +not usually needed, and can cause problems in configurations that work +well without them. The recommended setting is to let the defaults stand:

    + +
    +
    +smtp_tls_cert_file =
+smtp_tls_key_file =
+smtp_tls_eccert_file =
+smtp_tls_eckey_file =
+# Obsolete DSA parameters
+smtp_tls_dcert_file =
+smtp_tls_dkey_file =
+# Postfix ≥ 3.4 interface
+smtp_tls_chain_files =
+
    +
    + +

    The best way to use the default settings is to comment out the above +parameters in main.cf if present.

    + +

    To enable remote SMTP servers to verify the Postfix SMTP client +certificate, the issuing CA certificates must be made available to the +server. You should include the required certificates in the client +certificate file, the client certificate first, then the issuing +CA(s) (bottom-up order).

    + +

    Example: the certificate for "client.example.com" was issued by +"intermediate CA" which itself has a certificate issued by "root CA". +As the "root" super-user create the client.pem file with:

    + +
    +
    +# umask 077
+# cat client_key.pem client_cert.pem intermediate_CA.pem > chain.pem 
+
    +
    + +

    If you also want to verify remote SMTP server certificates issued by +these CAs, you can add the CA certificates to the smtp_tls_CAfile, in +which case it is not necessary to have them in the smtp_tls_cert_file, +smtp_tls_dcert_file (obsolete) or smtp_tls_eccert_file.

    + +

    A certificate supplied here must be usable as an SSL client certificate +and hence pass the "openssl verify -purpose sslclient ..." test.

    + +

    Example:

    + +
    +smtp_tls_cert_file = /etc/postfix/chain.pem
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_key_file $smtp_tls_cert_file + +

    File with the Postfix SMTP client RSA private key in PEM format. +This file may be combined with the Postfix SMTP client RSA certificate +file specified with $smtp_tls_cert_file. With Postfix ≥ 3.4 the +preferred way to configure client keys and certificates is via the +"smtp_tls_chain_files" parameter.

    + +

    The private key must be accessible without a pass-phrase, i.e. it +must not be encrypted. File permissions should grant read-only +access to the system superuser account ("root"), and no access +to anyone else.

    + +

    Example:

    + +
    +smtp_tls_key_file = $smtp_tls_cert_file
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_CAfile + +

    A file containing CA certificates of root CAs trusted to sign +either remote SMTP server certificates or intermediate CA certificates. +These are loaded into memory before the smtp(8) client enters the +chroot jail. If the number of trusted roots is large, consider using +smtp_tls_CApath instead, but note that the latter directory must be +present in the chroot jail if the smtp(8) client is chrooted. This +file may also be used to augment the client certificate trust chain, +but it is best to include all the required certificates directly in +$smtp_tls_cert_file (or, Postfix ≥ 3.4 $smtp_tls_chain_files).

    + +

    Specify "smtp_tls_CAfile = /path/to/system_CA_file" to use +ONLY the system-supplied default Certification Authority certificates. +

    + +

    Specify "tls_append_default_CA = no" to prevent Postfix from +appending the system-supplied default CAs and trusting third-party +certificates.

    + +

    Example:

    + +
    +smtp_tls_CAfile = /etc/postfix/CAcert.pem
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_CApath + +

    Directory with PEM format Certification Authority certificates +that the Postfix SMTP client uses to verify a remote SMTP server +certificate. Don't forget to create the necessary "hash" links +with, for example, "$OPENSSL_HOME/bin/c_rehash /etc/postfix/certs". +

    + +

    To use this option in chroot mode, this directory (or a copy) +must be inside the chroot jail.

    + +

    Specify "smtp_tls_CApath = /path/to/system_CA_directory" to +use ONLY the system-supplied default Certification Authority certificates. +

    + +

    Specify "tls_append_default_CA = no" to prevent Postfix from +appending the system-supplied default CAs and trusting third-party +certificates.

    + +

    Example:

    + +
    +smtp_tls_CApath = /etc/postfix/certs
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_loglevel 0 + +

    Enable additional Postfix SMTP client logging of TLS activity. +Each logging level also includes the information that is logged at +a lower logging level.

    + +
    + +
    0 Disable logging of TLS activity.
    + +
    1 Log only a summary message on TLS handshake completion +— no logging of remote SMTP server certificate trust-chain +verification errors if server certificate verification is not required. +With Postfix 2.8 and earlier, log the summary message and unconditionally +log trust-chain verification errors.
    + +
    2 Also log levels during TLS negotiation.
    + +
    3 Also log hexadecimal and ASCII dump of TLS negotiation +process.
    + +
    4 Also log hexadecimal and ASCII dump of complete +transmission after STARTTLS.
    + +
    + +

    Do not use "smtp_tls_loglevel = 2" or higher except in case of +problems. Use of loglevel 4 is strongly discouraged.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_session_cache_database + +

    Name of the file containing the optional Postfix SMTP client +TLS session cache. Specify a database type that supports enumeration, +such as btree or sdbm; there is no need to support +concurrent access. The file is created if it does not exist. The smtp(8) +daemon does not use this parameter directly, rather the cache is +implemented indirectly in the tlsmgr(8) daemon. This means that +per-smtp-instance master.cf overrides of this parameter are not effective. +Note, that each of the cache databases supported by tlsmgr(8) daemon: +$smtpd_tls_session_cache_database, $smtp_tls_session_cache_database +(and with Postfix 2.3 and later $lmtp_tls_session_cache_database), needs to +be stored separately. It is not at this time possible to store multiple +caches in a single database.

    + +

    Note: dbm databases are not suitable. TLS +session objects are too large.

    + +

    As of version 2.5, Postfix no longer uses root privileges when +opening this file. The file should now be stored under the Postfix-owned +data_directory. As a migration aid, an attempt to open the file +under a non-Postfix directory is redirected to the Postfix-owned +data_directory, and a warning is logged.

    + +

    Example:

    + +
    +smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_session_cache_timeout 3600s + +

    The expiration time of Postfix SMTP client TLS session cache +information. A cache cleanup is performed periodically +every $smtp_tls_session_cache_timeout seconds. As with +$smtp_tls_session_cache_database, this parameter is implemented in the +tlsmgr(8) daemon and therefore per-smtp-instance master.cf overrides +are not possible.

    + +

    As of Postfix 2.11 this setting cannot exceed 100 days. If set +≤ 0, session caching is disabled. If set to a positive value +less than 2 minutes, the minimum value of 2 minutes is used instead.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_use_tls no + +

    Opportunistic mode: use TLS when a remote SMTP server announces +STARTTLS support, otherwise send the mail in the clear. Beware: +some SMTP servers offer STARTTLS even if it is not configured. With +Postfix < 2.3, if the TLS handshake fails, and no other server is +available, delivery is deferred and mail stays in the queue. If this +is a concern for you, use the smtp_tls_per_site feature instead.

    + +

    This feature is available in Postfix 2.2 and later. With +Postfix 2.3 and later use smtp_tls_security_level instead.

    + +%PARAM smtp_enforce_tls no + +

    Enforcement mode: require that remote SMTP servers use TLS +encryption, and never send mail in the clear. This also requires +that the remote SMTP server hostname matches the information in +the remote server certificate, and that the remote SMTP server +certificate was issued by a CA that is trusted by the Postfix SMTP +client. If the certificate doesn't verify or the hostname doesn't +match, delivery is deferred and mail stays in the queue.

    + +

    The server hostname is matched against all names provided as +dNSNames in the SubjectAlternativeName. If no dNSNames are specified, +the CommonName is checked. The behavior may be changed with the +smtp_tls_enforce_peername option.

    + +

    This option is useful only if you are definitely sure that you +will only connect to servers that support RFC 2487 _and_ that +provide valid server certificates. Typical use is for clients that +send all their email to a dedicated mailhub.

    + +

    This feature is available in Postfix 2.2 and later. With +Postfix 2.3 and later use smtp_tls_security_level instead.

    + +%PARAM smtp_tls_enforce_peername yes + +

    With mandatory TLS encryption, require that the remote SMTP +server hostname matches the information in the remote SMTP server +certificate. As of RFC 2487 the requirements for hostname checking +for MTA clients are not specified.

    + +

    This option can be set to "no" to disable strict peer name +checking. This setting has no effect on sessions that are controlled +via the smtp_tls_per_site table.

    + +

    Disabling the hostname verification can make sense in closed +environment where special CAs are created. If not used carefully, +this option opens the danger of a "man-in-the-middle" attack (the +CommonName of this attacker will be logged).

    + +

    This feature is available in Postfix 2.2 and later. With +Postfix 2.3 and later use smtp_tls_security_level instead.

    + +%PARAM smtp_tls_per_site + +

    Optional lookup tables with the Postfix SMTP client TLS usage +policy by next-hop destination and by remote SMTP server hostname. +When both lookups succeed, the more specific per-site policy (NONE, +MUST, etc) overrides the less specific one (MAY), and the more secure +per-site policy (MUST, etc) overrides the less secure one (NONE). +With Postfix 2.3 and later smtp_tls_per_site is strongly discouraged: +use smtp_tls_policy_maps instead.

    + +

    Use of the bare hostname as the per-site table lookup key is +discouraged. Always use the full destination nexthop (enclosed in +[] with a possible ":port" suffix). A recipient domain or MX-enabled +transport next-hop with no port suffix may look like a bare hostname, +but is still a suitable destination.

    + +

    Specify a next-hop destination or server hostname on the left-hand +side; no wildcards are allowed. The next-hop destination is either +the recipient domain, or the destination specified with a transport(5) +table, the relayhost parameter, or the relay_transport parameter. +On the right hand side specify one of the following keywords:

    + +
    + +
    NONE
    Don't use TLS at all. This overrides a less +specific MAY lookup result from the alternate host or next-hop +lookup key, and overrides the global smtp_use_tls, smtp_enforce_tls, +and smtp_tls_enforce_peername settings.
    + +
    MAY
    Try to use TLS if the server announces support, +otherwise use the unencrypted connection. This has less precedence +than a more specific result (including NONE) from the alternate +host or next-hop lookup key, and has less precedence than the more +specific global "smtp_enforce_tls = yes" or "smtp_tls_enforce_peername += yes".
    + +
    MUST_NOPEERMATCH
    Require TLS encryption, but do not +require that the remote SMTP server hostname matches the information +in the remote SMTP server certificate, or that the server certificate +was issued by a trusted CA. This overrides a less secure NONE +or a less specific MAY lookup result from the alternate host +or next-hop lookup key, and overrides the global smtp_use_tls, +smtp_enforce_tls and smtp_tls_enforce_peername settings.
    + +
    MUST
    Require TLS encryption, require that the remote +SMTP server hostname matches the information in the remote SMTP +server certificate, and require that the remote SMTP server certificate +was issued by a trusted CA. This overrides a less secure NONE +and MUST_NOPEERMATCH or a less specific MAY lookup +result from the alternate host or next-hop lookup key, and overrides +the global smtp_use_tls, smtp_enforce_tls and smtp_tls_enforce_peername +settings.
    + +
    + +

    The above keywords correspond to the "none", "may", "encrypt" and +"verify" security levels for the new smtp_tls_security_level parameter +introduced in Postfix 2.3. Starting with Postfix 2.3, and independently +of how the policy is specified, the smtp_tls_mandatory_ciphers and +smtp_tls_mandatory_protocols parameters apply when TLS encryption +is mandatory. Connections for which encryption is optional typically +enable all "export" grade and better ciphers (see smtp_tls_ciphers +and smtp_tls_protocols).

    + +

    As long as no secure DNS lookup mechanism is available, false +hostnames in MX or CNAME responses can change the server hostname +that Postfix uses for TLS policy lookup and server certificate +verification. Even with a perfect match between the server hostname and +the server certificate, there is no guarantee that Postfix is connected +to the right server. See TLS_README (Closing a DNS loophole with obsolete +per-site TLS policies) for a possible work-around.

    + +

    This feature is available in Postfix 2.2 and later. With +Postfix 2.3 and later use smtp_tls_policy_maps instead.

    + +%PARAM smtp_tls_scert_verifydepth 9 + +

    The verification depth for remote SMTP server certificates. A depth +of 1 is sufficient if the issuing CA is listed in a local CA file.

    + +

    The default verification depth is 9 (the OpenSSL default) for +compatibility with earlier Postfix behavior. Prior to Postfix 2.5, +the default value was 5, but the limit was not actually enforced. If +you have set this to a lower non-default value, certificates with longer +trust chains may now fail to verify. Certificate chains with 1 or 2 +CAs are common, deeper chains are more rare and any number between 5 +and 9 should suffice in practice. You can choose a lower number if, +for example, you trust certificates directly signed by an issuing CA +but not any CAs it delegates to.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_note_starttls_offer no + +

    Log the hostname of a remote SMTP server that offers STARTTLS, +when TLS is not already enabled for that server.

    + +

    The logfile record looks like:

    + +
    +postfix/smtp[pid]:  Host offered STARTTLS: [name.of.host]
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_cipherlist + +

    Obsolete Postfix < 2.3 control for the Postfix SMTP client TLS +cipher list. As this feature applies to all TLS security levels, it is easy +to create interoperability problems by choosing a non-default cipher +list. Do not use a non-default TLS cipher list on hosts that deliver email +to the public Internet: you will be unable to send email to servers that +only support the ciphers you exclude. Using a restricted cipher list +may be more appropriate for an internal MTA, where one can exert some +control over the TLS software and settings of the peer servers.

    + +

    Note: do not use "" quotes around the parameter value.

    + +

    This feature is available in Postfix version 2.2. It is not used with +Postfix 2.3 and later; use smtp_tls_mandatory_ciphers instead.

    + +%PARAM smtp_starttls_timeout 300s + +

    Time limit for Postfix SMTP client write and read operations +during TLS startup and shutdown handshake procedures.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_dkey_file $smtp_tls_dcert_file + +

    File with the Postfix SMTP client DSA private key in PEM format. +This file may be combined with the Postfix SMTP client DSA certificate +file specified with $smtp_tls_dcert_file. The DSA algorithm is obsolete +and should not be used.

    + +

    The private key must be accessible without a pass-phrase, i.e. it +must not be encrypted. File permissions should grant read-only +access to the system superuser account ("root"), and no access +to anyone else.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_tls_dcert_file + +

    File with the Postfix SMTP client DSA certificate in PEM format. +This file may also contain the Postfix SMTP client private DSA key. +The DSA algorithm is obsolete and should not be used.

    + +

    See the discussion under smtp_tls_cert_file for more details. +

    + +

    Example:

    + +
    +smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
+
    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM tls_append_default_CA no + +

    Append the system-supplied default Certification Authority +certificates to the ones specified with *_tls_CApath or *_tls_CAfile. +The default is "no"; this prevents Postfix from trusting third-party +certificates and giving them relay permission with +permit_tls_all_clientcerts.

    + +

    This feature is available in Postfix 2.4.15, 2.5.11, 2.6.8, +2.7.2 and later versions. Specify "tls_append_default_CA = yes" for +backwards compatibility, to avoid breaking certificate verification +with sites that don't use permit_tls_all_clientcerts.

    + +%PARAM tls_random_exchange_name see "postconf -d" output + +

    Name of the pseudo random number generator (PRNG) state file +that is maintained by tlsmgr(8). The file is created when it does +not exist, and its length is fixed at 1024 bytes.

    + +

    As of version 2.5, Postfix no longer uses root privileges when +opening this file, and the default file location was changed from +${config_directory}/prng_exch to ${data_directory}/prng_exch. As +a migration aid, an attempt to open the file under a non-Postfix +directory is redirected to the Postfix-owned data_directory, and a +warning is logged.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM tls_random_source see "postconf -d" output + +

    The external entropy source for the in-memory tlsmgr(8) pseudo +random number generator (PRNG) pool. Be sure to specify a non-blocking +source. If this source is not a regular file, the entropy source +type must be prepended: egd:/path/to/egd_socket for a source with +EGD compatible socket interface, or dev:/path/to/device for a +device file.

    + +

    Note: on OpenBSD systems specify /dev/arandom when /dev/urandom +gives timeout errors.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM tls_random_bytes 32 + +

    The number of bytes that tlsmgr(8) reads from $tls_random_source +when (re)seeding the in-memory pseudo random number generator (PRNG) +pool. The default of 32 bytes (256 bits) is good enough for 128bit +symmetric keys. If using EGD or a device file, a maximum of 255 +bytes is read.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM tls_random_reseed_period 3600s + +

    The maximal time between attempts by tlsmgr(8) to re-seed the +in-memory pseudo random number generator (PRNG) pool from external +sources. The actual time between re-seeding attempts is calculated +using the PRNG, and is between 0 and the time specified.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM tls_random_prng_update_period 3600s + +

    The time between attempts by tlsmgr(8) to save the state of +the pseudo random number generator (PRNG) to the file specified +with $tls_random_exchange_name.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM tls_daemon_random_bytes 32 + +

    The number of pseudo-random bytes that an smtp(8) or smtpd(8) +process requests from the tlsmgr(8) server in order to seed its +internal pseudo random number generator (PRNG). The default of 32 +bytes (equivalent to 256 bits) is sufficient to generate a 128bit +(or 168bit) session key.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_sasl_tls_security_options $smtp_sasl_security_options + +

    The SASL authentication security options that the Postfix SMTP +client uses for TLS encrypted SMTP sessions.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtpd_sasl_tls_security_options $smtpd_sasl_security_options + +

    The SASL authentication security options that the Postfix SMTP +server uses for TLS encrypted SMTP sessions.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM smtp_generic_maps + +

    Optional lookup tables that perform address rewriting in the +Postfix SMTP client, typically to transform a locally valid address into +a globally valid address when sending mail across the Internet. +This is needed when the local machine does not have its own Internet +domain name, but uses something like localdomain.local +instead.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    The table format and lookups are documented in generic(5); +examples are shown in the ADDRESS_REWRITING_README and +STANDARD_CONFIGURATION_README documents.

    + +

    This feature is available in Postfix 2.2 and later.

    + +%PARAM message_reject_characters + +

    The set of characters that Postfix will reject in message +content. The usual C-like escape sequences are recognized: \a +\b \f \n \r \t \v \ddd (up to three octal digits) and +\\.

    + +

    Note 1: this feature does not recognize text that requires MIME +decoding. It inspects raw message content, just like header_checks +and body_checks.

    + +

    Note 2: this feature is disabled with "receive_override_options += no_header_body_checks".

    + +

    Example:

    + +
    +message_reject_characters = \0
+
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM message_strip_characters + +

    The set of characters that Postfix will remove from message +content. The usual C-like escape sequences are recognized: \a +\b \f \n \r \t \v \ddd (up to three octal digits) and +\\.

    + +

    Note 1: this feature does not recognize text that requires MIME +decoding. It inspects raw message content, just like header_checks +and body_checks.

    + +

    Note 2: this feature is disabled with "receive_override_options += no_header_body_checks".

    + +

    Example:

    + +
    +message_strip_characters = \0
+
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM frozen_delivered_to yes + +

    Update the local(8) delivery agent's idea of the Delivered-To: +address (see prepend_delivered_header) only once, at the start of +a delivery attempt; do not update the Delivered-To: address while +expanding aliases or .forward files.

    + +

    This feature is available in Postfix 2.3 and later. With older +Postfix releases, the behavior is as if this parameter is set to +"no". The old setting can be expensive with deeply nested aliases +or .forward files. When an alias or .forward file changes the +Delivered-To: address, it ties up one queue file and one cleanup +process instance while mail is being forwarded.

    + +%PARAM smtpd_peername_lookup yes + +

    Attempt to look up the remote SMTP client hostname, and verify that +the name matches the client IP address. A client name is set to +"unknown" when it cannot be looked up or verified, or when name +lookup is disabled. Turning off name lookup reduces delays due to +DNS lookup and increases the maximal inbound delivery rate.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM delay_logging_resolution_limit 2 + +

    The maximal number of digits after the decimal point when logging +sub-second delay values. Specify a number in the range 0..6.

    + +

    Large delay values are rounded off to an integral number seconds; +delay values below the delay_logging_resolution_limit are logged +as "0", and delay values under 100s are logged with at most two-digit +precision.

    + +

    The format of the "delays=a/b/c/d" logging is as follows:

    + +
      + +
    • a = time from message arrival to last active queue entry + +
    • b = time from last active queue entry to connection setup + +
    • c = time in connection setup, including DNS, EHLO and STARTTLS + +
    • d = time in message transmission + +
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM bounce_template_file + +

    Pathname of a configuration file with bounce message templates. +These override the built-in templates of delivery status notification +(DSN) messages for undeliverable mail, for delayed mail, successful +delivery, or delivery verification. The bounce(5) manual page +describes how to edit and test template files.

    + +

    Template message body text may contain $name references to +Postfix configuration parameters. The result of $name expansion can +be previewed with "postconf -b file_name" before the file +is placed into the Postfix configuration directory.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM sender_dependent_relayhost_maps + +

    A sender-dependent override for the global relayhost parameter +setting. The tables are searched by the envelope sender address and +@domain. A lookup result of DUNNO terminates the search without +overriding the global relayhost parameter setting (Postfix 2.6 and +later). This information is overruled with relay_transport, +sender_dependent_default_transport_maps, default_transport and with +the transport(5) table.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    For safety reasons, this feature does not allow $number +substitutions in regular expression maps.

    + +

    +This feature is available in Postfix 2.3 and later. +

    + +%PARAM empty_address_relayhost_maps_lookup_key <> + +

    The sender_dependent_relayhost_maps search string that will be +used instead of the null sender address.

    + +

    This feature is available in Postfix 2.5 and later. With +earlier versions, sender_dependent_relayhost_maps lookups were +skipped for the null sender address.

    + +%PARAM address_verify_sender_dependent_relayhost_maps $sender_dependent_relayhost_maps + +

    +Overrides the sender_dependent_relayhost_maps parameter setting for address +verification probes. +

    + +

    +This feature is available in Postfix 2.3 and later. +

    + +%PARAM smtp_sender_dependent_authentication no + +

    +Enable sender-dependent authentication in the Postfix SMTP client; this is +available only with SASL authentication, and disables SMTP connection +caching to ensure that mail from different senders will use the +appropriate credentials.

    + +

    +This feature is available in Postfix 2.3 and later. +

    + +%PARAM lmtp_lhlo_name $myhostname + +

    +The hostname to send in the LMTP LHLO command. +

    + +

    +The default value is the machine hostname. Specify a hostname or +[ip.add.re.ss]. +

    + +

    +This information can be specified in the main.cf file for all LMTP +clients, or it can be specified in the master.cf file for a specific +client, for example: +

    + +
    +
    +/etc/postfix/master.cf:
+    mylmtp ... lmtp -o lmtp_lhlo_name=foo.bar.com
+
    +
    + +

    +This feature is available in Postfix 2.3 and later. +

    + +%PARAM lmtp_discard_lhlo_keyword_address_maps + +

    Lookup tables, indexed by the remote LMTP server address, with +case insensitive lists of LHLO keywords (pipelining, starttls, +auth, etc.) that the Postfix LMTP client will ignore in the LHLO +response +from a remote LMTP server. See lmtp_discard_lhlo_keywords for +details. The table is not indexed by hostname for consistency with +smtpd_discard_ehlo_keyword_address_maps.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_discard_lhlo_keywords + +

    A case insensitive list of LHLO keywords (pipelining, starttls, +auth, etc.) that the Postfix LMTP client will ignore in the LHLO +response +from a remote LMTP server.

    + +

    This feature is available in Postfix 2.3 and later.

    + +

    Notes:

    + +
      + +

    • Specify the silent-discard pseudo keyword to prevent +this action from being logged.

      + +

    • Use the lmtp_discard_lhlo_keyword_address_maps feature to +discard LHLO keywords selectively.

      + +
    + +%PARAM lmtp_lhlo_timeout 300s + +

    The Postfix LMTP client time limit for sending the LHLO command, +and for receiving the initial remote LMTP server response.

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks). The default time unit is s (seconds).

    + +%PARAM lmtp_sasl_tls_security_options $lmtp_sasl_security_options + +

    The LMTP-specific version of the smtp_sasl_tls_security_options +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_sasl_mechanism_filter + +

    The LMTP-specific version of the smtp_sasl_mechanism_filter +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_bind_address + +

    The LMTP-specific version of the smtp_bind_address configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_bind_address6 + +

    The LMTP-specific version of the smtp_bind_address6 configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_host_lookup dns + +

    The LMTP-specific version of the smtp_host_lookup configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_connection_cache_destinations + +

    The LMTP-specific version of the smtp_connection_cache_destinations +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_per_site + +

    The LMTP-specific version of the smtp_tls_per_site configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_generic_maps + +

    The LMTP-specific version of the smtp_generic_maps configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_pix_workaround_threshold_time 500s + +

    The LMTP-specific version of the smtp_pix_workaround_threshold_time +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_pix_workaround_delay_time 10s + +

    The LMTP-specific version of the smtp_pix_workaround_delay_time +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_connection_reuse_time_limit 300s + +

    The LMTP-specific version of the smtp_connection_reuse_time_limit +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_starttls_timeout 300s + +

    The LMTP-specific version of the smtp_starttls_timeout configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_line_length_limit 990 + +

    The LMTP-specific version of the smtp_line_length_limit +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_mx_address_limit 5 + +

    The LMTP-specific version of the smtp_mx_address_limit configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_mx_session_limit 2 + +

    The LMTP-specific version of the smtp_mx_session_limit configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_scert_verifydepth 9 + +

    The LMTP-specific version of the smtp_tls_scert_verifydepth +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_skip_5xx_greeting yes + +

    The LMTP-specific version of the smtp_skip_5xx_greeting +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_randomize_addresses yes + +

    The LMTP-specific version of the smtp_randomize_addresses +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_quote_rfc821_envelope yes + +

    The LMTP-specific version of the smtp_quote_rfc821_envelope +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_defer_if_no_mx_address_found no + +

    The LMTP-specific version of the smtp_defer_if_no_mx_address_found +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_connection_cache_on_demand yes + +

    The LMTP-specific version of the smtp_connection_cache_on_demand +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_use_tls no + +

    The LMTP-specific version of the smtp_use_tls configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_enforce_tls no + +

    The LMTP-specific version of the smtp_enforce_tls configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_security_level + +

    The LMTP-specific version of the smtp_tls_security_level configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_enforce_peername yes + +

    The LMTP-specific version of the smtp_tls_enforce_peername +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_note_starttls_offer no + +

    The LMTP-specific version of the smtp_tls_note_starttls_offer +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_sender_dependent_authentication no + +

    The LMTP-specific version of the smtp_sender_dependent_authentication +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM connection_cache_protocol_timeout 5s + +

    Time limit for connection cache connect, send or receive +operations. The time limit is enforced in the client.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_sasl_type cyrus + +

    The SASL plug-in type that the Postfix SMTP server should use +for authentication. The available types are listed with the +"postconf -a" command.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_sasl_type cyrus + +

    The SASL plug-in type that the Postfix SMTP client should use +for authentication. The available types are listed with the +"postconf -A" command.

    + +

    This feature is available in Postfix 2.3 and later.

    + + +%PARAM lmtp_sasl_type cyrus + +

    The SASL plug-in type that the Postfix LMTP client should use +for authentication. The available types are listed with the +"postconf -A" command.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_sasl_path smtpd + +

    Implementation-specific information that the Postfix SMTP server +passes through to +the SASL plug-in implementation that is selected with +smtpd_sasl_type. Typically this specifies the name of a +configuration file or rendezvous point.

    + +

    This feature is available in Postfix 2.3 and later. In earlier +releases it was called smtpd_sasl_application_name.

    + +%PARAM smtpd_sasl_service smtp + +

    The service name that is passed to the SASL plug-in that is +selected with smtpd_sasl_type and smtpd_sasl_path. +

    + +

    This feature is available in Postfix 2.11 and later. Prior +versions behave as if "smtp" is specified.

    + +%PARAM smtpd_sasl_response_limit 12288 + +

    The maximum length of a SASL client's response to a server challenge. +When the client's "initial response" is longer than the normal limit for +SMTP commands, the client must omit its initial response, and wait for an +empty server challenge; it can then send what would have been its "initial +response" as a response to the empty server challenge. RFC4954 requires the +server to accept client responses up to at least 12288 octets of +base64-encoded text. The default value is therefore also the minimum value +accepted for this parameter.

    + +

    This feature is available in Postfix 3.4 and later. Prior versions use +"line_length_limit", which may need to be raised to accommodate larger client +responses, as may be needed with GSSAPI authentication of Windows AD users +who are members of many groups.

    + +%PARAM cyrus_sasl_config_path + +

    Search path for Cyrus SASL application configuration files, +currently used only to locate the $smtpd_sasl_path.conf file. +Specify zero or more directories separated by a colon character, +or an empty value to use Cyrus SASL's built-in search path.

    + +

    This feature is available in Postfix 2.5 and later when compiled +with Cyrus SASL 2.1.22 or later.

    + +%PARAM smtp_sasl_path + +

    Implementation-specific information that the Postfix SMTP client +passes through to +the SASL plug-in implementation that is selected with +smtp_sasl_type. Typically this specifies the name of a +configuration file or rendezvous point.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_sasl_path + +

    Implementation-specific information that is passed through to +the SASL plug-in implementation that is selected with +lmtp_sasl_type. Typically this specifies the name of a +configuration file or rendezvous point.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM plaintext_reject_code 450 + +

    +The numerical Postfix SMTP server response code when a request +is rejected by the reject_plaintext_session restriction. +

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM resolve_numeric_domain no + +

    Resolve "user@ipaddress" as "user@[ipaddress]", instead of +rejecting the address as invalid.

    + +

    This feature is available in Postfix 2.3 and later. + +%PARAM mailbox_transport_maps + +

    Optional lookup tables with per-recipient message delivery +transports to use for local(8) mailbox delivery, whether or not the +recipients are found in the UNIX passwd database.

    + +

    The precedence of local(8) delivery features from high to low +is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, +mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, +fallback_transport_maps, fallback_transport and luser_relay.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    For safety reasons, this feature does not allow $number +substitutions in regular expression maps.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM fallback_transport_maps + +

    Optional lookup tables with per-recipient message delivery +transports for recipients that the local(8) delivery agent could +not find in the aliases(5) or UNIX password database.

    + +

    The precedence of local(8) delivery features from high to low +is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, +mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, +fallback_transport_maps, fallback_transport and luser_relay.

    + +

    For safety reasons, this feature does not allow $number +substitutions in regular expression maps.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_cname_overrides_servername version dependent + +

    When the remote SMTP servername is a DNS CNAME, replace the +servername with the result from CNAME expansion for the purpose of +logging, SASL password lookup, TLS +policy decisions, or TLS certificate verification. The value "no" +hardens Postfix smtp_tls_per_site hostname-based policies against +false hostname information in DNS CNAME records, and makes SASL +password file lookups more predictable. This is the default setting +as of Postfix 2.3.

    + +

    When DNS CNAME records are validated with secure DNS lookups +(smtp_dns_support_level = dnssec), they are always allowed to +override the above servername (Postfix 2.11 and later).

    + +

    This feature is available in Postfix 2.2.9 and later.

    + +%PARAM lmtp_cname_overrides_servername yes + +

    The LMTP-specific version of the smtp_cname_overrides_servername +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_sasl_tls_verified_security_options $smtp_sasl_tls_security_options + +

    The SASL authentication security options that the Postfix SMTP +client uses for TLS encrypted SMTP sessions with a verified server +certificate.

    + +

    When mail is sent to the public MX host for the recipient's +domain, server certificates are by default optional, and delivery +proceeds even if certificate verification fails. For delivery via +a submission service that requires SASL authentication, it may be +appropriate to send plaintext passwords only when the connection +to the server is strongly encrypted and the server identity +is verified.

    + +

    The smtp_sasl_tls_verified_security_options parameter makes it +possible to only enable plaintext mechanisms when a secure connection +to the server is available. Submission servers subject to this +policy must either have verifiable certificates or offer suitable +non-plaintext SASL mechanisms.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM lmtp_sasl_tls_verified_security_options $lmtp_sasl_tls_security_options + +

    The LMTP-specific version of the +smtp_sasl_tls_verified_security_options configuration parameter. +See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_connection_cache_time_limit 2s + +

    The LMTP-specific version of the +smtp_connection_cache_time_limit configuration parameter. +See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_delay_open_until_valid_rcpt yes + +

    Postpone the start of an SMTP mail transaction until a valid +RCPT TO command is received. Specify "no" to create a mail transaction +as soon as the Postfix SMTP server receives a valid MAIL FROM +command.

    + +

    With sites that reject lots of mail, the default setting reduces +the use of +disk, CPU and memory resources. The downside is that rejected +recipients are logged with NOQUEUE instead of a mail transaction +ID. This complicates the logfile analysis of multi-recipient mail. +

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_cert_file + +

    The LMTP-specific version of the smtp_tls_cert_file +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_key_file $lmtp_tls_cert_file + +

    The LMTP-specific version of the smtp_tls_key_file +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_dcert_file + +

    The LMTP-specific version of the smtp_tls_dcert_file +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_dkey_file $lmtp_tls_dcert_file + +

    The LMTP-specific version of the smtp_tls_dkey_file +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_CAfile + +

    The LMTP-specific version of the smtp_tls_CAfile +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_CApath + +

    The LMTP-specific version of the smtp_tls_CApath +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_loglevel 0 + +

    The LMTP-specific version of the smtp_tls_loglevel +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_session_cache_database + +

    The LMTP-specific version of the smtp_tls_session_cache_database +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_session_cache_timeout 3600s + +

    The LMTP-specific version of the smtp_tls_session_cache_timeout +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_policy_maps + +

    Optional lookup tables with the Postfix SMTP client TLS security +policy by next-hop destination; when a non-empty value is specified, +this overrides the obsolete smtp_tls_per_site parameter. See +TLS_README for a more detailed discussion of TLS security levels. +

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    The TLS policy table is indexed by the full next-hop destination, +which is either the recipient domain, or the verbatim next-hop +specified in the transport table, $local_transport, $virtual_transport, +$relay_transport or $default_transport. This includes any enclosing +square brackets and any non-default destination server port suffix. The +LMTP socket type prefix (inet: or unix:) is not included in the lookup +key.

    + +

    Only the next-hop domain, or $myhostname with LMTP over UNIX-domain +sockets, is used as the nexthop name for certificate verification. The +port and any enclosing square brackets are used in the table lookup key, +but are not used for server name verification.

    + +

    When the lookup key is a domain name without enclosing square brackets +or any :port suffix (typically the recipient domain), and the full +domain is not found in the table, just as with the transport(5) table, +the parent domain starting with a leading "." is matched recursively. This +allows one to specify a security policy for a recipient domain and all +its sub-domains.

    + +

    The lookup result is a security level, followed by an optional list +of whitespace and/or comma separated name=value attributes that override +related main.cf settings. The TLS security levels in order of increasing +security are:

    + +
    + +
    none
    +
    No TLS. No additional attributes are supported at this level.
    + +
    may
    +
    Opportunistic TLS. Since sending in the clear is acceptable, +demanding stronger than default TLS security merely reduces +interoperability. The optional "ciphers", "exclude", and "protocols" +attributes (available for opportunistic TLS with Postfix ≥ 2.6) +and "connection_reuse" attribute (Postfix ≥ 3.4) override the +"smtp_tls_ciphers", "smtp_tls_exclude_ciphers", "smtp_tls_protocols", +and +"smtp_tls_connection_reuse" configuration parameters. When opportunistic +TLS handshakes fail, Postfix retries the connection with TLS disabled. +This allows mail delivery to sites with non-interoperable TLS +implementations.
    + +
    encrypt
    +
    Mandatory TLS encryption. At this level +and higher, the optional "protocols" attribute overrides the main.cf +smtp_tls_mandatory_protocols parameter, the optional "ciphers" attribute +overrides the main.cf smtp_tls_mandatory_ciphers parameter, the +optional "exclude" attribute (Postfix ≥ 2.6) overrides the main.cf +smtp_tls_mandatory_exclude_ciphers parameter, and the optional +"connection_reuse" attribute (Postfix ≥ 3.4) overrides the +main.cf smtp_tls_connection_reuse parameter. In the policy table, +multiple protocols or excluded ciphers must be separated by colons, +as attribute values may not contain whitespace or commas.
    + +
    dane
    +
    Opportunistic DANE TLS. The TLS policy for the destination is +obtained via TLSA records in DNSSEC. If no TLSA records are found, +the effective security level used is may. If TLSA records are +found, but none are usable, the effective security level is encrypt. When usable +TLSA records are obtained for the remote SMTP server, the +server certificate must match the TLSA records. RFC 7672 (DANE) +TLS authentication and DNSSEC support is available with Postfix +2.11 and later. The optional "connection_reuse" attribute (Postfix +≥ 3.4) overrides the main.cf smtp_tls_connection_reuse parameter. +
    + +
    dane-only
    +
    Mandatory DANE TLS. The TLS policy for the destination is +obtained via TLSA records in DNSSEC. If no TLSA records are found, +or none are usable, no connection is made to the server. When +usable TLSA records are obtained for the remote SMTP server, the +server certificate must match the TLSA records. RFC 7672 (DANE) TLS +authentication and DNSSEC support is available with Postfix 2.11 +and later. The optional "connection_reuse" attribute (Postfix ≥ +3.4) overrides the main.cf smtp_tls_connection_reuse parameter. +
    + +
    fingerprint
    +
    Certificate fingerprint +verification. Available with Postfix 2.5 and later. At this security +level, there are no trusted Certification Authorities. The certificate +trust chain, expiration date, ... are not checked. Instead, +the optional match attribute, or else the main.cf +smtp_tls_fingerprint_cert_match parameter, lists the certificate +fingerprints or the public key fingerprint (Postfix 2.9 and later) +of the valid server certificate. The digest +algorithm used to calculate the fingerprint is selected by the +smtp_tls_fingerprint_digest parameter. Multiple fingerprints can +be combined with a "|" delimiter in a single match attribute, or multiple +match attributes can be employed. The ":" character is not used as a +delimiter as it occurs between each pair of fingerprint (hexadecimal) +digits. The optional "connection_reuse" attribute (Postfix ≥ 3.4) +overrides the main.cf smtp_tls_connection_reuse parameter.
    + +
    verify
    +
    Mandatory TLS verification. At this security +level, DNS MX lookups are trusted to be secure enough, and the name +verified in the server certificate is usually obtained indirectly via +unauthenticated DNS MX lookups. The optional "match" attribute overrides +the main.cf smtp_tls_verify_cert_match parameter. In the policy table, +multiple match patterns and strategies must be separated by colons. +In practice explicit control over matching is more common with the +"secure" policy, described below. The optional "connection_reuse" +attribute (Postfix ≥ 3.4) overrides the main.cf +smtp_tls_connection_reuse parameter.
    + +
    secure
    +
    Secure-channel TLS. At this security level, DNS +MX lookups, though potentially used to determine the candidate next-hop +gateway IP addresses, are not trusted to be secure enough for TLS +peername verification. Instead, the default name verified in the server +certificate is obtained directly from the next-hop, or is explicitly +specified via the optional match attribute which overrides the +main.cf smtp_tls_secure_cert_match parameter. In the policy table, +multiple match patterns and strategies must be separated by colons. +The match attribute is most useful when multiple domains are supported by +common server, the policy entries for additional domains specify matching +rules for the primary domain certificate. While transport table overrides +routing the secondary domains to the primary nexthop also allow secure +verification, they risk delivery to the wrong destination when domains +change hands or are re-assigned to new gateways. With the "match" +attribute approach, routing is not perturbed, and mail is deferred if +verification of a new MX host fails. The optional "connection_reuse" +attribute (Postfix ≥ 3.4) overrides the main.cf +smtp_tls_connection_reuse parameter.
    + +
    + +

    +Example: +

    + +
    +/etc/postfix/main.cf:
+    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+    # Postfix 2.5 and later
+    smtp_tls_fingerprint_digest = md5
+
    + +
    +/etc/postfix/tls_policy:
+    example.edu                 none
+    example.mil                 may
+    example.gov                 encrypt protocols=TLSv1
+    example.com                 verify ciphers=high
+    example.net                 secure
+    .example.net                secure match=.example.net:example.net
+    [mail.example.org]:587      secure match=nexthop
+    # Postfix 2.5 and later
+    [thumb.example.org]          fingerprint
+        match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+        match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+
    + +

    Note: The hostname strategy if listed in a non-default +setting of smtp_tls_secure_cert_match or in the match attribute +in the policy table can render the secure level vulnerable to +DNS forgery. Do not use the hostname strategy for secure-channel +configurations in environments where DNS security is not assured.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_mandatory_protocols !SSLv2, !SSLv3 + +

    List of SSL/TLS protocols that the Postfix SMTP client will use with +mandatory TLS encryption. In main.cf the values are separated by +whitespace, commas or colons. In the policy table "protocols" attribute +(see smtp_tls_policy_maps) the only valid separator is colon. An +empty value means allow all protocols. The valid protocol names, (see +SSL_get_version(3)), are "SSLv2", "SSLv3" and "TLSv1". The +default value is "!SSLv2, !SSLv3" for Postfix releases after the +middle of 2015, "!SSLv2" for older releases.

    + +

    With Postfix ≥ 2.5 the parameter syntax was expanded to support +protocol exclusions. One can explicitly exclude "SSLv2" by setting +"smtp_tls_mandatory_protocols = !SSLv2". To exclude both "SSLv2" and +"SSLv3" set "smtp_tls_mandatory_protocols = !SSLv2, !SSLv3". Listing +the protocols to include, rather than protocols to exclude, is +supported, but not recommended. The exclusion form more closely +matches the underlying OpenSSL interface semantics. +

    + +

    The range of protocols advertised by an SSL/TLS client must be +contiguous. When a protocol version is enabled, disabling any +higher version implicitly disables all versions above that higher version. +Thus, for example (assuming the OpenSSL library supports both SSLv2 +and SSLv3): +

    +
    +
    +smtp_tls_mandatory_protocols = !SSLv2, !TLSv1
+
    +
    +

    also disables any protocols version higher than TLSv1 leaving +only "SSLv3" enabled.

    + +

    Note: As of OpenSSL 1.0.1 two new protocols are defined, "TLSv1.1" +and "TLSv1.2". When Postfix ≤ 2.5 is linked against OpenSSL 1.0.1 +or later, these, or any other new protocol versions, cannot be +disabled except by also disabling "TLSv1" (typically leaving just +"SSLv3"). The latest patch levels of Postfix ≥ 2.6, and all +versions of Postfix ≥ 2.10 can explicitly disable support for +"TLSv1.1" or "TLSv1.2".

    + +

    OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix +≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2) +this can be disabled, if need be, via "!TLSv1.3".

    + +

    At the dane and +dane-only security +levels, when usable TLSA records are obtained for the remote SMTP +server, the Postfix SMTP client is obligated to include the SNI TLS +extension in its SSL client hello message. This may help the remote +SMTP server live up to its promise to provide a certificate that +matches its TLSA records. Since TLS extensions require TLS 1.0 or +later, the Postfix SMTP client must disable "SSLv2" and "SSLv3" when +SNI is required. If you use "dane" or "dane-only" do not disable +TLSv1, except perhaps via the policy table for destinations which +you are sure will support "TLSv1.1" or "TLSv1.2".

    + +

    See the documentation of the smtp_tls_policy_maps parameter and +TLS_README for more information about security levels.

    + +

    Example:

    + +
    +# Preferred syntax with Postfix ≥ 2.5:
+smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
+# Legacy syntax:
+smtp_tls_mandatory_protocols = TLSv1
+
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_verify_cert_match hostname + +

    How the Postfix SMTP client verifies the server certificate +peername for the +"verify" TLS security level. In a "verify" TLS policy table +($smtp_tls_policy_maps) entry the optional "match" attribute +overrides this main.cf setting.

    + +

    This parameter specifies one or more patterns or strategies separated +by commas, whitespace or colons. In the policy table the only valid +separator is the colon character.

    + +

    Patterns specify domain names, or domain name suffixes:

    + +
    + +
    example.com
    Match the example.com domain, +i.e. one of the names the server certificate must be example.com, +upper and lower case distinctions are ignored.
    + +
    .example.com
    +
    Match subdomains of the example.com domain, i.e. match +a name in the server certificate that consists of a non-zero number of +labels followed by a .example.com suffix. Case distinctions are +ignored.
    + +
    + +

    Strategies specify a transformation from the next-hop domain +to the expected name in the server certificate:

    + +
    + +
    nexthop
    +
    Match against the next-hop domain, which is either the recipient +domain, or the transport next-hop configured for the domain stripped of +any optional socket type prefix, enclosing square brackets and trailing +port. When MX lookups are not suppressed, this is the original nexthop +domain prior to the MX lookup, not the result of the MX lookup. For +LMTP delivery via UNIX-domain sockets, the verified next-hop name is +$myhostname. This strategy is suitable for use with the "secure" +policy. Case is ignored.
    + +
    dot-nexthop
    +
    As above, but match server certificate names that are subdomains +of the next-hop domain. Case is ignored.
    + +
    hostname
    Match against the hostname of the server, often +obtained via an unauthenticated DNS MX lookup. For LMTP delivery via +UNIX-domain sockets, the verified name is $myhostname. This matches +the verification strategy of the "MUST" keyword in the obsolete +smtp_tls_per_site table, and is suitable for use with the "verify" +security level. When the next-hop name is enclosed in square brackets +to suppress MX lookups, the "hostname" strategy is the same as the +"nexthop" strategy. Case is ignored.
    + +
    + +

    +Sample main.cf setting: +

    + +
    +smtp_tls_verify_cert_match = hostname, nexthop, dot-nexthop
+
    + +

    +Sample policy table override: +

    + +
    +example.com     verify  match=hostname:nexthop
+.example.com    verify  match=example.com:.example.com:hostname
+
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_secure_cert_match nexthop, dot-nexthop + +

    How the Postfix SMTP client verifies the server certificate +peername for the "secure" TLS security level. In a "secure" TLS policy table +($smtp_tls_policy_maps) entry the optional "match" attribute +overrides this main.cf setting.

    + +

    This parameter specifies one or more patterns or strategies separated +by commas, whitespace or colons. In the policy table the only valid +separator is the colon character.

    + +

    For a description of the pattern and strategy syntax see the +smtp_tls_verify_cert_match parameter. The "hostname" strategy should +be avoided in this context, as in the absence of a secure global DNS, using +the results of MX lookups in certificate verification is not immune to active +(man-in-the-middle) attacks on DNS.

    + +

    +Sample main.cf setting: +

    + +
    +
    +smtp_tls_secure_cert_match = nexthop
+
    +
    + +

    +Sample policy table override: +

    + +
    +
    +example.net     secure match=example.com:.example.com
+.example.net    secure match=example.com:.example.com
+
    +
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_policy_maps + +

    The LMTP-specific version of the smtp_tls_policy_maps +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_mandatory_protocols !SSLv2, !SSLv3 + +

    The LMTP-specific version of the smtp_tls_mandatory_protocols +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_verify_cert_match hostname + +

    The LMTP-specific version of the smtp_tls_verify_cert_match +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_secure_cert_match nexthop + +

    The LMTP-specific version of the smtp_tls_secure_cert_match +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_tls_mandatory_protocols !SSLv2, !SSLv3 + +

    The SSL/TLS protocols accepted by the Postfix SMTP server with +mandatory TLS encryption. If the list is empty, the server supports +all available SSL/TLS protocol versions. A non-empty value is a +list of protocol names separated by whitespace, commas or colons. +The supported protocol names are "SSLv2", "SSLv3" and "TLSv1", and +are not case sensitive. The default value is "!SSLv2, !SSLv3" for +Postfix releases after the middle of 2015, "!SSLv2" for older +releases.

    + +

    With Postfix ≥ 2.5 the parameter syntax was expanded to support +protocol exclusions. One can explicitly exclude "SSLv2" by setting +"smtpd_tls_mandatory_protocols = !SSLv2". To exclude both "SSLv2" and +"SSLv3" set "smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3". Listing +the protocols to include, rather than protocols to exclude, is +supported, but not recommended. The exclusion form more closely +matches the underlying OpenSSL interface semantics.

    + +

    Note: As of OpenSSL 1.0.1 two new protocols are defined, "TLSv1.1" +and "TLSv1.2". When Postfix ≤ 2.5 is linked against OpenSSL 1.0.1 +or later, these, or any other new protocol versions, cannot be +disabled. The latest patch levels of Postfix ≥ 2.6, and all +versions of Postfix ≥ 2.10 can disable support for "TLSv1.1" or +"TLSv1.2".

    + +

    OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix +≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2) +this can be disabled, if need be, via "!TLSv1.3".

    + +

    Example:

    + +
    +# Preferred syntax with Postfix ≥ 2.5:
+smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
+# Legacy syntax:
+smtpd_tls_mandatory_protocols = TLSv1
+
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_security_level + +

    The default SMTP TLS security level for the Postfix SMTP client; +when a non-empty value is specified, this overrides the obsolete +parameters smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername. +

    + +

    Specify one of the following security levels:

    + +
    + +
    none
    +
    No TLS. TLS will not be used unless enabled for specific +destinations via smtp_tls_policy_maps.
    + +
    may
    +
    Opportunistic TLS. Use TLS if this is supported by the remote +SMTP server, otherwise use plaintext. Since +sending in the clear is acceptable, demanding stronger than default TLS +security merely reduces interoperability. +The "smtp_tls_ciphers" and "smtp_tls_protocols" (Postfix ≥ 2.6) +configuration parameters provide control over the protocols and +cipher grade used with opportunistic TLS. With earlier releases the +opportunistic TLS cipher grade is always "export" and no protocols +are disabled. +When TLS handshakes fail, the connection is retried with TLS disabled. +This allows mail delivery to sites with non-interoperable TLS +implementations.
    + +
    encrypt
    +
    Mandatory TLS encryption. Since a minimum +level of security is intended, it is reasonable to be specific about +sufficiently secure protocol versions and ciphers. At this security level +and higher, the main.cf parameters smtp_tls_mandatory_protocols and +smtp_tls_mandatory_ciphers specify the TLS protocols and minimum +cipher grade which the administrator considers secure enough for +mandatory encrypted sessions. This security level is not an appropriate +default for systems delivering mail to the Internet.
    + +
    dane
    +
    Opportunistic DANE TLS. At this security level, the TLS policy +for the destination is obtained via DNSSEC. For TLSA policy to be +in effect, the destination domain's containing DNS zone must be +signed and the Postfix SMTP client's operating system must be +configured to send its DNS queries to a recursive DNS nameserver +that is able to validate the signed records. Each MX host's DNS +zone should also be signed, and should publish DANE TLSA (RFC 7672) +records that specify how that MX host's TLS certificate is to be +verified. TLSA records do not preempt the normal SMTP MX host +selection algorithm, if some MX hosts support TLSA and others do +not, TLS security will vary from delivery to delivery. It is up +to the domain owner to configure their MX hosts and their DNS +sensibly. To configure the Postfix SMTP client for DNSSEC lookups +see the documentation for the smtp_dns_support_level main.cf +parameter. When DNSSEC-validated TLSA records are not found the +effective tls security level is "may". When TLSA records are found, +but are all unusable the effective security level is "encrypt". For +purposes of protocol and cipher selection, the "dane" security level +is treated like a "mandatory" TLS security level, and weak ciphers +and protocols are disabled. Since DANE authenticates server +certificates the "aNULL" cipher-suites are transparently excluded +at this level, no need to configure this manually. RFC 7672 (DANE) +TLS authentication is available with Postfix 2.11 and later.
    + +
    dane-only
    +
    Mandatory DANE TLS. This is just like "dane" above, but DANE +TLSA authentication is required. There is no fallback to "may" or +"encrypt" when TLSA records are missing or unusable. RFC 7672 +(DANE) TLS authentication is available with Postfix 2.11 and later. +
    + +
    fingerprint
    +
    Certificate fingerprint verification. +At this security level, there are no trusted Certification Authorities. +The certificate trust chain, expiration date, etc., are +not checked. Instead, the smtp_tls_fingerprint_cert_match +parameter lists the certificate fingerprint or public key fingerprint +(Postfix 2.9 and later) of the valid server certificate. The digest +algorithm used to calculate the fingerprint is selected by the +smtp_tls_fingerprint_digest parameter. Available with Postfix +2.5 and later.
    + +
    verify
    +
    Mandatory TLS verification. At this security +level, DNS MX lookups are trusted to be secure enough, and the name +verified in the server certificate is usually obtained indirectly +via unauthenticated DNS MX lookups. The smtp_tls_verify_cert_match +parameter controls how the server name is verified. In practice explicit +control over matching is more common at the "secure" level, described +below. This security level is not an appropriate default for systems +delivering mail to the Internet.
    + +
    secure
    +
    Secure-channel TLS. At this security level, +DNS MX lookups, though potentially used to determine the candidate +next-hop gateway IP addresses, are not trusted to be secure enough +for TLS peername verification. Instead, the default name verified in +the server certificate is obtained from the next-hop domain as specified +in the smtp_tls_secure_cert_match configuration parameter. The default +matching rule is that a server certificate matches when its name is equal +to or is a sub-domain of the nexthop domain. This security level is not +an appropriate default for systems delivering mail to the Internet.
    + +
    + +

    +Examples: +

    + +
    +# No TLS. Formerly: smtp_use_tls=no and smtp_enforce_tls=no.
+smtp_tls_security_level = none
+
    + +
    +# Opportunistic TLS.
+smtp_tls_security_level = may
+# Postfix ≥ 2.6:
+# Do not tweak opportunistic ciphers or protocol unless it is essential
+# to do so (if a security vulnerability is found in the SSL library that
+# can be mitigated by disabling a particular protocol or raising the
+# cipher grade from "export" to "low" or "medium").
+smtp_tls_ciphers = export
+smtp_tls_protocols = !SSLv2, !SSLv3
+
    + +
    +# Mandatory (high-grade) TLS encryption.
+smtp_tls_security_level = encrypt
+smtp_tls_mandatory_ciphers = high
+
    + +
    +# Mandatory TLS verification of hostname or nexthop domain.
+smtp_tls_security_level = verify
+smtp_tls_mandatory_ciphers = high
+smtp_tls_verify_cert_match = hostname, nexthop, dot-nexthop
+
    + +
    +# Secure channel TLS with exact nexthop name match.
+smtp_tls_security_level = secure
+smtp_tls_mandatory_protocols = TLSv1
+smtp_tls_mandatory_ciphers = high
+smtp_tls_secure_cert_match = nexthop
+
    + +
    +# Certificate fingerprint verification (Postfix ≥ 2.5).
+# The CA-less "fingerprint" security level only scales to a limited
+# number of destinations. As a global default rather than a per-site
+# setting, this is practical when mail for all recipients is sent
+# to a central mail hub.
+relayhost = [mailhub.example.com]
+smtp_tls_security_level = fingerprint
+smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
+smtp_tls_mandatory_ciphers = high
+smtp_tls_fingerprint_cert_match = 
+    3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+    EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_milters + +

    A list of Milter (mail filter) applications for new mail that +arrives via the Postfix smtpd(8) server. Specify space or comma as +separator. See the MILTER_README document for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM non_smtpd_milters + +

    A list of Milter (mail filter) applications for new mail that +does not arrive via the Postfix smtpd(8) server. This includes local +submission via the sendmail(1) command line, new mail that arrives +via the Postfix qmqpd(8) server, and old mail that is re-injected +into the queue with "postsuper -r". Specify space or comma as +separator. See the MILTER_README document for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_protocol 6 + +

    The mail filter protocol version and optional protocol extensions +for communication with a Milter application; prior to Postfix 2.6 +the default protocol is 2. Postfix +sends this version number during the initial protocol handshake. +It should match the version number that is expected by the mail +filter application (or by its Milter library).

    + +

    Protocol versions:

    + +
    + +
    2
    Use Sendmail 8 mail filter protocol version 2 (default +with Sendmail version 8.11 .. 8.13 and Postfix version 2.3 .. +2.5).
    + +
    3
    Use Sendmail 8 mail filter protocol version 3.
    + +
    4
    Use Sendmail 8 mail filter protocol version 4.
    + +
    6
    Use Sendmail 8 mail filter protocol version 6 (default +with Sendmail version 8.14 and Postfix version 2.6).
    + +
    + +

    Protocol extensions:

    + +
    + +
    no_header_reply
    Specify this when the Milter application +will not reply for each individual message header.
    + +
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_default_action tempfail + +

    The default action when a Milter (mail filter) application is +unavailable or mis-configured. Specify one of the following:

    + +
    + +
    accept
    Proceed as if the mail filter was not present. +
    + +
    reject
    Reject all further commands in this session +with a permanent status code.
    + +
    tempfail
    Reject all further commands in this session +with a temporary status code.
    + +
    quarantine
    Like "accept", but freeze the message in +the "hold" queue. Available with Postfix 2.6 and later.
    + +
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_connect_timeout 30s + +

    The time limit for connecting to a Milter (mail filter) +application, and for negotiating protocol options.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit).

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks). The default time unit is s (seconds).

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_command_timeout 30s + +

    The time limit for sending an SMTP command to a Milter (mail +filter) application, and for receiving the response.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit).

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks). The default time unit is s (seconds).

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_content_timeout 300s + +

    The time limit for sending message content to a Milter (mail +filter) application, and for receiving the response.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit).

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks). The default time unit is s (seconds).

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_connect_macros see "postconf -d" output + +

    The macros that are sent to Milter (mail filter) applications +after completion of an SMTP connection. See MILTER_README +for a list of available macro names and their meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_helo_macros see "postconf -d" output + +

    The macros that are sent to Milter (mail filter) applications +after the SMTP HELO or EHLO command. See +MILTER_README for a list of available macro names and their meanings. +

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_mail_macros see "postconf -d" output + +

    The macros that are sent to Milter (mail filter) applications +after the SMTP MAIL FROM command. See MILTER_README +for a list of available macro names and their meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_rcpt_macros see "postconf -d" output + +

    The macros that are sent to Milter (mail filter) applications +after the SMTP RCPT TO command. See MILTER_README +for a list of available macro names and their meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_data_macros see "postconf -d" output + +

    The macros that are sent to version 4 or higher Milter (mail +filter) applications after the SMTP DATA command. See MILTER_README +for a list of available macro names and their meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_end_of_header_macros see "postconf -d" output + +

    The macros that are sent to Milter (mail filter) applications +after the end of the message header. See MILTER_README for a list +of available macro names and their meanings.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM milter_end_of_data_macros see "postconf -d" output + +

    The macros that are sent to Milter (mail filter) applications +after the message end-of-data. See MILTER_README for a list of +available macro names and their meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_unknown_command_macros see "postconf -d" output + +

    The macros that are sent to version 3 or higher Milter (mail +filter) applications after an unknown SMTP command. See MILTER_README +for a list of available macro names and their meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_macro_daemon_name $myhostname + +

    The {daemon_name} macro value for Milter (mail filter) applications. +See MILTER_README for a list of available macro names and their +meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM milter_macro_defaults + +

    Optional list of name=value pairs that specify default +values for arbitrary macros that Postfix may send to Milter +applications. These defaults are used when there is no corresponding +information from the message delivery context.

    + +

    Specify name=value or {name}=value pairs separated +by comma or whitespace. Enclose a pair in "{}" when a value contains +comma or whitespace (this form ignores whitespace after the enclosing +"{", around the "=", and before the enclosing "}").

    + +

    This feature is available in Postfix 3.1 and later.

    + +%PARAM milter_macro_v $mail_name $mail_version + +

    The {v} macro value for Milter (mail filter) applications. +See MILTER_README for a list of available macro names and their +meanings.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_tls_mandatory_ciphers medium + +

    The minimum TLS cipher grade that the Postfix SMTP server will +use with mandatory TLS encryption. The default grade ("medium") is +sufficiently strong that any benefit from globally restricting TLS +sessions to a more stringent grade is likely negligible, especially +given the fact that many implementations still do not offer any stronger +("high" grade) ciphers, while those that do, will always use "high" +grade ciphers. So insisting on "high" grade ciphers is generally +counter-productive. Allowing "export" or "low" ciphers is typically +not a good idea, as systems limited to just these are limited to +obsolete browsers. No known SMTP clients fail to support at least +one "medium" or "high" grade cipher.

    + +

    The following cipher grades are supported:

    + +
    +
    export
    +
    Enable "EXPORT" grade or stronger OpenSSL ciphers. The +underlying cipherlist is specified via the tls_export_cipherlist +configuration parameter, which you are strongly encouraged to not +change. This choice is insecure and SHOULD NOT be used.
    + +
    low
    +
    Enable "LOW" grade or stronger OpenSSL ciphers. The underlying +cipherlist is specified via the tls_low_cipherlist configuration +parameter, which you are strongly encouraged to not change. This +choice is insecure and SHOULD NOT be used.
    + +
    medium
    +
    Enable "MEDIUM" grade or stronger OpenSSL ciphers. These use 128-bit +or longer symmetric bulk-encryption keys. This is the default minimum +strength for mandatory TLS encryption. The underlying cipherlist is +specified via the tls_medium_cipherlist configuration parameter, which +you are strongly encouraged to not change.
    + +
    high
    +
    Enable only "HIGH" grade OpenSSL ciphers. The +underlying cipherlist is specified via the tls_high_cipherlist +configuration parameter, which you are strongly encouraged to +not change.
    + +
    null
    +
    Enable only the "NULL" OpenSSL ciphers, these provide authentication +without encryption. This setting is only appropriate in the rare +case that all clients are prepared to use NULL ciphers (not normally +enabled in TLS clients). The underlying cipherlist is specified via the +tls_null_cipherlist configuration parameter, which you are strongly +encouraged to not change.
    + +
    + +

    Cipher types listed in +smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are +excluded from the base definition of the selected cipher grade. See +smtpd_tls_ciphers for cipher controls that apply to opportunistic +TLS.

    + +

    The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +server is configured to ask for remote SMTP client certificates. You are very +unlikely to need to take any steps to exclude anonymous ciphers, they +are excluded automatically as required. If you must exclude anonymous +ciphers even when Postfix does not need or use peer certificates, set +"smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only +when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = aNULL".

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_tls_exclude_ciphers + +

    List of ciphers or cipher types to exclude from the SMTP server +cipher list at all TLS security levels. Excluding valid ciphers +can create interoperability problems. DO NOT exclude ciphers unless it +is essential to do so. This is not an OpenSSL cipherlist; it is a simple +list separated by whitespace and/or commas. The elements are a single +cipher, or one or more "+" separated cipher properties, in which case +only ciphers matching all the properties are excluded.

    + +

    Examples (some of these will cause problems):

    + +
    +
    +smtpd_tls_exclude_ciphers = aNULL
+smtpd_tls_exclude_ciphers = MD5, DES
+smtpd_tls_exclude_ciphers = DES+MD5
+smtpd_tls_exclude_ciphers = AES256-SHA, DES-CBC3-MD5
+smtpd_tls_exclude_ciphers = kEDH+aRSA
+
    +
    + +

    The first setting disables anonymous ciphers. The next setting +disables ciphers that use the MD5 digest algorithm or the (single) DES +encryption algorithm. The next setting disables ciphers that use MD5 and +DES together. The next setting disables the two ciphers "AES256-SHA" +and "DES-CBC3-MD5". The last setting disables ciphers that use "EDH" +key exchange with RSA authentication.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_tls_mandatory_exclude_ciphers + +

    Additional list of ciphers or cipher types to exclude from the +Postfix SMTP server cipher list at mandatory TLS security levels. +This list +works in addition to the exclusions listed with smtpd_tls_exclude_ciphers +(see there for syntax details).

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_mandatory_ciphers medium + +

    The minimum TLS cipher grade that the Postfix SMTP client will +use with +mandatory TLS encryption. The default value "medium" is suitable +for most destinations with which you may want to enforce TLS, and +is beyond the reach of today's cryptanalytic methods. See +smtp_tls_policy_maps for information on how to configure ciphers +on a per-destination basis.

    + +

    The following cipher grades are supported:

    + +
    +
    export
    +
    Enable "EXPORT" grade or better OpenSSL ciphers. The underlying +cipherlist is specified via the tls_export_cipherlist configuration +parameter, which you are strongly encouraged to not change. This +choice is insecure and SHOULD NOT be used.
    + +
    low
    +
    Enable "LOW" grade or better OpenSSL ciphers. The underlying +cipherlist is specified via the tls_low_cipherlist configuration +parameter, which you are strongly encouraged to not change. This +choice is insecure and SHOULD NOT be used.
    + +
    medium
    +
    Enable "MEDIUM" grade or better OpenSSL ciphers. +The underlying cipherlist is specified via the tls_medium_cipherlist +configuration parameter, which you are strongly encouraged to not change. +
    + +
    high
    +
    Enable only "HIGH" grade OpenSSL ciphers. This setting may +be appropriate when all mandatory TLS destinations (e.g. when all +mail is routed to a suitably capable relayhost) support at least one +"HIGH" grade cipher. The underlying cipherlist is specified via the +tls_high_cipherlist configuration parameter, which you are strongly +encouraged to not change.
    + +
    null
    +
    Enable only the "NULL" OpenSSL ciphers, these provide authentication +without encryption. This setting is only appropriate in the rare case +that all servers are prepared to use NULL ciphers (not normally enabled +in TLS servers). A plausible use-case is an LMTP server listening on a +UNIX-domain socket that is configured to support "NULL" ciphers. The +underlying cipherlist is specified via the tls_null_cipherlist +configuration parameter, which you are strongly encouraged to not +change.
    + +
    + +

    The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +Postfix SMTP client is configured to verify server certificates. +You are very unlikely to need to take any steps to exclude anonymous +ciphers, they are excluded automatically as necessary. If you must +exclude anonymous ciphers at the "may" or "encrypt" security levels, +when the Postfix SMTP client does not need or use peer certificates, set +"smtp_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only when +TLS is enforced, set "smtp_tls_mandatory_exclude_ciphers = aNULL".

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_exclude_ciphers + +

    List of ciphers or cipher types to exclude from the Postfix +SMTP client cipher +list at all TLS security levels. This is not an OpenSSL cipherlist, it is +a simple list separated by whitespace and/or commas. The elements are a +single cipher, or one or more "+" separated cipher properties, in which +case only ciphers matching all the properties are excluded.

    + +

    Examples (some of these will cause problems):

    + +
    +
    +smtp_tls_exclude_ciphers = aNULL
+smtp_tls_exclude_ciphers = MD5, DES
+smtp_tls_exclude_ciphers = DES+MD5
+smtp_tls_exclude_ciphers = AES256-SHA, DES-CBC3-MD5
+smtp_tls_exclude_ciphers = kEDH+aRSA
+
    +
    + +

    The first setting, disables anonymous ciphers. The next setting +disables ciphers that use the MD5 digest algorithm or the (single) DES +encryption algorithm. The next setting disables ciphers that use MD5 and +DES together. The next setting disables the two ciphers "AES256-SHA" +and "DES-CBC3-MD5". The last setting disables ciphers that use "EDH" +key exchange with RSA authentication.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_tls_mandatory_exclude_ciphers + +

    Additional list of ciphers or cipher types to exclude from the +Postfix SMTP client cipher list at mandatory TLS security levels. This list +works in addition to the exclusions listed with smtp_tls_exclude_ciphers +(see there for syntax details).

    + +

    Starting with Postfix 2.6, the mandatory cipher exclusions can be +specified on a per-destination basis via the TLS policy "exclude" +attribute. See smtp_tls_policy_maps for notes and examples.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM tls_high_cipherlist see "postconf -d" output + +

    The OpenSSL cipherlist for "high" grade ciphers. This defines +the meaning of the "high" setting in smtpd_tls_ciphers, +smtpd_tls_mandatory_ciphers, smtp_tls_ciphers, smtp_tls_mandatory_ciphers, +lmtp_tls_ciphers, and lmtp_tls_mandatory_ciphers. You are strongly +encouraged to not change this setting.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM tls_medium_cipherlist see "postconf -d" output + +

    The OpenSSL cipherlist for "medium" or higher grade ciphers. This +defines the meaning of the "medium" setting in smtpd_tls_ciphers, +smtpd_tls_mandatory_ciphers, smtp_tls_ciphers, smtp_tls_mandatory_ciphers, +lmtp_tls_ciphers, and lmtp_tls_mandatory_ciphers. This is the +default cipherlist for mandatory TLS encryption in the TLS client +(with anonymous ciphers disabled when verifying server certificates). +This is the default cipherlist for opportunistic TLS with Postfix +releases after the middle of 2015. You are strongly encouraged to +not change this setting.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM tls_low_cipherlist see "postconf -d" output + +

    The OpenSSL cipherlist for "low" or higher grade ciphers. This defines +the meaning of the "low" setting in smtpd_tls_ciphers, +smtpd_tls_mandatory_ciphers, smtp_tls_ciphers, smtp_tls_mandatory_ciphers, +lmtp_tls_ciphers, and lmtp_tls_mandatory_ciphers. You are strongly +encouraged to not change this setting.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM tls_export_cipherlist see "postconf -d" output + +

    The OpenSSL cipherlist for "export" or higher grade ciphers. This +defines the meaning of the "export" setting in smtpd_tls_ciphers, +smtpd_tls_mandatory_ciphers, smtp_tls_ciphers, smtp_tls_mandatory_ciphers, +lmtp_tls_ciphers, and lmtp_tls_mandatory_ciphers. With Postfix +releases before the middle of 2015 this is the default cipherlist +for the opportunistic ("may") TLS client security level and also +the default cipherlist for the SMTP server. You are strongly +encouraged to not change this setting.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM tls_null_cipherlist eNULL:!aNULL + +

    The OpenSSL cipherlist for "NULL" grade ciphers that provide +authentication without encryption. This defines the meaning of the "null" +setting in smtpd_mandatory_tls_ciphers, smtp_tls_mandatory_ciphers and +lmtp_tls_mandatory_ciphers. You are strongly encouraged to not +change this setting.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_mandatory_ciphers medium + +

    The LMTP-specific version of the smtp_tls_mandatory_ciphers +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_exclude_ciphers + +

    The LMTP-specific version of the smtp_tls_exclude_ciphers +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM lmtp_tls_mandatory_exclude_ciphers + +

    The LMTP-specific version of the smtp_tls_mandatory_exclude_ciphers +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_tls_security_level + +

    The SMTP TLS security level for the Postfix SMTP server; when +a non-empty value is specified, this overrides the obsolete parameters +smtpd_use_tls and smtpd_enforce_tls. This parameter is ignored with +"smtpd_tls_wrappermode = yes".

    + +

    Specify one of the following security levels:

    + +
    + +
    none
    TLS will not be used.
    + +
    may
    Opportunistic TLS: announce STARTTLS support +to remote SMTP clients, but do not require that clients use TLS encryption. +
    + +
    encrypt
    Mandatory TLS encryption: announce +STARTTLS support to remote SMTP clients, and require that clients use TLS +encryption. According to RFC 2487 this MUST NOT be applied in case +of a publicly-referenced SMTP server. Instead, this option should +be used only on dedicated servers.
    + +
    + +

    Note 1: the "fingerprint", "verify" and "secure" levels are not +supported here. +The Postfix SMTP server logs a warning and uses "encrypt" instead. +To verify remote SMTP client certificates, see TLS_README for a discussion +of the smtpd_tls_ask_ccert, smtpd_tls_req_ccert, and permit_tls_clientcerts +features.

    + +

    Note 2: The parameter setting "smtpd_tls_security_level = +encrypt" implies "smtpd_tls_auth_only = yes".

    + +

    Note 3: when invoked via "sendmail -bs", Postfix will never +offer STARTTLS due to insufficient privileges to access the server +private key. This is intended behavior.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM internal_mail_filter_classes + +

    What categories of Postfix-generated mail are subject to +before-queue content inspection by non_smtpd_milters, header_checks +and body_checks. Specify zero or more of the following, separated +by whitespace or comma.

    + +
    + +
    bounce
    Inspect the content of delivery +status notifications.
    + +
    notify
    Inspect the content of postmaster +notifications by the smtp(8) and smtpd(8) processes.
    + +
    + +

    NOTE: It's generally not safe to enable content inspection of +Postfix-generated email messages. The user is warned.

    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtpd_tls_always_issue_session_ids yes + +

    Force the Postfix SMTP server to issue a TLS session id, even +when TLS session caching is turned off (smtpd_tls_session_cache_database +is empty). This behavior is compatible with Postfix < 2.3.

    + +

    With Postfix 2.3 and later the Postfix SMTP server can disable +session id generation when TLS session caching is turned off. This +keeps remote SMTP clients from caching sessions that almost certainly cannot +be re-used.

    + +

    By default, the Postfix SMTP server always generates TLS session +ids. This works around a known defect in mail client applications +such as MS Outlook, and may also prevent interoperability issues +with other MTAs.

    + +

    Example:

    + +
    +smtpd_tls_always_issue_session_ids = no
+
    + +

    This feature is available in Postfix 2.3 and later.

    + +%PARAM smtp_pix_workarounds disable_esmtp, delay_dotcrlf + +

    A list that specifies zero or more workarounds for CISCO PIX +firewall bugs. These workarounds are implemented by the Postfix +SMTP client. Workaround names are separated by comma or space, and +are case insensitive. This parameter setting can be overruled with +per-destination smtp_pix_workaround_maps settings.

    + +
    + +
    delay_dotcrlf
    Insert a delay before sending +".<CR><LF>" after the end of the message content. The +delay is subject to the smtp_pix_workaround_delay_time and +smtp_pix_workaround_threshold_time parameter settings.
    + +
    disable_esmtp
    Disable all extended SMTP commands: +send HELO instead of EHLO.
    + +
    + +

    This feature is available in Postfix 2.4 and later. The default +settings are backwards compatible with earlier Postfix versions. +

    + +%PARAM smtp_pix_workaround_maps + +

    Lookup tables, indexed by the remote SMTP server address, with +per-destination workarounds for CISCO PIX firewall bugs. The table +is not indexed by hostname for consistency with +smtp_discard_ehlo_keyword_address_maps.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    This feature is available in Postfix 2.4 and later.

    + +%PARAM lmtp_pix_workarounds + +

    The LMTP-specific version of the smtp_pix_workaround +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.4 and later.

    + +%PARAM smtp_tls_fingerprint_digest md5 + +

    The message digest algorithm used to construct remote SMTP server +certificate fingerprints. At the "fingerprint" TLS security level +(smtp_tls_security_level = fingerprint), the server certificate is +verified by directly matching its certificate fingerprint or its public +key fingerprint (Postfix 2.9 and later). The fingerprint is the +message digest of the server certificate (or its public key) +using the selected +algorithm. With a digest algorithm resistant to "second pre-image" +attacks, it is not feasible to create a new public key and a matching +certificate (or public/private key-pair) that has the same fingerprint.

    + +

    The default algorithm is md5; this is consistent with +the backwards compatible setting of the digest used to verify client +certificates in the SMTP server.

    + +

    The best practice algorithm is now sha1. Recent advances in hash +function cryptanalysis have led to md5 being deprecated in favor of sha1. +However, as long as there are no known "second pre-image" attacks +against md5, its use in this context can still be considered safe. +

    + +

    While additional digest algorithms are often available with OpenSSL's +libcrypto, only those used by libssl in SSL cipher suites are available to +Postfix. For now this means just md5 or sha1.

    + +

    To find the fingerprint of a specific certificate file, with a +specific digest algorithm, run: +

    + +
    +
    +$ openssl x509 -noout -fingerprint -digest -in certfile.pem
+
    +
    + +

    The text to the right of "=" sign is the desired fingerprint. +For example:

    + +
    +
    +$ openssl x509 -noout -fingerprint -sha1 -in cert.pem
+SHA1 Fingerprint=D4:6A:AB:19:24:79:F8:32:BB:A6:CB:66:82:C0:8E:9B:EE:29:A8:1A
+
    +
    + +

    To extract the public key fingerprint from an X.509 certificate, +you need to extract the public key from the certificate and compute +the appropriate digest of its DER (ASN.1) encoding. With OpenSSL +the "-pubkey" option of the "x509" command extracts the public +key always in "PEM" format. We pipe the result to another OpenSSL +command that converts the key to DER and then to the "dgst" command +to compute the fingerprint.

    + +

    The actual command to transform the key to DER format depends +on the version of OpenSSL used. With OpenSSL 1.0.0 and later, the +"pkey" command supports all key types. With OpenSSL 0.9.8 and +earlier, the key type is always RSA (nobody uses DSA, and EC +keys are not fully supported by 0.9.8), so the "rsa" command is +used.

    +
    +
    +# OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl pkey -pubin -outform DER |
+    openssl dgst -sha1 -c
+(stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
+
    +
    + +
    +
    +# OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl rsa -pubin -outform DER |
+    openssl dgst -md5 -c
+(stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
+
    +
    + +

    The Postfix SMTP server and client log the peer (leaf) certificate +fingerprint and public key fingerprint when the TLS loglevel is 2 or +higher.

    + +

    Note: Postfix 2.9.0–2.9.5 computed the public key +fingerprint incorrectly. To use public-key fingerprints, upgrade +to Postfix 2.9.6 or later.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_tls_fingerprint_cert_match + +

    List of acceptable remote SMTP server certificate fingerprints for +the "fingerprint" TLS security level (smtp_tls_security_level = +fingerprint). At this security level, Certification Authorities are not +used, and certificate expiration times are ignored. Instead, server +certificates are verified directly via their certificate fingerprint +or public key fingerprint (Postfix 2.9 and later). The fingerprint +is a message digest of the server certificate (or public key). The +digest algorithm is selected via the smtp_tls_fingerprint_digest +parameter.

    + +

    When an smtp_tls_policy_maps table entry specifies the +"fingerprint" security level, any "match" attributes in that entry specify +the list of valid fingerprints for the corresponding destination. Multiple +fingerprints can be combined with a "|" delimiter in a single match +attribute, or multiple match attributes can be employed.

    + +

    Example: Certificate fingerprint verification with internal mailhub. +Two matching fingerprints are listed. The relayhost may be multiple +physical hosts behind a load-balancer, each with its own private/public +key and self-signed certificate. Alternatively, a single relayhost may +be in the process of switching from one set of private/public keys to +another, and both keys are trusted just prior to the transition.

    + +
    +
    +relayhost = [mailhub.example.com]
+smtp_tls_security_level = fingerprint
+smtp_tls_fingerprint_digest = md5
+smtp_tls_fingerprint_cert_match =
+    3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+    EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
    +
    + +

    Example: Certificate fingerprint verification with selected destinations. +As in the example above, we show two matching fingerprints:

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+    smtp_tls_fingerprint_digest = md5
+
    +
    + +
    +
    +/etc/postfix/tls_policy:
+    example.com	fingerprint
+        match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+        match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
    +
    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_tls_fingerprint_cert_match + +

    The LMTP-specific version of the smtp_tls_fingerprint_cert_match +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_tls_fingerprint_digest md5 + +

    The LMTP-specific version of the smtp_tls_fingerprint_digest +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtpd_tls_fingerprint_digest md5 + +

    The message digest algorithm to construct remote SMTP +client-certificate +fingerprints or public key fingerprints (Postfix 2.9 and later) +for check_ccert_access and permit_tls_clientcerts. The +default algorithm is md5, for backwards compatibility with Postfix +releases prior to 2.5.

    + +

    Advances in hash +function cryptanalysis have led to md5 being deprecated in favor of sha1. +However, as long as there are no known "second pre-image" attacks +against md5, its use in this context can still be considered safe. +

    + +

    While additional digest algorithms are often available with OpenSSL's +libcrypto, only those used by libssl in SSL cipher suites are available to +Postfix.

    + +

    To find the fingerprint of a specific certificate file, with a +specific digest algorithm, run:

    + +
    +
    +$ openssl x509 -noout -fingerprint -digest -in certfile.pem
+
    +
    + +

    The text to the right of "=" sign is the desired fingerprint. +For example:

    + +
    +
    +$ openssl x509 -noout -fingerprint -sha1 -in cert.pem
+SHA1 Fingerprint=D4:6A:AB:19:24:79:F8:32:BB:A6:CB:66:82:C0:8E:9B:EE:29:A8:1A
+
    +
    + +

    To extract the public key fingerprint from an X.509 certificate, +you need to extract the public key from the certificate and compute +the appropriate digest of its DER (ASN.1) encoding. With OpenSSL +the "-pubkey" option of the "x509" command extracts the public +key always in "PEM" format. We pipe the result to another OpenSSL +command that converts the key to DER and then to the "dgst" command +to compute the fingerprint.

    + +

    The actual command to transform the key to DER format depends +on the version of OpenSSL used. With OpenSSL 1.0.0 and later, the +"pkey" command supports all key types. With OpenSSL 0.9.8 and +earlier, the key type is always RSA (nobody uses DSA, and EC +keys are not fully supported by 0.9.8), so the "rsa" command is +used.

    +
    +
    +# OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl pkey -pubin -outform DER |
+    openssl dgst -sha1 -c
+(stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
+
    +
    + +
    +
    +# OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey |
+    openssl rsa -pubin -outform DER |
+    openssl dgst -md5 -c
+(stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
+
    +
    + +

    The Postfix SMTP server and client log the peer (leaf) certificate +fingerprint and public key fingerprint when the TLS loglevel is 2 or +higher.

    + +

    Note: Postfix 2.9.0–2.9.5 computed the public key +fingerprint incorrectly. To use public-key fingerprints, upgrade +to Postfix 2.9.6 or later.

    + +

    Example: client-certificate access table, with sha1 fingerprints:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_tls_fingerprint_digest = sha1
+    smtpd_client_restrictions =
+        check_ccert_access hash:/etc/postfix/access,
+        reject
+
    +
    +/etc/postfix/access:
+    # Action folded to next line...
+    AF:88:7C:AD:51:95:6F:36:96:F6:01:FB:2E:48:CD:AB:49:25:A2:3B
+        OK
+    85:16:78:FD:73:6E:CE:70:E0:31:5F:0D:3C:C8:6D:C4:2C:24:59:E1
+        permit_auth_destination
+
    +
    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_pix_workaround_maps + +

    The LMTP-specific version of the smtp_pix_workaround_maps +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.4 and later.

    + +%PARAM detect_8bit_encoding_header yes + +

    Automatically detect 8BITMIME body content by looking at +Content-Transfer-Encoding: message headers; historically, this +behavior was hard-coded to be "always on".

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM send_cyrus_sasl_authzid no + +

    When authenticating to a remote SMTP or LMTP server with the +default setting "no", send no SASL authoriZation ID (authzid); send +only the SASL authentiCation ID (authcid) plus the authcid's password. +

    + +

    The non-default setting "yes" enables the behavior of older +Postfix versions. These always send a SASL authzid that is equal +to the SASL authcid, but this causes interoperability problems +with some SMTP servers.

    + +

    This feature is available in Postfix 2.4.4 and later.

    + +%PARAM smtpd_client_port_logging no + +

    Enable logging of the remote SMTP client port in addition to +the hostname and IP address. The logging format is "host[address]:port". +

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM qmqpd_client_port_logging no + +

    Enable logging of the remote QMQP client port in addition to +the hostname and IP address. The logging format is "host[address]:port". +

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_tls_protocols !SSLv2, !SSLv3 + +

    List of TLS protocols that the Postfix SMTP client will exclude or +include with opportunistic TLS encryption. The default value is +"!SSLv2, !SSLv3" for Postfix releases after the middle of 2015, +"!SSLv2" for older releases. Before Postfix 2.6, the Postfix SMTP +client would use all protocols with opportunistic TLS.

    + +

    In main.cf the values are separated by whitespace, commas or +colons. In the policy table (see smtp_tls_policy_maps) the only valid +separator is colon. An empty value means allow all protocols. The valid +protocol names, (see SSL_get_version(3)), are "SSLv2", "SSLv3" +and "TLSv1".

    + +

    The range of protocols advertised by an SSL/TLS client must be +contiguous. When a protocol version is enabled, disabling any +higher version implicitly disables all versions above that higher version. +Thus, for example (assuming the OpenSSL library supports both SSLv2 +and SSLv3): +

    +
    +
    +smtp_tls_protocols = !SSLv2, !TLSv1
+
    +
    +

    also disables any protocols version higher than TLSv1 leaving +only "SSLv3" enabled.

    + +

    Note: As of OpenSSL 1.0.1 two new protocols are defined, "TLSv1.1" +and "TLSv1.2". The latest patch levels of Postfix ≥ 2.6, and all +versions of Postfix ≥ 2.10 can explicitly disable support for +"TLSv1.1" or "TLSv1.2"

    + +

    OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix +≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2) +this can be disabled, if need be, via "!TLSv1.3".

    + +

    To include a protocol list its name, to exclude it, prefix the name +with a "!" character. To exclude SSLv2 for opportunistic TLS set +"smtp_tls_protocols = !SSLv2". To exclude both "SSLv2" and "SSLv3" set +"smtp_tls_protocols = !SSLv2, !SSLv3". Explicitly listing the protocols to +include, rather than protocols to exclude, is supported, but not +recommended. The exclusion form more closely matches the underlying +OpenSSL interface semantics.

    + +

    Example:

    +
    +# TLSv1 or better:
+smtp_tls_protocols = !SSLv2, !SSLv3
+
    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM smtpd_tls_protocols !SSLv2, !SSLv3 + +

    List of TLS protocols that the Postfix SMTP server will exclude +or include with opportunistic TLS encryption. The default value is +"!SSLv2, !SSLv3" for Postfix releases after the middle of 2015, +empty for older releases allowing all protocols to be +used with opportunistic TLS. A non-empty value is a list of protocol +names separated by whitespace, commas or colons. The supported +protocol names are "SSLv2", "SSLv3" and "TLSv1", and are not case +sensitive.

    + +

    Note: As of OpenSSL 1.0.1 two new protocols are defined, "TLSv1.1" +and "TLSv1.2". The latest patch levels of Postfix ≥ 2.6, and all +versions of Postfix ≥ 2.10 can disable support for "TLSv1.1" or +"TLSv1.2".

    + +

    OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix +≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2) +this can be disabled, if need be, via "!TLSv1.3".

    + +

    To include a protocol list its name, to exclude it, prefix the name +with a "!" character. To exclude SSLv2 for opportunistic TLS set +"smtpd_tls_protocols = !SSLv2". To exclude both "SSLv2" and "SSLv3" set +"smtpd_tls_protocols = !SSLv2, !SSLv3". Explicitly listing the protocols to +include, rather than protocols to exclude, is supported, but not +recommended. The exclusion form more closely matches the underlying +OpenSSL interface semantics.

    + +

    Example:

    +
    +smtpd_tls_protocols = !SSLv2, !SSLv3
+
    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM lmtp_tls_protocols !SSLv2, !SSLv3 + +

    The LMTP-specific version of the smtp_tls_protocols configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM smtp_tls_ciphers medium + +

    The minimum TLS cipher grade that the Postfix SMTP client +will use with opportunistic TLS encryption. Cipher types listed in +smtp_tls_exclude_ciphers are excluded from the base definition of +the selected cipher grade. The default value is "medium" for +Postfix releases after the middle of 2015, "export" for older +releases.

    + +

    When TLS is mandatory the cipher grade is chosen via the +smtp_tls_mandatory_ciphers configuration parameter, see there for syntax +details. See smtp_tls_policy_maps for information on how to configure +ciphers on a per-destination basis.

    + +

    This feature is available in Postfix 2.6 and later. With earlier Postfix +releases only the smtp_tls_mandatory_ciphers parameter is implemented, +and opportunistic TLS always uses "export" or better (i.e. all) ciphers.

    + +%PARAM smtpd_tls_ciphers medium + +

    The minimum TLS cipher grade that the Postfix SMTP server +will use with opportunistic TLS encryption. Cipher types listed in +smtpd_tls_exclude_ciphers are excluded from the base definition of +the selected cipher grade. The default value is "medium" for Postfix +releases after the middle of 2015, "export" for older releases. +

    + +

    When TLS is mandatory the cipher grade is chosen via the +smtpd_tls_mandatory_ciphers configuration parameter, see there for syntax +details.

    + +

    This feature is available in Postfix 2.6 and later. With earlier Postfix +releases only the smtpd_tls_mandatory_ciphers parameter is implemented, +and opportunistic TLS always uses "export" or better (i.e. all) ciphers.

    + +%PARAM lmtp_tls_ciphers medium + +

    The LMTP-specific version of the smtp_tls_ciphers configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM tls_eecdh_auto_curves see "postconf -d" output + +

    The prioritized list of elliptic curves supported by the Postfix +SMTP client and server. These curves are used by the Postfix SMTP +server when "smtpd_tls_eecdh_grade = auto". The selected curves +must be implemented by OpenSSL and be standardized for use in TLS +(RFC 4492 or its imminent successor). It is unwise to list only +"bleeding-edge" curves supported by a small subset of clients. The +default list is suitable for most users.

    + +

    Postfix skips curve names that are unknown to OpenSSL, or that +are known but not yet implemented. This makes it possible to +"anticipate" support for curves that should be used once they become +available. In particular, in some OpenSSL versions, the new RFC +8031 curves "X25519" and "X448" may be known by name, but ECDH +support for either or both may be missing. These curves may appear +in the default value of this parameter, even though they'll only +be usable with later versions of OpenSSL.

    + +

    This feature is available in Postfix 3.2 and later, when it is +compiled and linked with OpenSSL 1.0.2 or later on platforms where +EC algorithms have not been disabled by the vendor.

    + +%PARAM tls_eecdh_strong_curve prime256v1 + +

    The elliptic curve used by the Postfix SMTP server for sensibly +strong +ephemeral ECDH key exchange. This curve is used by the Postfix SMTP +server when "smtpd_tls_eecdh_grade = strong". The phrase "sensibly +strong" means approximately 128-bit security based on best known +attacks. The selected curve must be implemented by OpenSSL (as +reported by ecparam(1) with the "-list_curves" option) and be one +of the curves listed in Section 5.1.1 of RFC 4492. You should not +generally change this setting. Remote SMTP client implementations +must support this curve for EECDH key exchange to take place. It +is unwise to choose an "bleeding-edge" curve supported by only a +small subset of clients.

    + +

    The default "strong" curve is rated in NSA Suite +B for information classified up to SECRET.

    + +

    Note: elliptic curve names are poorly standardized; different +standards groups are assigning different names to the same underlying +curves. The curve with the X9.62 name "prime256v1" is also known +under the SECG name "secp256r1", but OpenSSL does not recognize the +latter name.

    + +

    If you want to take maximal advantage of ciphers that offer forward secrecy see +the Getting +started section of FORWARD_SECRECY_README. The +full document conveniently presents all information about Postfix +"perfect" forward secrecy support in one place: what forward secrecy +is, how to tweak settings, and what you can expect to see when +Postfix uses ciphers with forward secrecy.

    + +

    This feature is available in Postfix 2.6 and later, when it is +compiled and linked with OpenSSL 1.0.0 or later on platforms where +EC algorithms have not been disabled by the vendor.

    + +%PARAM tls_eecdh_ultra_curve secp384r1 + +

    The elliptic curve used by the Postfix SMTP server for maximally +strong +ephemeral ECDH key exchange. This curve is used by the Postfix SMTP +server when "smtpd_tls_eecdh_grade = ultra". The phrase "maximally +strong" means approximately 192-bit security based on best known attacks. +This additional strength comes at a significant computational cost, most +users should instead set "smtpd_tls_eecdh_grade = strong". The selected +curve must be implemented by OpenSSL (as reported by ecparam(1) with the +"-list_curves" option) and be one of the curves listed in Section 5.1.1 +of RFC 4492. You should not generally change this setting.

    + +

    This default "ultra" curve is rated in NSA Suite +B for information classified up to TOP SECRET.

    + +

    If you want to take maximal advantage of ciphers that offer forward secrecy see +the Getting +started section of FORWARD_SECRECY_README. The +full document conveniently presents all information about Postfix +"perfect" forward secrecy support in one place: what forward secrecy +is, how to tweak settings, and what you can expect to see when +Postfix uses ciphers with forward secrecy.

    + +

    This feature is available in Postfix 2.6 and later, when it is +compiled and linked with OpenSSL 1.0.0 or later on platforms where +EC algorithms have not been disabled by the vendor.

    + +%PARAM smtpd_tls_eecdh_grade see "postconf -d" output + +

    The Postfix SMTP server security grade for ephemeral elliptic-curve +Diffie-Hellman (EECDH) key exchange.

    + +

    The available choices are:

    + +
    + +
    none
    Don't use EECDH. Ciphers based on EECDH key +exchange will be disabled. This is the default in Postfix versions +2.6 and 2.7.
    + +
    strong
    Use EECDH with approximately 128 +bits of security at a reasonable computational cost. This is the +current best-practice trade-off between security and computational +efficiency. This is the default in Postfix version 2.8 and later. +
    + +
    ultra
    Use EECDH with approximately 192 bits of +security at computational cost that is approximately twice as high +as 128 bit strength ECC. Barring significant progress in attacks on +elliptic curve crypto-systems, the "strong" curve is sufficient for most +users.
    + +
    auto
    Use the most preferred curve that is +supported by both the client and the server. This setting requires +Postfix ≥ 3.2 compiled and linked with OpenSSL ≥ 1.0.2. This +is the default setting under the above conditions.
    + +
    + +

    If you want to take maximal advantage of ciphers that offer forward secrecy see +the Getting +started section of FORWARD_SECRECY_README. The +full document conveniently presents all information about Postfix +"perfect" forward secrecy support in one place: what forward secrecy +is, how to tweak settings, and what you can expect to see when +Postfix uses ciphers with forward secrecy.

    + +

    This feature is available in Postfix 2.6 and later, when it is +compiled and linked with OpenSSL 1.0.0 or later on platforms +where EC algorithms have not been disabled by the vendor.

    + +%PARAM smtpd_tls_eccert_file + +

    File with the Postfix SMTP server ECDSA certificate in PEM format. +This file may also contain the Postfix SMTP server private ECDSA key. +With Postfix ≥ 3.4 the preferred way to configure server keys and +certificates is via the "smtpd_tls_chain_files" parameter.

    + +

    See the discussion under smtpd_tls_cert_file for more details.

    + +

    Example:

    + +
    +smtpd_tls_eccert_file = /etc/postfix/ecdsa-scert.pem
+
    + +

    This feature is available in Postfix 2.6 and later, when Postfix is +compiled and linked with OpenSSL 1.0.0 or later.

    + +%PARAM smtpd_tls_eckey_file $smtpd_tls_eccert_file + +

    File with the Postfix SMTP server ECDSA private key in PEM format. +This file may be combined with the Postfix SMTP server ECDSA certificate +file specified with $smtpd_tls_eccert_file. With Postfix ≥ 3.4 the +preferred way to configure server keys and certificates is via the +"smtpd_tls_chain_files" parameter.

    + +

    The private key must be accessible without a pass-phrase, i.e. it +must not be encrypted. File permissions should grant read-only +access to the system superuser account ("root"), and no access +to anyone else.

    + +

    This feature is available in Postfix 2.6 and later, when Postfix is +compiled and linked with OpenSSL 1.0.0 or later.

    + +%PARAM smtp_tls_eccert_file + +

    File with the Postfix SMTP client ECDSA certificate in PEM format. +This file may also contain the Postfix SMTP client ECDSA private key. +With Postfix ≥ 3.4 the preferred way to configure client keys and +certificates is via the "smtp_tls_chain_files" parameter.

    + +

    See the discussion under smtp_tls_cert_file for more details. +

    + +

    Example:

    + +
    +smtp_tls_eccert_file = /etc/postfix/ecdsa-ccert.pem
+
    + +

    This feature is available in Postfix 2.6 and later, when Postfix is +compiled and linked with OpenSSL 1.0.0 or later.

    + +%PARAM smtp_tls_eckey_file $smtp_tls_eccert_file + +

    File with the Postfix SMTP client ECDSA private key in PEM format. +This file may be combined with the Postfix SMTP client ECDSA certificate +file specified with $smtp_tls_eccert_file. With Postfix ≥ 3.4 the +preferred way to configure client keys and certificates is via the +"smtp_tls_chain_files" parameter.

    + +

    The private key must be accessible without a pass-phrase, i.e. it +must not be encrypted. File permissions should grant read-only +access to the system superuser account ("root"), and no access +to anyone else.

    + +

    This feature is available in Postfix 2.6 and later, when Postfix is +compiled and linked with OpenSSL 1.0.0 or later.

    + +%PARAM lmtp_tls_eccert_file + +

    The LMTP-specific version of the smtp_tls_eccert_file configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.6 and later, when Postfix is +compiled and linked with OpenSSL 1.0.0 or later.

    + +%PARAM lmtp_tls_eckey_file + +

    The LMTP-specific version of the smtp_tls_eckey_file configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.6 and later, when Postfix is +compiled and linked with OpenSSL 1.0.0 or later.

    + +%PARAM smtp_header_checks + +

    Restricted header_checks(5) tables for the Postfix SMTP client. +These tables are searched while mail is being delivered. Actions +that change the delivery time or destination are not available. +

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_mime_header_checks + +

    Restricted mime_header_checks(5) tables for the Postfix SMTP +client. These tables are searched while mail is being delivered. +Actions that change the delivery time or destination are not +available.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_nested_header_checks + +

    Restricted nested_header_checks(5) tables for the Postfix SMTP +client. These tables are searched while mail is being delivered. +Actions that change the delivery time or destination are not +available.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_body_checks + +

    Restricted body_checks(5) tables for the Postfix SMTP client. +These tables are searched while mail is being delivered. Actions +that change the delivery time or destination are not available. +

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM destination_concurrency_feedback_debug no + +

    Make the queue manager's feedback algorithm verbose for performance +analysis purposes.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM default_destination_concurrency_failed_cohort_limit 1 + +

    How many pseudo-cohorts must suffer connection or handshake +failure before a specific destination is considered unavailable +(and further delivery is suspended). Specify zero to disable this +feature. A destination's pseudo-cohort failure count is reset each +time a delivery completes without connection or handshake failure +for that specific destination.

    + +

    A pseudo-cohort is the number of deliveries equal to a destination's +delivery concurrency.

    + +

    Use transport_destination_concurrency_failed_cohort_limit to specify +a transport-specific override, where transport is the master.cf +name of the message delivery transport.

    + +

    This feature is available in Postfix 2.5. The default setting +is compatible with earlier Postfix versions.

    + +%PARAM default_destination_concurrency_negative_feedback 1 + +

    The per-destination amount of delivery concurrency negative +feedback, after a delivery completes with a connection or handshake +failure. Feedback values are in the range 0..1 inclusive. With +negative feedback, concurrency is decremented at the beginning of +a sequence of length 1/feedback. This is unlike positive feedback, +where concurrency is incremented at the end of a sequence of length +1/feedback.

    + +

    As of Postfix version 2.5, negative feedback cannot reduce +delivery concurrency to zero. Instead, a destination is marked +dead (further delivery suspended) after the failed pseudo-cohort +count reaches $default_destination_concurrency_failed_cohort_limit +(or $transport_destination_concurrency_failed_cohort_limit). +To make the scheduler completely immune to connection or handshake +failures, specify a zero feedback value and a zero failed pseudo-cohort +limit.

    + +

    Specify one of the following forms:

    + +
    + +
    number
    + +
    number / number
    + +
    Constant feedback. The value must be in the range 0..1 inclusive. +The default setting of "1" is compatible with Postfix versions +before 2.5, where a destination's delivery concurrency is throttled +down to zero (and further delivery suspended) after a single failed +pseudo-cohort.
    + +
    number / concurrency
    + +
    Variable feedback of "number / (delivery concurrency)". +The number must be in the range 0..1 inclusive. With +number equal to "1", a destination's delivery concurrency +is decremented by 1 after each failed pseudo-cohort.
    + + + +
    + +

    A pseudo-cohort is the number of deliveries equal to a destination's +delivery concurrency.

    + +

    Use transport_destination_concurrency_negative_feedback +to specify a transport-specific override, where transport +is the master.cf +name of the message delivery transport.

    + +

    This feature is available in Postfix 2.5. The default setting +is compatible with earlier Postfix versions.

    + +%PARAM default_destination_concurrency_positive_feedback 1 + +

    The per-destination amount of delivery concurrency positive +feedback, after a delivery completes without connection or handshake +failure. Feedback values are in the range 0..1 inclusive. The +concurrency increases until it reaches the per-destination maximal +concurrency limit. With positive feedback, concurrency is incremented +at the end of a sequence with length 1/feedback. This is unlike +negative feedback, where concurrency is decremented at the start +of a sequence of length 1/feedback.

    + +

    Specify one of the following forms:

    + +
    + +
    number
    + +
    number / number
    + +
    Constant feedback. The value must be in the range 0..1 +inclusive. The default setting of "1" is compatible with Postfix +versions before 2.5, where a destination's delivery concurrency +doubles after each successful pseudo-cohort.
    + +
    number / concurrency
    + +
    Variable feedback of "number / (delivery concurrency)". +The number must be in the range 0..1 inclusive. With +number equal to "1", a destination's delivery concurrency +is incremented by 1 after each successful pseudo-cohort.
    + + + +
    + +

    A pseudo-cohort is the number of deliveries equal to a destination's +delivery concurrency.

    + +

    Use transport_destination_concurrency_positive_feedback +to specify a transport-specific override, where transport +is the master.cf name of the message delivery transport.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM transport_destination_concurrency_failed_cohort_limit $default_destination_concurrency_failed_cohort_limit + +

    A transport-specific override for the +default_destination_concurrency_failed_cohort_limit parameter value, +where transport is the master.cf name of the message delivery +transport.

    + +

    Note: some transport_destination_concurrency_failed_cohort_limit +parameters will not show up in "postconf" command output before +Postfix version 2.9. This limitation applies to many parameters +whose name is a combination of a master.cf service name and a +built-in suffix (in this case: +"_destination_concurrency_failed_cohort_limit").

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM transport_destination_concurrency_positive_feedback $default_destination_concurrency_positive_feedback + +

    A transport-specific override for the +default_destination_concurrency_positive_feedback parameter value, +where transport is the master.cf name of the message delivery +transport.

    + +

    Note: some transport_destination_concurrency_positive_feedback +parameters will not show up in "postconf" command output before +Postfix version 2.9. This limitation applies to many parameters +whose name is a combination of a master.cf service name and a +built-in suffix (in this case: +"_destination_concurrency_positive_feedback").

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM transport_destination_concurrency_negative_feedback $default_destination_concurrency_negative_feedback + +

    A transport-specific override for the +default_destination_concurrency_negative_feedback parameter value, +where transport is the master.cf name of the message delivery +transport.

    + +

    Note: some transport_destination_concurrency_negative_feedback +parameters will not show up in "postconf" command output before +Postfix version 2.9. This limitation applies to many parameters +whose name is a combination of a master.cf service name and a +built-in suffix (in this case: +"_destination_concurrency_negative_feedback").

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM transport_initial_destination_concurrency $initial_destination_concurrency + +

    A transport-specific override for the initial_destination_concurrency +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: some transport_initial_destination_concurrency +parameters will not show up in "postconf" command output before +Postfix version 2.9. This limitation applies to many parameters +whose name is a combination of a master.cf service name and a +built-in suffix (in this case: "_initial_destination_concurrency"). +

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM transport_destination_concurrency_limit $default_destination_concurrency_limit + +

    A transport-specific override for the +default_destination_concurrency_limit parameter value, where +transport is the master.cf name of the message delivery +transport.

    + +

    Note: some transport_destination_concurrency_limit +parameters will not show up in "postconf" command output before +Postfix version 2.9. This limitation applies to many parameters +whose name is a combination of a master.cf service name and a +built-in suffix (in this case: "_destination_concurrency_limit"). +

    + +%PARAM transport_destination_recipient_limit $default_destination_recipient_limit + +

    A transport-specific override for the +default_destination_recipient_limit parameter value, where +transport is the master.cf name of the message delivery +transport.

    + +

    Note: some transport_destination_recipient_limit parameters +will not show up in "postconf" command output before Postfix version +2.9. This limitation applies to many parameters whose name is a +combination of a master.cf service name and a built-in suffix (in +this case: "_destination_recipient_limit").

    + +%PARAM transport_time_limit $command_time_limit + +

    A transport-specific override for the command_time_limit parameter +value, where transport is the master.cf name of the message +delivery transport.

    + +

    Note: transport_time_limit parameters will not show up +in "postconf" command output before Postfix version 2.9. This +limitation applies to many parameters whose name is a combination +of a master.cf service name and a built-in suffix (in this case: +"_time_limit").

    + +%PARAM transport_delivery_slot_cost $default_delivery_slot_cost + +

    A transport-specific override for the default_delivery_slot_cost +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: transport_delivery_slot_cost parameters will not +show up in "postconf" command output before Postfix version 2.9. +This limitation applies to many parameters whose name is a combination +of a master.cf service name and a built-in suffix (in this case: +"_delivery_slot_cost").

    + +%PARAM transport_delivery_slot_loan $default_delivery_slot_loan + +

    A transport-specific override for the default_delivery_slot_loan +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: transport_delivery_slot_loan parameters will not +show up in "postconf" command output before Postfix version 2.9. +This limitation applies to many parameters whose name is a combination +of a master.cf service name and a built-in suffix (in this case: +"_delivery_slot_loan").

    + +%PARAM transport_delivery_slot_discount $default_delivery_slot_discount + +

    A transport-specific override for the default_delivery_slot_discount +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: transport_delivery_slot_discount parameters will +not show up in "postconf" command output before Postfix version +2.9. This limitation applies to many parameters whose name is a +combination of a master.cf service name and a built-in suffix (in +this case: "_delivery_slot_discount").

    + +%PARAM transport_minimum_delivery_slots $default_minimum_delivery_slots + +

    A transport-specific override for the default_minimum_delivery_slots +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: transport_minimum_delivery_slots parameters will +not show up in "postconf" command output before Postfix version +2.9. This limitation applies to many parameters whose name is a +combination of a master.cf service name and a built-in suffix (in +this case: "_minimum_delivery_slots").

    + +%PARAM transport_recipient_limit $default_recipient_limit + +

    A transport-specific override for the default_recipient_limit +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: some transport_recipient_limit parameters will not +show up in "postconf" command output before Postfix version 2.9. +This limitation applies to many parameters whose name is a combination +of a master.cf service name and a built-in suffix (in this case: +"_recipient_limit").

    + +%PARAM transport_extra_recipient_limit $default_extra_recipient_limit + +

    A transport-specific override for the default_extra_recipient_limit +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: transport_extra_recipient_limit parameters will +not show up in "postconf" command output before Postfix version +2.9. This limitation applies to many parameters whose name is a +combination of a master.cf service name and a built-in suffix (in +this case: "_extra_recipient_limit").

    + +%PARAM transport_recipient_refill_limit $default_recipient_refill_limit + +

    A transport-specific override for the default_recipient_refill_limit +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: transport_recipient_refill_limit parameters will +not show up in "postconf" command output before Postfix version +2.9. This limitation applies to many parameters whose name is a +combination of a master.cf service name and a built-in suffix (in +this case: "_recipient_refill_limit").

    + +

    This feature is available in Postfix 2.4 and later.

    + +%PARAM transport_recipient_refill_delay $default_recipient_refill_delay + +

    A transport-specific override for the default_recipient_refill_delay +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: transport_recipient_refill_delay parameters will +not show up in "postconf" command output before Postfix version +2.9. This limitation applies to many parameters whose name is a +combination of a master.cf service name and a built-in suffix (in +this case: "_recipient_refill_delay").

    + +

    This feature is available in Postfix 2.4 and later.

    + +%PARAM default_transport_rate_delay 0s + +

    The default amount of delay that is inserted between individual +message deliveries over the same message delivery transport, +regardless of destination. Specify a non-zero value to rate-limit +those message deliveries to at most one per $default_transport_rate_delay. +

    + +

    Use transport_transport_rate_delay to specify a +transport-specific override, where the initial transport is +the master.cf name of the message delivery transport.

    + +

    Example: throttle outbound SMTP mail to at most 3 deliveries +per minute.

    + +
    +/etc/postfix/main.cf:
+    smtp_transport_rate_delay = 20s
+
    + +

    To enable the delay, specify a non-zero time value (an integral +value plus an optional one-letter suffix that specifies the time +unit).

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks). The default time unit is s (seconds).

    + +

    NOTE: the delay is enforced by the queue manager.

    + +

    This feature is available in Postfix 3.1 and later.

    + +%PARAM transport_transport_rate_delay $default_transport_rate_delay + +

    A transport-specific override for the default_transport_rate_delay +parameter value, where the initial transport in the parameter +name is the master.cf name of the message delivery transport.

    + +%PARAM default_destination_rate_delay 0s + +

    The default amount of delay that is inserted between individual +message deliveries to the same destination and over the same message +delivery transport. Specify a non-zero value to rate-limit those +message deliveries to at most one per $default_destination_rate_delay. +

    + +

    The resulting behavior depends on the value of the corresponding +per-destination recipient limit. + +

    + +
      + +

    • With a corresponding per-destination recipient limit > +1, the rate delay specifies the time between deliveries to the +same domain. Different domains are delivered in parallel, +subject to the process limits specified in master.cf.

      + +

    • With a corresponding per-destination recipient limit equal +to 1, the rate delay specifies the time between deliveries to the +same recipient. Different recipients are delivered in +parallel, subject to the process limits specified in master.cf. +

      + +
    + +

    To enable the delay, specify a non-zero time value (an integral +value plus an optional one-letter suffix that specifies the time +unit).

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks). The default time unit is s (seconds).

    + +

    NOTE: the delay is enforced by the queue manager. The delay +timer state does not survive "postfix reload" or "postfix +stop". +

    + +

    Use transport_destination_rate_delay to specify a +transport-specific override, where transport is the master.cf +name of the message delivery transport. +

    + +

    NOTE: with a non-zero _destination_rate_delay, specify a +transport_destination_concurrency_failed_cohort_limit of 10 +or more to prevent Postfix from deferring all mail for the same +destination after only one connection or handshake error.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM transport_destination_rate_delay $default_destination_rate_delay + +

    A transport-specific override for the default_destination_rate_delay +parameter value, where transport is the master.cf name of +the message delivery transport.

    + +

    Note: some transport_destination_rate_delay parameters +will not show up in "postconf" command output before Postfix version +2.9. This limitation applies to many parameters whose name is a +combination of a master.cf service name and a built-in suffix (in +this case: "_destination_rate_delay").

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM data_directory see "postconf -d" output + +

    The directory with Postfix-writable data files (for example: +caches, pseudo-random numbers). This directory must be owned by +the mail_owner account, and must not be shared with non-Postfix +software.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM stress + +

    This feature is documented in the STRESS_README document.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_sasl_auth_soft_bounce yes + +

    When a remote SMTP server rejects a SASL authentication request +with a 535 reply code, defer mail delivery instead of returning +mail as undeliverable. The latter behavior was hard-coded prior to +Postfix version 2.5.

    + +

    Note: the setting "yes" overrides the global soft_bounce +parameter, but the setting "no" does not.

    + +

    Example:

    + +
    +# Default as of Postfix 2.5
+smtp_sasl_auth_soft_bounce = yes
+# The old hard-coded default
+smtp_sasl_auth_soft_bounce = no
+
    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_sasl_auth_cache_name + +

    An optional table to prevent repeated SASL authentication +failures with the same remote SMTP server hostname, username and +password. Each table (key, value) pair contains a server name, a +username and password, and the full server response. This information +is stored when a remote SMTP server rejects an authentication attempt +with a 535 reply code. As long as the smtp_sasl_password_maps +information does no change, and as long as the smtp_sasl_auth_cache_name +information does not expire (see smtp_sasl_auth_cache_time) the +Postfix SMTP client avoids SASL authentication attempts with the +same server, username and password, and instead bounces or defers +mail as controlled with the smtp_sasl_auth_soft_bounce configuration +parameter.

    + +

    Use a per-destination delivery concurrency of 1 (for example, +"smtp_destination_concurrency_limit = 1", +"relay_destination_concurrency_limit = 1", etc.), otherwise multiple +delivery agents may experience a login failure at the same time. +

    + +

    The table must be accessed via the proxywrite service, i.e. the +map name must start with "proxy:". The table should be stored under +the directory specified with the data_directory parameter.

    + +

    This feature uses cryptographic hashing to protect plain-text +passwords, and requires that Postfix is compiled with TLS support. +

    + +

    Example:

    + +
    +smtp_sasl_auth_cache_name = proxy:btree:/var/lib/postfix/sasl_auth_cache
+
    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM smtp_sasl_auth_cache_time 90d + +

    The maximal age of an smtp_sasl_auth_cache_name entry before it +is removed.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_sasl_auth_soft_bounce yes + +

    The LMTP-specific version of the smtp_sasl_auth_soft_bounce +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_sasl_auth_cache_name + +

    The LMTP-specific version of the smtp_sasl_auth_cache_name +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_sasl_auth_cache_time 90d + +

    The LMTP-specific version of the smtp_sasl_auth_cache_time +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM unverified_sender_reject_reason + +

    The Postfix SMTP server's reply when rejecting mail with +reject_unverified_sender. Do not include the numeric SMTP reply +code or the enhanced status code. By default, the response includes +actual address verification details. + +

    Example:

    + +
    +unverified_sender_reject_reason = Sender address lookup failed
+
    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM unverified_recipient_reject_reason + +

    The Postfix SMTP server's reply when rejecting mail with +reject_unverified_recipient. Do not include the numeric SMTP reply +code or the enhanced status code. By default, the response includes +actual address verification details. + +

    Example:

    + +
    +unverified_recipient_reject_reason = Recipient address lookup failed
+
    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM strict_mailbox_ownership yes + +

    Defer delivery when a mailbox file is not owned by its recipient. +The default setting is not backwards compatible.

    + +

    This feature is available in Postfix 2.5.3 and later.

    + +%PARAM proxymap_service_name proxymap + +

    The name of the proxymap read-only table lookup service. This +service is normally implemented by the proxymap(8) daemon.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM proxywrite_service_name proxywrite + +

    The name of the proxywrite read-write table lookup service. +This service is normally implemented by the proxymap(8) daemon. +

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM master_service_disable + +

    Selectively disable master(8) listener ports by service type +or by service name and type. Specify a list of service types +("inet", "unix", "fifo", or "pass") or "name/type" tuples, where +"name" is the first field of a master.cf entry and "type" is a +service type. As with other Postfix matchlists, a search stops at +the first match. Specify "!pattern" to exclude a service from the +list. By default, all master(8) listener ports are enabled.

    + +

    Note: this feature does not support "/file/name" or "type:table" +patterns, nor does it support wildcards such as "*" or "all". This +is intentional.

    + +

    Examples:

    + +
    +# With Postfix 2.6..2.10 use '.' instead of '/'.
+# Turn on all master(8) listener ports (the default).
+master_service_disable =
+# Turn off only the main SMTP listener port.
+master_service_disable = smtp/inet
+# Turn off all TCP/IP listener ports.
+master_service_disable = inet
+# Turn off all TCP/IP listener ports except "foo".
+master_service_disable = !foo/inet, inet
+
    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM tcp_windowsize 0 + +

    An optional workaround for routers that break TCP window scaling. +Specify a value > 0 and < 65536 to enable this feature. With +Postfix TCP servers (smtpd(8), qmqpd(8)), this feature is implemented +by the Postfix master(8) daemon.

    + +

    To change this parameter without stopping Postfix, you need to +first terminate all Postfix TCP servers:

    + +
    +
    +# postconf -e master_service_disable=inet
+# postfix reload
+
    +
    + +

    This immediately terminates all processes that accept network +connections. Next, you enable Postfix TCP servers with the updated +tcp_windowsize setting:

    + +
    +
    +# postconf -e tcp_windowsize=65535 master_service_disable=
+# postfix reload
+
    +
    + +

    If you skip these steps with a running Postfix system, then the +tcp_windowsize change will work only for Postfix TCP clients (smtp(8), +lmtp(8)).

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM multi_instance_directories + +

    An optional list of non-default Postfix configuration directories; +these directories belong to additional Postfix instances that share +the Postfix executable files and documentation with the default +Postfix instance, and that are started, stopped, etc., together +with the default Postfix instance. Specify a list of pathnames +separated by comma or whitespace.

    + +

    When $multi_instance_directories is empty, the postfix(1) command +runs in single-instance mode and operates on a single Postfix +instance only. Otherwise, the postfix(1) command runs in multi-instance +mode and invokes the multi-instance manager specified with the +multi_instance_wrapper parameter. The multi-instance manager in +turn executes postfix(1) commands for the default instance and for +all Postfix instances in $multi_instance_directories.

    + +

    Currently, this parameter setting is ignored except for the +default main.cf file.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM multi_instance_wrapper + +

    The pathname of a multi-instance manager command that the +postfix(1) command invokes when the multi_instance_directories +parameter value is non-empty. The pathname may be followed by +initial command arguments separated by whitespace; shell +metacharacters such as quotes are not supported in this context. +

    + +

    The postfix(1) command invokes the manager command with the +postfix(1) non-option command arguments on the manager command line, +and with all installation configuration parameters exported into +the manager command process environment. The manager command in +turn invokes the postfix(1) command for individual Postfix instances +as "postfix -c config_directory command".

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM multi_instance_group + +

    The optional instance group name of this Postfix instance. A +group identifies closely-related Postfix instances that the +multi-instance manager can start, stop, etc., as a unit. This +parameter is reserved for the multi-instance manager.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM multi_instance_name + +

    The optional instance name of this Postfix instance. This name +becomes also the default value for the syslog_name parameter.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM multi_instance_enable no + +

    Allow this Postfix instance to be started, stopped, etc., by a +multi-instance manager. By default, new instances are created in +a safe state that prevents them from being started inadvertently. +This parameter is reserved for the multi-instance manager.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM reject_tempfail_action defer_if_permit + +

    The Postfix SMTP server's action when a reject-type restriction +fails due to a temporary error condition. Specify "defer" to defer +the remote SMTP client request immediately. With the default +"defer_if_permit" action, the Postfix SMTP server continues to look +for opportunities to reject mail, and defers the client request +only if it would otherwise be accepted.

    + +

    For finer control, see: unverified_recipient_tempfail_action, +unverified_sender_tempfail_action, unknown_address_tempfail_action, +and unknown_helo_hostname_tempfail_action.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM unverified_recipient_tempfail_action $reject_tempfail_action + +

    The Postfix SMTP server's action when reject_unverified_recipient +fails due to a temporary error condition. Specify "defer" to defer +the remote SMTP client request immediately. With the default +"defer_if_permit" action, the Postfix SMTP server continues to look +for opportunities to reject mail, and defers the client request +only if it would otherwise be accepted.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM unverified_sender_tempfail_action $reject_tempfail_action + +

    The Postfix SMTP server's action when reject_unverified_sender +fails due to a temporary error condition. Specify "defer" to defer +the remote SMTP client request immediately. With the default +"defer_if_permit" action, the Postfix SMTP server continues to look +for opportunities to reject mail, and defers the client request +only if it would otherwise be accepted.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM unknown_address_tempfail_action $reject_tempfail_action + +

    The Postfix SMTP server's action when reject_unknown_sender_domain +or reject_unknown_recipient_domain fail due to a temporary error +condition. Specify "defer" to defer the remote SMTP client request +immediately. With the default "defer_if_permit" action, the Postfix +SMTP server continues to look for opportunities to reject mail, and +defers the client request only if it would otherwise be accepted. +

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM unknown_helo_hostname_tempfail_action $reject_tempfail_action + +

    The Postfix SMTP server's action when reject_unknown_helo_hostname +fails due to a temporary error condition. Specify "defer" to defer +the remote SMTP client request immediately. With the default +"defer_if_permit" action, the Postfix SMTP server continues to look +for opportunities to reject mail, and defers the client request +only if it would otherwise be accepted.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM postmulti_start_commands start + +

    The postfix(1) commands that the postmulti(1) instance manager treats +as "start" commands. For these commands, disabled instances are "checked" +rather than "started", and failure to "start" a member instance of an +instance group will abort the start-up of later instances.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM postmulti_stop_commands see "postconf -d" output + +

    The postfix(1) commands that the postmulti(1) instance manager treats +as "stop" commands. For these commands, disabled instances are skipped, +and enabled instances are processed in reverse order.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM postmulti_control_commands reload flush + +

    The postfix(1) commands that the postmulti(1) instance manager +treats as "control" commands, that operate on running instances. For +these commands, disabled instances are skipped.

    + +

    This feature is available in Postfix 2.6 and later.

    + +%PARAM lmtp_assume_final no + +

    When a remote LMTP server announces no DSN support, assume that +the +server performs final delivery, and send "delivered" delivery status +notifications instead of "relayed". The default setting is backwards +compatible to avoid the infinitesimal possibility of breaking +existing LMTP-based content filters.

    + +%PARAM always_add_missing_headers no + +

    Always add (Resent-) From:, To:, Date: or Message-ID: headers +when not present. Postfix 2.6 and later add these headers only +when clients match the local_header_rewrite_clients parameter +setting. Earlier Postfix versions always add these headers; this +may break DKIM signatures that cover non-existent headers. +The undisclosed_recipients_header parameter setting determines +whether a To: header will be added.

    + +%PARAM lmtp_header_checks + +

    The LMTP-specific version of the smtp_header_checks configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_mime_header_checks + +

    The LMTP-specific version of the smtp_mime_header_checks +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_nested_header_checks + +

    The LMTP-specific version of the smtp_nested_header_checks +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM lmtp_body_checks + +

    The LMTP-specific version of the smtp_body_checks configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 2.5 and later.

    + +%PARAM milter_header_checks + +

    Optional lookup tables for content inspection of message headers +that are produced by Milter applications. See the header_checks(5) +manual page available actions. Currently, PREPEND is not implemented. +

    + +

    The following example sends all mail that is marked as SPAM to +a spam handling machine. Note that matches are case-insensitive +by default.

    + +
    +/etc/postfix/main.cf:
+    milter_header_checks = pcre:/etc/postfix/milter_header_checks
+
    + +
    +/etc/postfix/milter_header_checks:
+    /^X-SPAM-FLAG:\s+YES/ FILTER mysmtp:sanitizer.example.com:25
+
    + +

    The milter_header_checks mechanism could also be used for +whitelisting. For example it could be used to skip heavy content +inspection for DKIM-signed mail from known friendly domains.

    + +

    This feature is available in Postfix 2.7, and as an optional +patch for Postfix 2.6.

    + +%PARAM postscreen_cache_map btree:$data_directory/postscreen_cache + +

    Persistent storage for the postscreen(8) server decisions.

    + +

    To share a postscreen(8) cache between multiple postscreen(8) +instances, use "postscreen_cache_map = proxy:btree:/path/to/file". +This requires Postfix version 2.9 or later; earlier proxymap(8) +implementations don't support cache cleanup. For an alternative +approach see the memcache_table(5) manpage.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM smtpd_service_name smtpd + +

    The internal service that postscreen(8) hands off allowed +connections to. In a future version there may be different +classes of SMTP service.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_post_queue_limit $default_process_limit + +

    The number of clients that can be waiting for service from a +real Postfix SMTP server process. When this queue is full, all +clients will +receive a 421 response.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_pre_queue_limit $default_process_limit + +

    The number of non-whitelisted clients that can be waiting for +a decision whether they will receive service from a real Postfix +SMTP server +process. When this queue is full, all non-whitelisted clients will +receive a 421 response.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_greet_ttl 1d + +

    The amount of time that postscreen(8) will use the result from +a successful PREGREET test. During this time, the client IP address +is excluded from this test. The default is relatively short, because +a good client can immediately talk to a real Postfix SMTP server.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_cache_retention_time 7d + +

    The amount of time that postscreen(8) will cache an expired +temporary whitelist entry before it is removed. This prevents clients +from being logged as "NEW" just because their cache entry expired +an hour ago. It also prevents the cache from filling up with clients +that passed some deep protocol test once and never came back.

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_cache_cleanup_interval 12h + +

    The amount of time between postscreen(8) cache cleanup runs. +Cache cleanup increases the load on the cache database and should +therefore not be run frequently. This feature requires that the +cache database supports the "delete" and "sequence" operators. +Specify a zero interval to disable cache cleanup.

    + +

    After each cache cleanup run, the postscreen(8) daemon logs the +number of entries that were retained and dropped. A cleanup run is +logged as "partial" when the daemon terminates early after "postfix +reload", "postfix stop", or no requests for $max_idle +seconds.

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_greet_wait normal: 6s, overload: 2s + +

    The amount of time that postscreen(8) will wait for an SMTP +client to send a command before its turn, and for DNS blocklist +lookup results to arrive (default: up to 2 seconds under stress, +up to 6 seconds otherwise).

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit).

    + +

    Time units: s (seconds), m (minutes), h (hours), d (days), w +(weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_dnsbl_sites + +

    Optional list of DNS white/blacklist domains, filters and weight +factors. When the list is non-empty, the dnsblog(8) daemon will +query these domains with the IP addresses of remote SMTP clients, +and postscreen(8) will update an SMTP client's DNSBL score with +each non-error reply.

    + +

    Caution: when postscreen rejects mail, it replies with the DNSBL +domain name. Use the postscreen_dnsbl_reply_map feature to hide +"password" information in DNSBL domain names.

    + +

    When a client's score is equal to or greater than the threshold +specified with postscreen_dnsbl_threshold, postscreen(8) can drop +the connection with the remote SMTP client.

    + +

    Specify a list of domain=filter*weight entries, separated by +comma or whitespace.

    + +
      + +

    • When no "=filter" is specified, postscreen(8) will use any +non-error DNSBL reply. Otherwise, postscreen(8) uses only DNSBL +replies that match the filter. The filter has the form d.d.d.d, +where each d is a number, or a pattern inside [] that contains one +or more ";"-separated numbers or number..number ranges.

      + +

    • When no "*weight" is specified, postscreen(8) increments +the remote SMTP client's DNSBL score by 1. Otherwise, the weight must be +an integral number, and postscreen(8) adds the specified weight to +the remote SMTP client's DNSBL score. Specify a negative number for +whitelisting.

      + +

    • When one postscreen_dnsbl_sites entry produces multiple +DNSBL responses, postscreen(8) applies the weight at most once. +

      + +
    + +

    Examples:

    + +

    To use example.com as a high-confidence blocklist, and to +block mail with example.net and example.org only when both agree: +

    + +
     
+postscreen_dnsbl_threshold = 2 
+postscreen_dnsbl_sites = example.com*2, example.net, example.org 
+
    + +

    To filter only DNSBL replies containing 127.0.0.4:

    + +
     
+postscreen_dnsbl_sites = example.com=127.0.0.4 
+
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_dnsbl_action ignore + +

    The action that postscreen(8) takes when a remote SMTP client's combined +DNSBL score is equal to or greater than a threshold (as defined +with the postscreen_dnsbl_sites and postscreen_dnsbl_threshold +parameters). Specify one of the following:

    + +
    + +
    ignore (default)
    + +
    Ignore the failure of this test. Allow other tests to complete. +Repeat this test the next time the client connects. +This option is useful for testing and collecting statistics +without blocking mail.
    + +
    enforce
    + +
    Allow other tests to complete. Reject attempts to deliver mail +with a 550 SMTP reply, and log the helo/sender/recipient information. +Repeat this test the next time the client connects.
    + +
    drop
    + +
    Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects.
    + +
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_greet_action ignore + +

    The action that postscreen(8) takes when a remote SMTP client speaks +before its turn within the time specified with the postscreen_greet_wait +parameter. Specify one of the following:

    + +
    + +
    ignore (default)
    + +
    Ignore the failure of this test. Allow other tests to complete. +Repeat this test the next time the client connects. +This option is useful for testing and collecting statistics +without blocking mail.
    + +
    enforce
    + +
    Allow other tests to complete. Reject attempts to deliver mail +with a 550 SMTP reply, and log the helo/sender/recipient information. +Repeat this test the next time the client connects.
    + +
    drop
    + +
    Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects.
    + +
    + +

    In either case, postscreen(8) will not whitelist the remote SMTP client +IP address.

    + +

    This feature is available in Postfix 2.8.

    + +#%PARAM postscreen_whitelist_networks $mynetworks +# +#

    Network addresses that are permanently whitelisted, and that +#will not be subjected to postscreen(8) checks. This parameter uses +#the same address syntax as the mynetworks parameter. This feature +#never uses the remote SMTP client hostname.

    +# +#

    This feature is available in Postfix 2.8.

    +# +#%PARAM postscreen_blacklist_networks +# +#

    Network addresses that are permanently blacklisted; see the +#postscreen_blacklist_action parameter for possible actions. This +#parameter uses the same address syntax as the mynetworks parameter. +#The blacklist has higher precedence than whitelists. This feature +#never uses the remote SMTP client hostname.

    +# +#

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_access_list permit_mynetworks + +

    Permanent white/blacklist for remote SMTP client IP addresses. +postscreen(8) searches this list immediately after a remote SMTP +client connects. Specify a comma- or whitespace-separated list of +commands (in upper or lower case) or lookup tables. The search stops +upon the first command that fires for the client IP address.

    + +
    + +
    permit_mynetworks
    Whitelist the client and +terminate the search if the client IP address matches $mynetworks. +Do not subject the client to any before/after 220 greeting tests. +Pass the connection immediately to a Postfix SMTP server process. +
    Pattern matching of domain names is controlled by the presence +or absence of "postscreen_access_list" in the +parent_domain_matches_subdomains parameter value.
    + +
    type:table
    Query the specified lookup +table. Each table lookup result is an access list, except that +access lists inside a table cannot specify type:table entries.
    +To discourage the use of hash, btree, etc. tables, there is no +support for substring matching like smtpd(8). Use CIDR tables +instead.
    + +
    permit
    Whitelist the client and terminate +the search. Do not subject the client to any before/after 220 +greeting tests. Pass the connection immediately to a Postfix SMTP +server process.
    + +
    reject
    Blacklist the client and terminate +the search. Subject the client to the action configured with the +postscreen_blacklist_action configuration parameter.
    + +
    dunno
    All postscreen(8) access lists +implicitly have this command at the end.
    When dunno +is executed inside a lookup table, return from the lookup table and +evaluate the next command.
    When dunno is executed +outside a lookup table, terminate the search, and subject the client +to the configured before/after 220 greeting tests.
    + +
    + +

    Example:

    + +
    +/etc/postfix/main.cf:
+    postscreen_access_list = permit_mynetworks, 
+        cidr:/etc/postfix/postscreen_access.cidr
+    postscreen_blacklist_action = enforce
+
    + +
    +/etc/postfix/postscreen_access.cidr:
+    # Rules are evaluated in the order as specified.
+    # Blacklist 192.168.* except 192.168.0.1.
+    192.168.0.1         dunno
+    192.168.0.0/16      reject
+
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_greet_banner $smtpd_banner + +

    The text in the optional "220-text..." server +response that +postscreen(8) sends ahead of the real Postfix SMTP server's "220 +text..." response, in an attempt to confuse bad SMTP clients so +that they speak before their turn (pre-greet). Specify an empty +value to disable this feature.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_blacklist_action ignore + +

    The action that postscreen(8) takes when a remote SMTP client is +permanently blacklisted with the postscreen_access_list parameter. +Specify one of the following:

    + +
    + +
    ignore (default)
    + +
    Ignore this result. Allow other tests to complete. Repeat +this test the next time the client connects. +This option is useful for testing and collecting statistics +without blocking mail.
    + +
    enforce
    + +
    Allow other tests to complete. Reject attempts to deliver mail +with a 550 SMTP reply, and log the helo/sender/recipient information. +Repeat this test the next time the client connects.
    + +
    drop
    + +
    Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects.
    + +
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM smtpd_command_filter + +

    A mechanism to transform commands from remote SMTP clients. +This is a last-resort tool to work around client commands that break +interoperability with the Postfix SMTP server. Other uses involve +fault injection to test Postfix's handling of invalid commands. +

    + +

    Specify the name of a "type:table" lookup table. The search +string is the SMTP command as received from the remote SMTP client, +except that initial whitespace and the trailing <CR><LF> +are removed. The result value is executed by the Postfix SMTP +server.

    + +

    There is no need to use smtpd_command_filter for the following +cases:

    + +
      + +

    • Use "resolve_numeric_domain = yes" to accept +"user@ipaddress".

      + +

    • Postfix already accepts the correct form +"user@[ipaddress]". Use virtual_alias_maps or canonical_maps +to translate these into domain names if necessary.

      + +

    • Use "strict_rfc821_envelopes = no" to accept "RCPT TO:<User +Name <user@example.com>>". Postfix will ignore the "User +Name" part and deliver to the <user@example.com> address. +

      + +
    + +

    Examples of problems that can be solved with the smtpd_command_filter +feature:

    + +
    +/etc/postfix/main.cf:
+    smtpd_command_filter = pcre:/etc/postfix/command_filter
+
    + +
    +/etc/postfix/command_filter:
+    # Work around clients that send malformed HELO commands.
+    /^HELO\s*$/ HELO domain.invalid
+
    + +
    +    # Work around clients that send empty lines.
+    /^\s*$/     NOOP
+
    + +
    +    # Work around clients that send RCPT TO:<'user@domain'>.
+    # WARNING: do not lose the parameters that follow the address.
+    /^(RCPT\s+TO:\s*<)'([^[:space:]]+)'(>.*)/     $1$2$3
+
    + +
    +    # Append XVERP to MAIL FROM commands to request VERP-style delivery.
+    # See VERP_README for more information on how to use Postfix VERP.
+    /^(MAIL FROM:\s*<listname@example\.com>.*)/   $1 XVERP
+
    + +
    +    # Bounce-never mail sink. Use notify_classes=bounce,resource,software 
+    # to send bounced mail to the postmaster (with message body removed).
+    /^(RCPT\s+TO:\s*<.*>.*)\s+NOTIFY=\S+(.*)/     $1 NOTIFY=NEVER$2
+    /^(RCPT\s+TO:.*)/                             $1 NOTIFY=NEVER
+
    + +

    This feature is available in Postfix 2.7.

    + +%PARAM smtp_reply_filter + +

    A mechanism to transform replies from remote SMTP servers one +line at a time. This is a last-resort tool to work around server +replies that break interoperability with the Postfix SMTP client. +Other uses involve fault injection to test Postfix's handling of +invalid responses.

    + +

    Notes:

    + +
      + +

    • In the case of a multi-line reply, the Postfix SMTP client +uses the final reply line's numerical SMTP reply code and enhanced +status code.

      + +

    • The numerical SMTP reply code (XYZ) takes precedence over +the enhanced status code (X.Y.Z). When the enhanced status code +initial digit differs from the SMTP reply code initial digit, or +when no enhanced status code is present, the Postfix SMTP client +uses a generic enhanced status code (X.0.0) instead.

      + +
    + +

    Specify the name of a "type:table" lookup table. The search +string is a single SMTP reply line as received from the remote SMTP +server, except that the trailing <CR><LF> are removed. +When the lookup succeeds, the result replaces the single SMTP reply +line.

    + +

    Examples:

    + +
    +/etc/postfix/main.cf:
+    smtp_reply_filter = pcre:/etc/postfix/reply_filter
+
    + +
    +/etc/postfix/reply_filter:
+    # Transform garbage into "250-filler..." so that it looks like
+    # one line from a multi-line reply. It does not matter what we
+    # substitute here as long it has the right syntax.  The Postfix
+    # SMTP client will use the final line's numerical SMTP reply
+    # code and enhanced status code.
+    !/^([2-5][0-9][0-9]($|[- ]))/ 250-filler for garbage
+
    + +

    This feature is available in Postfix 2.7.

    + +%PARAM lmtp_reply_filter + +

    The LMTP-specific version of the smtp_reply_filter +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.7 and later.

    + +%PARAM smtp_tls_block_early_mail_reply no + +

    Try to detect a mail hijacking attack based on a TLS protocol +vulnerability (CVE-2009-3555), where an attacker prepends malicious +HELO, MAIL, RCPT, DATA commands to a Postfix SMTP client TLS session. +The attack would succeed with non-Postfix SMTP servers that reply +to the malicious HELO, MAIL, RCPT, DATA commands after negotiating +the Postfix SMTP client TLS session.

    + +

    This feature is available in Postfix 2.7.

    + +%PARAM lmtp_tls_block_early_mail_reply + +

    The LMTP-specific version of the smtp_tls_block_early_mail_reply +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.7 and later.

    + +%PARAM empty_address_default_transport_maps_lookup_key <> + +

    The sender_dependent_default_transport_maps search string that +will be used instead of the null sender address.

    + +

    This feature is available in Postfix 2.7 and later.

    + +%PARAM sender_dependent_default_transport_maps + +

    A sender-dependent override for the global default_transport +parameter setting. The tables are searched by the envelope sender +address and @domain. A lookup result of DUNNO terminates the search +without overriding the global default_transport parameter setting. +This information is overruled with the transport(5) table.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    Note: this overrides default_transport, not transport_maps, and +therefore the expected syntax is that of default_transport, not the +syntax of transport_maps. Specifically, this does not support the +transport_maps syntax for null transport, null nexthop, or null +email addresses.

    + +

    For safety reasons, this feature does not allow $number +substitutions in regular expression maps.

    + +

    This feature is available in Postfix 2.7 and later.

    + +%PARAM address_verify_sender_dependent_default_transport_maps $sender_dependent_default_transport_maps + +

    Overrides the sender_dependent_default_transport_maps parameter +setting for address verification probes.

    + +

    This feature is available in Postfix 2.7 and later.

    + +%PARAM default_filter_nexthop + +

    When a content_filter or FILTER request specifies no explicit +next-hop destination, use $default_filter_nexthop instead; when +that value is empty, use the domain in the recipient address. +Specify "default_filter_nexthop = $myhostname" for compatibility +with Postfix version 2.6 and earlier, or specify an explicit next-hop +destination with each content_filter value or FILTER action.

    + +

    This feature is available in Postfix 2.7 and later.

    + +%PARAM smtp_address_preference any + +

    The address type ("ipv6", "ipv4" or "any") that the Postfix +SMTP client will try first, when a destination has IPv6 and IPv4 +addresses with equal MX preference. This feature has no effect +unless the inet_protocols setting enables both IPv4 and IPv6.

    + +

    Postfix SMTP client address preference has evolved. With Postfix +2.8 the default is "ipv6"; earlier implementations are hard-coded +to prefer IPv6 over IPv4.

    + +

    Notes for mail delivery between sites that have both IPv4 and +IPv6 connectivity:

    + +
      + +

    • The setting "smtp_address_preference = ipv6" is unsafe. +It can fail to deliver mail when there is an outage that affects +IPv6, while the destination is still reachable over IPv4.

      + +

    • The setting "smtp_address_preference = any" is safe. With +this, mail will eventually be delivered even if there is an outage +that affects IPv6 or IPv4, as long as it does not affect both.

      + +
    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM lmtp_address_preference ipv6 + +

    The LMTP-specific version of the smtp_address_preference +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM smtp_dns_resolver_options + +

    DNS Resolver options for the Postfix SMTP client. Specify zero +or more of the following options, separated by comma or whitespace. +Option names are case-sensitive. Some options refer to domain names +that are specified in the file /etc/resolv.conf or equivalent.

    + +
    + +
    res_defnames
    + +
    Append the current domain name to single-component names (those +that do not contain a "." character). This can produce incorrect +results, and is the hard-coded behavior prior to Postfix 2.8.
    + +
    res_dnsrch
    + +
    Search for host names in the current domain and in parent +domains. This can produce incorrect results and is therefore not +recommended.
    + +
    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM lmtp_dns_resolver_options + +

    The LMTP-specific version of the smtp_dns_resolver_options +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM postscreen_dnsbl_threshold 1 + +

    The inclusive lower bound for blocking a remote SMTP client, based on +its combined DNSBL score as defined with the postscreen_dnsbl_sites +parameter.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_dnsbl_whitelist_threshold 0 + +

    Allow a remote SMTP client to skip "before" and "after 220 +greeting" protocol tests, based on its combined DNSBL score as +defined with the postscreen_dnsbl_sites parameter.

    + +

    Specify a negative value to enable this feature. When a client +passes the postscreen_dnsbl_whitelist_threshold without having +failed other tests, all pending or disabled tests are flagged as +completed with a time-to-live value equal to postscreen_dnsbl_ttl. +When a test was already completed, its time-to-live value is updated +if it was less than postscreen_dnsbl_ttl.

    + +

    This feature is available in Postfix 2.11.

    + +%PARAM postscreen_command_count_limit 20 + +

    The limit on the total number of commands per SMTP session for +postscreen(8)'s built-in SMTP protocol engine. This SMTP engine +defers or rejects all attempts to deliver mail, therefore there is +no need to enforce separate limits on the number of junk commands +and error commands.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_command_time_limit normal: 300s, overload: 10s + +

    The time limit to read an entire command line with postscreen(8)'s +built-in SMTP protocol engine.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_dnsbl_ttl 1h + +

    The amount of time that postscreen(8) will use the result from +a successful DNS-based reputation test before a client +IP address is required to pass that test again.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 2.8-3.0. It was +replaced by postscreen_dnsbl_max_ttl in Postfix 3.1.

    + +%PARAM postscreen_dnsbl_min_ttl 60s + +

    The minimum amount of time that postscreen(8) will use the +result from a successful DNS-based reputation test before a +client IP address is required to pass that test again. If the DNS +reply specifies a larger TTL value, that value will be used unless +it would be larger than postscreen_dnsbl_max_ttl.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 3.1.

    + +%PARAM postscreen_dnsbl_max_ttl ${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h + +

    The maximum amount of time that postscreen(8) will use the +result from a successful DNS-based reputation test before a +client IP address is required to pass that test again. If the DNS +reply specifies a shorter TTL value, that value will be used unless +it would be smaller than postscreen_dnsbl_min_ttl.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 3.1. The default setting +is backwards-compatible with older Postfix versions.

    + +%PARAM postscreen_pipelining_action enforce + +

    The action that postscreen(8) takes when a remote SMTP client +sends +multiple commands instead of sending one command and waiting for +the server to respond. Specify one of the following:

    + +
    + +
    ignore
    + +
    Ignore the failure of this test. Allow other tests to complete. +Do not repeat this test before some the result from some +other test expires. +This option is useful for testing and collecting statistics +without blocking mail permanently.
    + +
    enforce
    + +
    Allow other tests to complete. Reject attempts to deliver mail +with a 550 SMTP reply, and log the helo/sender/recipient information. +Repeat this test the next time the client connects.
    + +
    drop
    + +
    Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects.
    + +
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_pipelining_ttl 30d + +

    The amount of time that postscreen(8) will use the result from +a successful "pipelining" SMTP protocol test. During this time, the +client IP address is excluded from this test. The default is +long because a good client must disconnect after it passes the test, +before it can talk to a real Postfix SMTP server.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_pipelining_enable no + +

    Enable "pipelining" SMTP protocol tests in the postscreen(8) +server. These tests are expensive: a good client must disconnect +after it passes the test, before it can talk to a real Postfix SMTP +server.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_watchdog_timeout 10s + +

    How much time a postscreen(8) process may take to respond to +a remote SMTP client command or to perform a cache operation before it +is terminated by a built-in watchdog timer. This is a safety +mechanism that prevents postscreen(8) from becoming non-responsive +due to a bug in Postfix itself or in system software. To avoid +false alarms and unnecessary cache corruption this limit cannot be +set under 10s.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_helo_required $smtpd_helo_required + +

    Require that a remote SMTP client sends HELO or EHLO before +commencing a MAIL transaction.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_forbidden_commands $smtpd_forbidden_commands + +

    List of commands that the postscreen(8) server considers in +violation of the SMTP protocol. See smtpd_forbidden_commands for +syntax, and postscreen_non_smtp_command_action for possible actions. +

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_disable_vrfy_command $disable_vrfy_command + +

    Disable the SMTP VRFY command in the postscreen(8) daemon. See +disable_vrfy_command for details.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_non_smtp_command_action drop + +

    The action that postscreen(8) takes when a remote SMTP client sends +non-SMTP commands as specified with the postscreen_forbidden_commands +parameter. Specify one of the following:

    + +
    + +
    ignore
    + +
    Ignore the failure of this test. Allow other tests to complete. +Do not repeat this test before some the result from some +other test expires. +This option is useful for testing and collecting statistics +without blocking mail permanently.
    + +
    enforce
    + +
    Allow other tests to complete. Reject attempts to deliver mail +with a 550 SMTP reply, and log the helo/sender/recipient information. +Repeat this test the next time the client connects.
    + +
    drop
    + +
    Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects. This action is the +same as with the Postfix SMTP server's smtpd_forbidden_commands +feature.
    + +
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_non_smtp_command_ttl 30d + +

    The amount of time that postscreen(8) will use the result from +a successful "non_smtp_command" SMTP protocol test. During this +time, the client IP address is excluded from this test. The default +is long because a client must disconnect after it passes the test, +before it can talk to a real Postfix SMTP server.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_non_smtp_command_enable no + +

    Enable "non-SMTP command" tests in the postscreen(8) server. These +tests are expensive: a client must disconnect after it passes the +test, before it can talk to a real Postfix SMTP server.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_dnsbl_reply_map + +

    A mapping from actual DNSBL domain name which includes a secret +password, to the DNSBL domain name that postscreen will reply with +when it rejects mail. When no mapping is found, the actual DNSBL +domain will be used.

    + +

    For maximal stability it is best to use a file that is read +into memory such as pcre:, regexp: or texthash: (texthash: is similar +to hash:, except a) there is no need to run postmap(1) before the +file can be used, and b) texthash: does not detect changes after +the file is read).

    + +

    Example:

    + +
    +/etc/postfix/main.cf:
+    postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
+
    + +
    +/etc/postfix/dnsbl_reply:
+   secret.zen.spamhaus.org	zen.spamhaus.org
+
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_dnsbl_timeout 10s + +

    The time limit for DNSBL or DNSWL lookups. This is separate from +the timeouts in the dnsblog(8) daemon which are defined by system +resolver(3) routines.

    + +

    This feature is available in Postfix 3.0.

    +%PARAM postscreen_bare_newline_action ignore + +

    The action that postscreen(8) takes when a remote SMTP client sends +a bare newline character, that is, a newline not preceded by carriage +return. Specify one of the following:

    + +
    + +
    ignore
    + +
    Ignore the failure of this test. Allow other tests to complete. +Do not repeat this test before some the result from some +other test expires. +This option is useful for testing and collecting statistics +without blocking mail permanently.
    + +
    enforce
    + +
    Allow other tests to complete. Reject attempts to deliver mail +with a 550 SMTP reply, and log the helo/sender/recipient information. +Repeat this test the next time the client connects.
    + +
    drop
    + +
    Drop the connection immediately with a 521 SMTP reply. Repeat +this test the next time the client connects.
    + +
    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_bare_newline_ttl 30d + +

    The amount of time that postscreen(8) will use the result from +a successful "bare newline" SMTP protocol test. During this +time, the client IP address is excluded from this test. The default +is long because a remote SMTP client must disconnect after it passes +the test, +before it can talk to a real Postfix SMTP server.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_bare_newline_enable no + +

    Enable "bare newline" SMTP protocol tests in the postscreen(8) +server. These tests are expensive: a remote SMTP client must +disconnect after +it passes the test, before it can talk to a real Postfix SMTP server. +

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM postscreen_client_connection_count_limit $smtpd_client_connection_count_limit + +

    How many simultaneous connections any remote SMTP client is +allowed to have +with the postscreen(8) daemon. By default, this limit is the same +as with the Postfix SMTP server. Note that the triage process can +take several seconds, with the time spent in postscreen_greet_wait +delay, and with the time spent talking to the postscreen(8) built-in +dummy SMTP protocol engine.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM dnsblog_reply_delay 0s + +

    A debugging aid to artificially delay DNS responses.

    + +

    This feature is available in Postfix 2.8.

    + +%PARAM reset_owner_alias no + +

    Reset the local(8) delivery agent's idea of the owner-alias +attribute, when delivering mail to a child alias that does not have +its own owner alias.

    + +

    This feature is available in Postfix 2.8 and later. With older +Postfix releases, the behavior is as if this parameter is set to +"yes".

    + +

    As documented in aliases(5), when an alias name has a +companion alias named owner-name, this will replace the +envelope sender address, so that delivery errors will be +reported to the owner alias instead of the sender. This configuration +is recommended for mailing lists.

    + +

    A less known property of the owner alias is that it also forces +the local(8) delivery agent to write local and remote addresses +from alias expansion to a new queue file, instead of attempting to +deliver mail to local addresses as soon as they come out of alias +expansion.

    + +

    Writing local addresses from alias expansion to a new queue +file allows for robust handling of temporary delivery errors: errors +with one local member have no effect on deliveries to other members +of the list. On the other hand, delivery to local addresses as +soon as they come out of alias expansion is fragile: a temporary +error with one local address from alias expansion will cause the +entire alias to be expanded repeatedly until the error goes away, +or until the message expires in the queue. In that case, a problem +with one list member results in multiple message deliveries to other +list members.

    + +

    The default behavior of Postfix 2.8 and later is to keep the +owner-alias attribute of the parent alias, when delivering mail to +a child alias that does not have its own owner alias. Then, local +addresses from that child alias will be written to a new queue file, +and a temporary error with one local address will not affect delivery +to other mailing list members.

    + +

    Unfortunately, older Postfix releases reset the owner-alias +attribute when delivering mail to a child alias that does not have +its own owner alias. To be precise, this resets only the decision +to create a new queue file, not the decision to override the envelope +sender address. The local(8) delivery agent then attempts to +deliver local addresses as soon as they come out of child alias +expansion. If delivery to any address from child alias expansion +fails with a temporary error condition, the entire mailing list may +be expanded repeatedly until the mail expires in the queue, resulting +in multiple deliveries of the same message to mailing list members. +

    + +%PARAM qmgr_ipc_timeout 60s + +

    The time limit for the queue manager to send or receive information +over an internal communication channel. The purpose is to break +out of deadlock situations. If the time limit is exceeded the +software either retries or aborts the operation.

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM qmgr_daemon_timeout 1000s + +

    How much time a Postfix queue manager process may take to handle +a request before it is terminated by a built-in watchdog timer. +

    + +

    +Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). +The default time unit is s (seconds). +

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tls_preempt_cipherlist no + +

    With SSLv3 and later, use the Postfix SMTP server's cipher +preference order instead of the remote client's cipher preference +order.

    + +

    By default, the OpenSSL server selects the client's most preferred +cipher that the server supports. With SSLv3 and later, the server may +choose its own most preferred cipher that is supported (offered) by +the client. Setting "tls_preempt_cipherlist = yes" enables server cipher +preferences.

    + +

    While server cipher selection may in some cases lead to a more secure +or performant cipher choice, there is some risk of interoperability +issues. In the past, some SSL clients have listed lower priority ciphers +that they did not implement correctly. If the server chooses a cipher +that the client prefers less, it may select a cipher whose client +implementation is flawed. Most notably Windows 2003 Microsoft +Exchange servers have flawed implementations of DES-CBC3-SHA, which +OpenSSL considers stronger than RC4-SHA. Enabling server cipher-suite +selection may create interoperability issues with Windows 2003 +Microsoft Exchange clients.

    + +

    This feature is available in Postfix 2.8 and later, in combination +with OpenSSL 0.9.7 and later.

    + +%PARAM tls_disable_workarounds see "postconf -d" output + +

    List or bit-mask of OpenSSL bug work-arounds to disable.

    + +

    The OpenSSL toolkit includes a set of work-arounds for buggy SSL/TLS +implementations. Applications, such as Postfix, that want to maximize +interoperability ask the OpenSSL library to enable the full set of +recommended work-arounds.

    + +

    From time to time, it is discovered that a work-around creates a +security issue, and should no longer be used. If upgrading OpenSSL +to a fixed version is not an option or an upgrade is not available +in a timely manner, or in closed environments where no buggy clients +or servers exist, it may be appropriate to disable some or all of the +OpenSSL interoperability work-arounds. This parameter specifies which +bug work-arounds to disable.

    + +

    If the value of the parameter is a hexadecimal long integer starting +with "0x", the bug work-arounds corresponding to the bits specified in +its value are removed from the SSL_OP_ALL work-around bit-mask +(see openssl/ssl.h and SSL_CTX_set_options(3)). You can specify more +bits than are present in SSL_OP_ALL, excess bits are ignored. Specifying +0xFFFFFFFF disables all bug-workarounds on a 32-bit system. This should +also be sufficient on 64-bit systems, until OpenSSL abandons support +for 32-bit systems and starts using the high 32 bits of a 64-bit +bug-workaround mask.

    + +

    Otherwise, the parameter is a white-space or comma separated list +of specific named bug work-arounds chosen from the list below. It +is possible that your OpenSSL version includes new bug work-arounds +added after your Postfix source code was last updated, in that case +you can only disable one of these via the hexadecimal syntax above.

    + +
    + +
    CRYPTOPRO_TLSEXT_BUG
    New with GOST support in +OpenSSL 1.0.0.
    + +
    DONT_INSERT_EMPTY_FRAGMENTS
    See +SSL_CTX_set_options(3)
    + +
    LEGACY_SERVER_CONNECT
    See SSL_CTX_set_options(3)
    + +
    MICROSOFT_BIG_SSLV3_BUFFER
    See +SSL_CTX_set_options(3)
    + +
    MICROSOFT_SESS_ID_BUG
    See SSL_CTX_set_options(3)
    + +
    MSIE_SSLV2_RSA_PADDING
    also aliased as +CVE-2005-2969. Postfix 2.8 disables this work-around by +default with OpenSSL versions that may predate the fix. Fixed in +OpenSSL 0.9.7h and OpenSSL 0.9.8a.
    + +
    NETSCAPE_CHALLENGE_BUG
    See SSL_CTX_set_options(3)
    + +
    NETSCAPE_REUSE_CIPHER_CHANGE_BUG
    also aliased +as CVE-2010-4180. Postfix 2.8 disables this work-around by +default with OpenSSL versions that may predate the fix. Fixed in +OpenSSL 0.9.8q and OpenSSL 1.0.0c.
    + +
    SSLEAY_080_CLIENT_DH_BUG
    See +SSL_CTX_set_options(3)
    + +
    SSLREF2_REUSE_CERT_TYPE_BUG
    See +SSL_CTX_set_options(3)
    + +
    TLS_BLOCK_PADDING_BUG
    See SSL_CTX_set_options(3)
    + +
    TLS_D5_BUG
    See SSL_CTX_set_options(3)
    + +
    TLS_ROLLBACK_BUG
    See SSL_CTX_set_options(3). +This is disabled in OpenSSL 0.9.7 and later. Nobody should still +be using 0.9.6!
    + +
    TLSEXT_PADDING
    Postfix ≥ 3.4. See SSL_CTX_set_options(3).
    + +
    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tls_legacy_public_key_fingerprints no + +

    A temporary migration aid for sites that use certificate +public-key fingerprints with Postfix 2.9.0..2.9.5, which use +an incorrect algorithm. This parameter has no effect on the certificate +fingerprint support that is available since Postfix 2.2.

    + +

    Specify "tls_legacy_public_key_fingerprints = yes" temporarily, +pending a migration from configuration files with incorrect Postfix +2.9.0..2.9.5 certificate public-key finger prints, to the correct +fingerprints used by Postfix 2.9.6 and later. To compute the correct +certificate public-key fingerprints, see TLS_README.

    + +

    This feature is available in Postfix 2.9.6 and later.

    + +%PARAM tlsproxy_watchdog_timeout 10s + +

    How much time a tlsproxy(8) process may take to process local +or remote I/O before it is terminated by a built-in watchdog timer. +This is a safety mechanism that prevents tlsproxy(8) from becoming +non-responsive due to a bug in Postfix itself or in system software. +To avoid false alarms and unnecessary cache corruption this limit +cannot be set under 10s.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 2.8 and later

    + +%PARAM postscreen_discard_ehlo_keywords $smtpd_discard_ehlo_keywords + +

    A case insensitive list of EHLO keywords (pipelining, starttls, +auth, etc.) that the postscreen(8) server will not send in the EHLO +response to a remote SMTP client. See smtpd_discard_ehlo_keywords +for details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM postscreen_discard_ehlo_keyword_address_maps $smtpd_discard_ehlo_keyword_address_maps + +

    Lookup tables, indexed by the remote SMTP client address, with +case insensitive lists of EHLO keywords (pipelining, starttls, auth, +etc.) that the postscreen(8) server will not send in the EHLO response +to a remote SMTP client. See smtpd_discard_ehlo_keywords for details. +The table is not searched by hostname for robustness reasons.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM postscreen_use_tls $smtpd_use_tls + +

    Opportunistic TLS: announce STARTTLS support to remote SMTP clients, +but do not require that clients use TLS encryption.

    + +

    This feature is available in Postfix 2.8 and later. +Preferably, use postscreen_tls_security_level instead.

    + +%PARAM postscreen_enforce_tls $smtpd_enforce_tls + +

    Mandatory TLS: announce STARTTLS support to remote SMTP clients, and +require that clients use TLS encryption. See smtpd_postscreen_enforce_tls +for details.

    + +

    This feature is available in Postfix 2.8 and later. +Preferably, use postscreen_tls_security_level instead.

    + +%PARAM postscreen_tls_security_level $smtpd_tls_security_level + +

    The SMTP TLS security level for the postscreen(8) server; when +a non-empty value is specified, this overrides the obsolete parameters +postscreen_use_tls and postscreen_enforce_tls. See smtpd_tls_security_level +for details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_enforce_tls $smtpd_enforce_tls + +

    Mandatory TLS: announce STARTTLS support to remote SMTP clients, and +require that clients use TLS encryption. See smtpd_enforce_tls for +further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_CAfile $smtpd_tls_CAfile + +

    A file containing (PEM format) CA certificates of root CAs +trusted to sign either remote SMTP client certificates or intermediate +CA certificates. See smtpd_tls_CAfile for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_CApath $smtpd_tls_CApath + +

    A directory containing (PEM format) CA certificates of root CAs +trusted to sign either remote SMTP client certificates or intermediate +CA certificates. See smtpd_tls_CApath for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_always_issue_session_ids $smtpd_tls_always_issue_session_ids + +

    Force the Postfix tlsproxy(8) server to issue a TLS session id, +even when TLS session caching is turned off. See +smtpd_tls_always_issue_session_ids for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_ask_ccert $smtpd_tls_ask_ccert + +

    Ask a remote SMTP client for a client certificate. See +smtpd_tls_ask_ccert for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_ccert_verifydepth $smtpd_tls_ccert_verifydepth + +

    The verification depth for remote SMTP client certificates. A +depth of 1 is sufficient if the issuing CA is listed in a local CA +file. See smtpd_tls_ccert_verifydepth for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_cert_file $smtpd_tls_cert_file + +

    File with the Postfix tlsproxy(8) server RSA certificate in PEM +format. This file may also contain the Postfix tlsproxy(8) server +private RSA key. See smtpd_tls_cert_file for further details. With +Postfix ≥ 3.4 the preferred way to configure tlsproxy server keys and +certificates is via the "tlsproxy_tls_chain_files" parameter.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_ciphers $smtpd_tls_ciphers + +

    The minimum TLS cipher grade that the Postfix tlsproxy(8) server +will use with opportunistic TLS encryption. See smtpd_tls_ciphers +for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_dcert_file $smtpd_tls_dcert_file + +

    File with the Postfix tlsproxy(8) server DSA certificate in PEM +format. This file may also contain the Postfix tlsproxy(8) server +private DSA key. DSA is obsolete and should not be used. See +smtpd_tls_dcert_file for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_dh1024_param_file $smtpd_tls_dh1024_param_file + +

    File with DH parameters that the Postfix tlsproxy(8) server +should use with non-export EDH ciphers. See smtpd_tls_dh1024_param_file +for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_dh512_param_file $smtpd_tls_dh512_param_file + +

    File with DH parameters that the Postfix tlsproxy(8) server +should use with export-grade EDH ciphers. See smtpd_tls_dh512_param_file +for further details. The default SMTP server cipher grade is +"medium" with Postfix releases after the middle of 2015, and as a +result export-grade cipher suites are by default not used.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_dkey_file $smtpd_tls_dkey_file + +

    File with the Postfix tlsproxy(8) server DSA private key in PEM +format. This file may be combined with the Postfix tlsproxy(8) server +DSA certificate file specified with $smtpd_tls_dcert_file. DSA is +obsolete and should not be used. See smtpd_tls_dkey_file for further +details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_eccert_file $smtpd_tls_eccert_file + +

    File with the Postfix tlsproxy(8) server ECDSA certificate in PEM +format. This file may also contain the Postfix tlsproxy(8) server +private ECDSA key. See smtpd_tls_eccert_file for further details. With +Postfix ≥ 3.4 the preferred way to configure tlsproxy server keys and +certificates is via the "tlsproxy_tls_chain_files" parameter.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_eckey_file $smtpd_tls_eckey_file + +

    File with the Postfix tlsproxy(8) server ECDSA private key in PEM +format. This file may be combined with the Postfix tlsproxy(8) server +ECDSA certificate file specified with $smtpd_tls_eccert_file. See +smtpd_tls_eckey_file for further details. With Postfix ≥ 3.4 the +preferred way to configure tlsproxy server keys and certificates is via +the "tlsproxy_tls_chain_files" parameter.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_eecdh_grade $smtpd_tls_eecdh_grade + +

    The Postfix tlsproxy(8) server security grade for ephemeral +elliptic-curve Diffie-Hellman (EECDH) key exchange. See +smtpd_tls_eecdh_grade for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_exclude_ciphers $smtpd_tls_exclude_ciphers + +

    List of ciphers or cipher types to exclude from the tlsproxy(8) +server cipher list at all TLS security levels. See +smtpd_tls_exclude_ciphers for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_fingerprint_digest $smtpd_tls_fingerprint_digest + +

    The message digest algorithm to construct remote SMTP +client-certificate +fingerprints. See smtpd_tls_fingerprint_digest for further details. +

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_key_file $smtpd_tls_key_file + +

    File with the Postfix tlsproxy(8) server RSA private key in PEM +format. This file may be combined with the Postfix tlsproxy(8) server +RSA certificate file specified with $smtpd_tls_cert_file. See +smtpd_tls_key_file for further details. With Postfix ≥ 3.4 the +preferred way to configure tlsproxy server keys and certificates is via +the "tlsproxy_tls_chain_files" parameter.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_loglevel $smtpd_tls_loglevel + +

    Enable additional Postfix tlsproxy(8) server logging of TLS +activity. Each logging level also includes the information that +is logged at a lower logging level. See smtpd_tls_loglevel for +further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_mandatory_ciphers $smtpd_tls_mandatory_ciphers + +

    The minimum TLS cipher grade that the Postfix tlsproxy(8) server +will use with mandatory TLS encryption. See smtpd_tls_mandatory_ciphers +for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_mandatory_exclude_ciphers $smtpd_tls_mandatory_exclude_ciphers + +

    Additional list of ciphers or cipher types to exclude from the +tlsproxy(8) server cipher list at mandatory TLS security levels. +See smtpd_tls_mandatory_exclude_ciphers for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_mandatory_protocols $smtpd_tls_mandatory_protocols + +

    The SSL/TLS protocols accepted by the Postfix tlsproxy(8) server +with mandatory TLS encryption. If the list is empty, the server +supports all available SSL/TLS protocol versions. See +smtpd_tls_mandatory_protocols for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_protocols $smtpd_tls_protocols + +

    List of TLS protocols that the Postfix tlsproxy(8) server will +exclude or include with opportunistic TLS encryption. See +smtpd_tls_protocols for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_req_ccert $smtpd_tls_req_ccert + +

    With mandatory TLS encryption, require a trusted remote SMTP +client certificate in order to allow TLS connections to proceed. +See smtpd_tls_req_ccert for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_security_level $smtpd_tls_security_level + +

    The SMTP TLS security level for the Postfix tlsproxy(8) server; +when a non-empty value is specified, this overrides the obsolete +parameters smtpd_use_tls and smtpd_enforce_tls. See +smtpd_tls_security_level for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_tls_session_cache_timeout $smtpd_tls_session_cache_timeout + +

    Obsolete expiration time of Postfix tlsproxy(8) server TLS session +cache information. Since the cache is shared with smtpd(8) and managed +by tlsmgr(8), there is only one expiration time for the SMTP server cache +shared by all three services, namely smtpd_tls_session_cache_timeout.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_use_tls $smtpd_use_tls + +

    Opportunistic TLS: announce STARTTLS support to remote SMTP clients, +but do not require that clients use TLS encryption. See smtpd_use_tls +for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM smtpd_reject_footer + +

    Optional information that is appended after each Postfix SMTP +server +4XX or 5XX response.

    + +

    The following example uses "\c" at the start of the template +(supported in Postfix 2.10 and later) to suppress the line break +between the reply text and the footer text. With earlier Postfix +versions, the footer text always begins on a new line, and the "\c" +is output literally.

    + +
    +/etc/postfix/main.cf:
+    smtpd_reject_footer = \c. For assistance, call 800-555-0101.
+     Please provide the following information in your problem report:
+     time ($localtime), client ($client_address) and server
+     ($server_name).
+
    + +

    Server response:

    + +
    +    550-5.5.1 <user@example> Recipient address rejected: User
+    unknown. For assistance, call 800-555-0101. Please provide the
+    following information in your problem report: time (Jan 4 15:42:00),
+    client (192.168.1.248) and server (mail1.example.com).
+
    + +

    Note: the above text is meant to make it easier to find the +Postfix logfile records for a failed SMTP session. The text itself +is not logged to the Postfix SMTP server's maillog file.

    + +

    Be sure to keep the text as short as possible. Long text may +be truncated before it is logged to the remote SMTP client's maillog +file, or before it is returned to the sender in a delivery status +notification.

    + +

    The template text is not subject to Postfix configuration +parameter $name expansion. Instead, this feature supports a limited +number of $name attributes in the footer text. These attributes are +replaced with their current value for the SMTP session.

    + +

    Note: specify $$name in footer text that is looked up from +regexp: or pcre:-based smtpd_reject_footer_maps, otherwise the +Postfix server will not use the footer text and will log a warning +instead.

    + +
    + +
    client_address
    The Client IP address that +is logged in the maillog file.
    + +
    client_port
    The client TCP port that is +logged in the maillog file.
    + +
    localtime
    The server local time (Mmm dd +hh:mm:ss) that is logged in the maillog file.
    + +
    server_name
    The server's myhostname value. +This attribute is made available for sites with multiple MTAs +(perhaps behind a load-balancer), where the server name can help +the server support team to quickly find the right log files.
    + +
    + +

    Notes:

    + +
      + +

    • NOT SUPPORTED are other attributes such as sender, recipient, +or main.cf parameters.

      + +

    • For safety reasons, text that does not match +$smtpd_expansion_filter is censored.

      + +
    + +

    This feature supports the two-character sequence \n as a request +for a line break in the footer text. Postfix automatically inserts +after each line break the three-digit SMTP reply code (and optional +enhanced status code) from the original Postfix reject message. +

    + +

    To work around mail software that mis-handles multi-line replies, +specify the two-character sequence \c at the start of the template. +This suppresses the line break between the reply text and the footer +text (Postfix 2.10 and later).

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM smtpd_reject_footer_maps + +

    Lookup tables, indexed by the complete Postfix SMTP server 4xx or +5xx response, with reject footer templates. See smtpd_reject_footer +for details.

    + +

    +Specify zero or more "type:name" lookup tables, separated by +whitespace or comma. Tables will be searched in the specified order +until a match is found. +

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM postscreen_expansion_filter see "postconf -d" output + +

    List of characters that are permitted in postscreen_reject_footer +attribute expansions. See smtpd_expansion_filter for further +details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM postscreen_reject_footer $smtpd_reject_footer + +

    Optional information that is appended after a 4XX or 5XX +postscreen(8) server +response. See smtpd_reject_footer for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM postscreen_reject_footer_maps $smtpd_reject_footer_maps + +

    Optional lookup table for information that is appended after a 4XX +or 5XX postscreen(8) server response. See smtpd_reject_footer_maps for +further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM postscreen_command_filter $smtpd_command_filter + +

    A mechanism to transform commands from remote SMTP clients. +See smtpd_command_filter for further details.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM dnsblog_service_name dnsblog + +

    The name of the dnsblog(8) service entry in master.cf. This +service performs DNS white/blacklist lookups.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM tlsproxy_service_name tlsproxy + +

    The name of the tlsproxy(8) service entry in master.cf. This +service performs plaintext <=> TLS ciphertext conversion.

    + +

    This feature is available in Postfix 2.8 and later.

    + +%PARAM smtpd_per_record_deadline normal: no, overload: yes + +

    Change the behavior of the smtpd_timeout and smtpd_starttls_timeout +time limits, from a +time limit per read or write system call, to a time limit to send +or receive a complete record (an SMTP command line, SMTP response +line, SMTP message content line, or TLS protocol message). This +limits the impact from hostile peers that trickle data one byte at +a time.

    + +

    Note: when per-record deadlines are enabled, a short timeout +may cause problems with TLS over very slow network connections. +The reasons are that a TLS protocol message can be up to 16 kbytes +long (with TLSv1), and that an entire TLS protocol message must be +sent or received within the per-record deadline.

    + +

    This feature is available in Postfix 2.9 and later. With older +Postfix releases, the behavior is as if this parameter is set to +"no".

    + +%PARAM smtp_per_record_deadline no + +

    Change the behavior of the smtp_*_timeout time limits, from a +time limit per read or write system call, to a time limit to send +or receive a complete record (an SMTP command line, SMTP response +line, SMTP message content line, or TLS protocol message). This +limits the impact from hostile peers that trickle data one byte at +a time.

    + +

    Note: when per-record deadlines are enabled, a short timeout +may cause problems with TLS over very slow network connections. +The reasons are that a TLS protocol message can be up to 16 kbytes +long (with TLSv1), and that an entire TLS protocol message must be +sent or received within the per-record deadline.

    + +

    This feature is available in Postfix 2.9 and later. With older +Postfix releases, the behavior is as if this parameter is set to +"no".

    + +%PARAM lmtp_per_record_deadline no + +

    The LMTP-specific version of the smtp_per_record_deadline +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM postscreen_whitelist_interfaces static:all + +

    A list of local postscreen(8) server IP addresses where a +non-whitelisted remote SMTP client can obtain postscreen(8)'s temporary +whitelist status. This status is required before the client can +talk to a Postfix SMTP server process. By default, a client can +obtain postscreen(8)'s whitelist status on any local postscreen(8) +server IP address.

    + +

    When postscreen(8) listens on both primary and backup MX +addresses, the postscreen_whitelist_interfaces parameter can be +configured to give the temporary whitelist status only when a client +connects to a primary MX address. Once a client is whitelisted it +can talk to a Postfix SMTP server on any address. Thus, clients +that connect only to backup MX addresses will never become whitelisted, +and will never be allowed to talk to a Postfix SMTP server process. +

    + +

    Specify a list of network addresses or network/netmask patterns, +separated by commas and/or whitespace. The netmask specifies the +number of bits in the network part of a host address. Continue long +lines by starting the next line with whitespace.

    + +

    You can also specify "/file/name" or "type:table" patterns. A +"/file/name" pattern is replaced by its contents; a "type:table" +lookup table is matched when a table entry matches a lookup string +(the lookup result is ignored).

    + +

    The list is matched left to right, and the search stops on the +first match. Specify "!pattern" to exclude an address or network +block from the list.

    + +

    Note: IP version 6 address information must be specified inside +[] in the postscreen_whitelist_interfaces value, and in files +specified with "/file/name". IP version 6 addresses contain the +":" character, and would otherwise be confused with a "type:table" +pattern.

    + +

    Example:

    + +
    +/etc/postfix/main.cf:
+    # Don't whitelist connections to the backup IP address.
+    postscreen_whitelist_interfaces = !168.100.189.8, static:all
+
    + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM postscreen_upstream_proxy_protocol + +

    The name of the proxy protocol used by an optional before-postscreen +proxy agent. When a proxy agent is used, this protocol conveys local +and remote address and port information. Specify +"postscreen_upstream_proxy_protocol = haproxy" to enable the haproxy +protocol.

    + +

    This feature is available in Postfix 2.10 and later.

    + +%PARAM postscreen_upstream_proxy_timeout 5s + +

    The time limit for the proxy protocol specified with the +postscreen_upstream_proxy_protocol parameter.

    + +

    This feature is available in Postfix 2.10 and later.

    + +%PARAM smtpd_upstream_proxy_protocol + +

    The name of the proxy protocol used by an optional before-smtpd +proxy agent. When a proxy agent is used, this protocol conveys local +and remote address and port information. Specify +"smtpd_upstream_proxy_protocol = haproxy" to enable the haproxy +protocol.

    + +

    NOTE: To use the nginx proxy with smtpd(8), enable the XCLIENT +protocol with smtpd_authorized_xclient_hosts. This supports SASL +authentication in the proxy agent (Postfix 2.9 and later).

    + +

    This feature is available in Postfix 2.10 and later.

    + +%PARAM smtpd_upstream_proxy_timeout 5s + +

    The time limit for the proxy protocol specified with the +smtpd_upstream_proxy_protocol parameter.

    + +

    This feature is available in Postfix 2.10 and later.

    + +%PARAM enable_long_queue_ids no + +

    Enable long, non-repeating, queue IDs (queue file names). The +benefit of non-repeating names is simpler logfile analysis and +easier queue migration (there is no need to run "postsuper" to +change queue file names that don't match their message file inode +number).

    + +

    Note: see below for how to convert long queue file names to +Postfix ≤ 2.8.

    + +

    Changing the parameter value to "yes" has the following effects: +

    + +
      + +

    • Existing queue file names are not affected.

      + +

    • New queue files are created with names such as 3Pt2mN2VXxznjll. +These are encoded in a 52-character alphabet that contains digits +(0-9), upper-case letters (B-Z) and lower-case letters (b-z). For +safety reasons the vowels (AEIOUaeiou) are excluded from the alphabet. +The name format is: 6 or more characters for the time in seconds, +4 characters for the time in microseconds, the 'z'; the remainder +is the file inode number encoded in the first 51 characters of the +52-character alphabet.

      + +

    • New messages have a Message-ID header with +queueID@myhostname.

      + +

    • The mailq (postqueue -p) output has a wider Queue ID column. +The number of whitespace-separated fields is not changed.

      + +

    • The hash_queue_depth algorithm uses the first characters +of the queue file creation time in microseconds, after conversion +into hexadecimal representation. This produces the same queue hashing +behavior as if the queue file name was created with "enable_long_queue_ids += no".

      + +
    + +

    Changing the parameter value to "no" has the following effects: +

    + +
      + +

    • Existing long queue file names are renamed to the short +form (while running "postfix reload" or "postsuper").

      + +

    • New queue files are created with names such as C3CD21F3E90 +from a hexadecimal alphabet that contains digits (0-9) and upper-case +letters (A-F). The name format is: 5 characters for the time in +microseconds; the remainder is the file inode number.

      + +

    • New messages have a Message-ID header with +YYYYMMDDHHMMSS.queueid@myhostname, where +YYYYMMDDHHMMSS are the year, month, day, hour, minute and +second. + +

    • The mailq (postqueue -p) output has the same format as +with Postfix ≤ 2.8.

      + +

    • The hash_queue_depth algorithm uses the first characters +of the queue file name, with the hexadecimal representation of the +file creation time in microseconds.

      + +
    + +

    Before migration to Postfix ≤ 2.8, the following commands +are required to convert long queue file names into short names:

    + +
    +# postfix stop
+# postconf enable_long_queue_ids=no
+# postsuper
+
    + +

    Repeat the postsuper command until it reports no more queue file +name changes.

    + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM sendmail_fix_line_endings always + +

    Controls how the Postfix sendmail command converts email message +line endings from <CR><LF> into UNIX format (<LF>). +

    + +
    + +
    always
    Always convert message lines ending +in <CR><LF>. This setting is the default with Postfix +2.9 and later.
    + +
    strict
    Convert message lines ending in +<CR><LF> only if the first input line ends in +<CR><LF>. This setting is backwards-compatible with +Postfix 2.8 and earlier.
    + +
    never
    Never convert message lines ending in +<CR><LF>. This setting exists for completeness only. +
    + +
    + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM smtp_send_dummy_mail_auth no + +

    Whether or not to append the "AUTH=<>" option to the MAIL +FROM command in SASL-authenticated SMTP sessions. The default is +not to send this, to avoid problems with broken remote SMTP servers. +Before Postfix 2.9 the behavior is as if "smtp_send_dummy_mail_auth += yes". + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM lmtp_send_dummy_mail_auth no + +

    The LMTP-specific version of the smtp_send_dummy_mail_auth +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM address_verify_sender_ttl 0s + +

    The time between changes in the time-dependent portion of address +verification probe sender addresses. The time-dependent portion is +appended to the localpart of the address specified with the +address_verify_sender parameter. This feature is ignored when the +probe sender addresses is the null sender, i.e. the address_verify_sender +value is empty or <>.

    + +

    Historically, the probe sender address was fixed. This has +caused such addresses to end up on spammer mailing lists, and has +resulted in wasted network and processing resources.

    + +

    To enable time-dependent probe sender addresses, specify a +non-zero time value (an integral value plus an optional one-letter +suffix that specifies the time unit). Specify a value of at least +several hours, to avoid problems with senders that use greylisting. +Avoid nice TTL values, to make the result less predictable. Time +units are: s (seconds), m (minutes), h (hours), d (days), w (weeks). +

    + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM smtp_address_verify_target rcpt + +

    In the context of email address verification, the SMTP protocol +stage that determines whether an email address is deliverable. +Specify one of "rcpt" or "data". The latter is needed with remote +SMTP servers that reject recipients after the DATA command. Use +transport_maps to apply this feature selectively:

    + +
    +
    +/etc/postfix/main.cf:
+    transport_maps = hash:/etc/postfix/transport
+
    +
    + +
    +
    +/etc/postfix/transport:
+    smtp-domain-that-verifies-after-data    smtp-data-target:
+    lmtp-domain-that-verifies-after-data    lmtp-data-target:
+
    +
    + +
    +
    +/etc/postfix/master.cf:
+    smtp-data-target    unix    -    -    n    -    -    smtp
+        -o smtp_address_verify_target=data
+    lmtp-data-target    unix    -    -    n    -    -    lmtp
+        -o lmtp_address_verify_target=data
+
    +
    + +

    Unselective use of the "data" target does no harm, but will +result in unnecessary "lost connection after DATA" events at remote +SMTP/LMTP servers.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM lmtp_address_verify_target rcpt + +

    The LMTP-specific version of the smtp_address_verify_target +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM daemon_table_open_error_is_fatal no + +

    How a Postfix daemon process handles errors while opening lookup +tables: gradual degradation or immediate termination.

    + +
    + +
    no (default)

    Gradual degradation: a +daemon process logs a message of type "error" and continues execution +with reduced functionality. Features that do not depend on the +unavailable table will work normally, while features that depend +on the table will result in a type "warning" message.
    When +the notify_classes parameter value contains the "data" class, the +Postfix SMTP server and client will report transcripts of sessions +with an error because a table is unavailable.

    + +
    yes (historical behavior)

    Immediate +termination: a daemon process logs a type "fatal" message and +terminates immediately. This option reduces the number of possible +code paths through Postfix, and may therefore be slightly more +secure than the default.

    + +
    + +

    For the sake of sanity, the number of type "error" messages is +limited to 13 over the lifetime of a daemon process.

    + +

    This feature is available in Postfix 2.9 and later.

    + +%PARAM smtpd_log_access_permit_actions + +

    Enable logging of the named "permit" actions in SMTP server +access lists (by default, the SMTP server logs "reject" actions but +not "permit" actions). This feature does not affect conditional +actions such as "defer_if_permit".

    + +

    Specify a list of "permit" action names, "/file/name" or +"type:table" patterns, separated by commas and/or whitespace. The +list is matched left to right, and the search stops on the first +match. A "/file/name" pattern is replaced by its contents; a +"type:table" lookup table is matched when a name matches a lookup +key (the lookup result is ignored). Continue long lines by starting +the next line with whitespace. Specify "!pattern" to exclude a name +from the list.

    + +

    Examples:

    + +
    +/etc/postfix/main.cf:
+    # Log all "permit" actions.
+    smtpd_log_access_permit_actions = static:all
+
    + +
    +/etc/postfix/main.cf:
+    # Log "permit_dnswl_client" only.
+    smtpd_log_access_permit_actions = permit_dnswl_client
+
    + +

    This feature is available in Postfix 2.10 and later.

    + +%PARAM smtp_dns_support_level + +

    Level of DNS support in the Postfix SMTP client. With +"smtp_dns_support_level" left at its empty default value, the legacy +"disable_dns_lookups" parameter controls whether DNS is enabled in +the Postfix SMTP client, otherwise the legacy parameter is ignored. +

    + +

    Specify one of the following:

    + +
    + +
    disabled
    + +
    Disable DNS lookups. No MX lookups are performed and hostname +to address lookups are unconditionally "native". This setting is +not appropriate for hosts that deliver mail to the public Internet. +Some obsolete how-to documents recommend disabling DNS lookups in +some configurations with content_filters. This is no longer required +and strongly discouraged.
    + +
    enabled
    + +
    Enable DNS lookups. Nexthop destination domains not enclosed +in "[]" will be subject to MX lookups. If "dns" and "native" are +included in the "smtp_host_lookup" parameter value, DNS will be +queried first to resolve MX-host A records, followed by "native" +lookups if no answer is found in DNS.
    + +
    dnssec
    + +
    Enable DNSSEC +lookups. The "dnssec" setting differs from the "enabled" setting +above in the following ways:
    • Any MX lookups will set +RES_USE_DNSSEC and RES_USE_EDNS0 to request DNSSEC-validated +responses. If the MX response is DNSSEC-validated the corresponding +hostnames are considered validated.
    • The address lookups of +validated hostnames are also validated, (provided of course +"smtp_host_lookup" includes "dns", see below).
    • Temporary +failures in DNSSEC-enabled hostname-to-address resolution block any +"native" lookups. Additional "native" lookups only happen when +DNSSEC lookups hard-fail (NODATA or NXDOMAIN).
    + +
    + +

    The Postfix SMTP client considers non-MX "[nexthop]" and +"[nexthop]:port" destinations equivalent to statically-validated +MX records of the form "nexthop. IN MX 0 nexthop." Therefore, +with "dnssec" support turned on, validated hostname-to-address +lookups apply to the nexthop domain of any "[nexthop]" or +"[nexthop]:port" destination. This is also true for LMTP "inet:host" +and "inet:host:port" destinations, as LMTP hostnames are never +subject to MX lookups.

    + +

    The "dnssec" setting is recommended only if you plan to use the +dane or dane-only TLS security +level, otherwise enabling DNSSEC support in Postfix offers no +additional security. Postfix DNSSEC support relies on an upstream +recursive nameserver that validates DNSSEC signatures. Such a DNS +server will always filter out forged DNS responses, even when Postfix +itself is not configured to use DNSSEC.

    + +

    When using Postfix DANE support the "smtp_host_lookup" parameter +should include "dns", as DANE is not applicable +to hosts resolved via "native" lookups.

    + +

    As mentioned above, Postfix is not a validating stub +resolver; it relies on the system's configured DNSSEC-validating +recursive +nameserver to perform all DNSSEC validation. Since this +nameserver's DNSSEC-validated responses will be fully trusted, it +is strongly recommended that the MTA host have a local DNSSEC-validating +recursive caching nameserver listening on a loopback address, and +be configured to use only this nameserver for all lookups. Otherwise, +Postfix may remain subject to man-in-the-middle attacks that forge +responses from the recursive nameserver

    + +

    DNSSEC support requires a version of Postfix compiled against a +reasonably-modern DNS resolver(3) library that implements the +RES_USE_DNSSEC and RES_USE_EDNS0 resolver options.

    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM lmtp_dns_support_level + +

    The LMTP-specific version of the smtp_dns_support_level +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM smtp_tls_trust_anchor_file + +

    Zero or more PEM-format files with trust-anchor certificates +and/or public keys. If the parameter is not empty the root CAs in +CAfile and CApath are no longer trusted. Rather, the Postfix SMTP +client will only trust certificate-chains signed by one of the +trust-anchors contained in the chosen files. The specified +trust-anchor certificates and public keys are not subject to +expiration, and need not be (self-signed) root CAs. They may, if +desired, be intermediate certificates. Therefore, these certificates +also may be found "in the middle" of the trust chain presented by +the remote SMTP server, and any untrusted issuing parent certificates +will be ignored. Specify a list of pathnames separated by comma +or whitespace.

    + +

    Whether specified in main.cf, or on a per-destination basis, +the trust-anchor PEM file must be accessible to the Postfix SMTP +client in the chroot jail if applicable. The trust-anchor file +should contain only certificates and public keys, no private key +material, and must be readable by the non-privileged $mail_owner +user. This allows destinations to be bound to a set of specific +CAs or public keys without trusting the same CAs for all destinations. +

    + +

    The main.cf parameter supports single-purpose Postfix installations +that send mail to a fixed set of SMTP peers. At most sites, if +trust-anchor files are used at all, they will be specified on a +per-destination basis via the "tafile" attribute of the "verify" +and "secure" levels in smtp_tls_policy_maps.

    + +

    The underlying mechanism is in support of RFC 7672 (DANE TLSA), +which defines mechanisms for an SMTP client MTA to securely determine +server TLS certificates via DNS.

    + +

    If you want your trust anchors to be public keys, with OpenSSL +you can extract a single PEM public key from a PEM X.509 file +containing a single certificate, as follows:

    + +
    +
    +$ openssl x509 -in cert.pem -out ta-key.pem -noout -pubkey
+
    +
    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM lmtp_tls_trust_anchor_file + +

    The LMTP-specific version of the smtp_tls_trust_anchor_file +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM tls_dane_trust_anchor_digest_enable yes + +

    Enable support for RFC 6698 (DANE TLSA) DNS records that contain +digests of trust-anchors with certificate usage "2". Do not change +this setting from its default value.

    + +

    This feature is available in Postfix 2.11 through 3.1. It has +been withdrawn in Postfix 3.2, as trust-anchor TLSA records are now +widely used and have proved sufficiently reliable. Postfix 3.2 and +later ignore this configuration parameter and behaves as though it +were set to "yes".

    + +%PARAM tls_wildcard_matches_multiple_labels yes + +

    Match multiple DNS labels with "*" in wildcard certificates. +

    + +

    Some mail service providers prepend the customer domain name +to a base domain for which they have a wildcard TLS certificate. +For example, the MX records for example.com hosted by example.net +may be:

    + +
    +
    +example.com. IN MX 0 example.com.mx1.example.net.
+example.com. IN MX 0 example.com.mx2.example.net.
+
    +
    + +

    and the TLS certificate may be for "*.example.net". The "*" +then corresponds with multiple labels in the mail server domain +name. While multi-label wildcards are not widely supported, and +are not blessed by any standard, there is little to be gained by +disallowing their use in this context.

    + +

    Notes:

    + +

      + +

    • In a certificate name, the "*" is special only when it is +used as the first label.

      + +

    • While Postfix (2.11 or later) can match "*" with multiple +domain name labels, other implementations likely will not.

      + +

    • Earlier Postfix implementations behave as if +"tls_wildcard_matches_multiple_labels = no".

      + +
    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM tls_ssl_options + +

    List or bit-mask of OpenSSL options to enable.

    + +

    The OpenSSL toolkit provides a set of options that applications +can enable to tune the OpenSSL behavior. Some of these work around +bugs in other implementations and are on by default. You can use +the tls_disable_workarounds parameter to selectively disable some +or all of the bug work-arounds, making OpenSSL more strict at the +cost of non-interoperability with SSL clients or servers that exhibit +the bugs.

    + +

    Other options are off by default, and typically enable or disable +features rather than bug work-arounds. These may be turned on (with +care) via the tls_ssl_options parameter. The value is a white-space +or comma separated list of named options chosen from the list below. +The names are not case-sensitive, you can use lower-case if you +prefer. The upper case values below match the corresponding macro +name in the ssl.h header file with the SSL_OP_ prefix removed. It +is possible that your OpenSSL version includes new options added +after your Postfix source code was last updated, in that case you +can only enable one of these via the hexadecimal syntax below.

    + +

    You should only enable features via the hexadecimal mask when +the need to control the feature is critical (to deal with a new +vulnerability or a serious interoperability problem). Postfix DOES +NOT promise backwards compatible behavior with respect to the mask +bits. A feature enabled via the mask in one release may be enabled +by other means in a later release, and the mask bit will then be +ignored. Therefore, use of the hexadecimal mask is only a temporary +measure until a new Postfix or OpenSSL release provides a better +solution.

    + +

    If the value of the parameter is a hexadecimal long integer +starting with "0x", the options corresponding to the bits specified +in its value are enabled (see openssl/ssl.h and SSL_CTX_set_options(3)). +You can only enable options not already controlled by other Postfix +settings. For example, you cannot disable protocols or enable +server cipher preference. Do not attempt to turn all features by +specifying 0xFFFFFFFF, this is unlikely to be a good idea. Some +bug work-arounds are also valid here, allowing them to be re-enabled +if/when they're no longer enabled by default. The supported values +include:

    + +
    + +
    ENABLE_MIDDLEBOX_COMPAT
    Postfix ≥ 3.4. See +SSL_CTX_set_options(3).
    + +
    LEGACY_SERVER_CONNECT
    See SSL_CTX_set_options(3).
    + +
    NO_TICKET
    Enabled by default when needed in +fully-patched Postfix ≥ 2.7. Not needed at all for Postfix ≥ +2.11, unless for some reason you do not want to support TLS session +resumption. Best not set explicitly. See SSL_CTX_set_options(3).
    + +
    NO_COMPRESSION
    Disable SSL compression even if +supported by the OpenSSL library. Compression is CPU-intensive, +and compression before encryption does not always improve security.
    + +
    NO_RENEGOTIATION
    Postfix ≥ 3.4. This can +reduce opportunities for a potential CPU exhaustion attack. See +SSL_CTX_set_options(3).
    + +
    NO_SESSION_RESUMPTION_ON_RENEGOTIATION
    Postfix +≥ 3.4. See SSL_CTX_set_options(3).
    + +
    PRIORITIZE_CHACHA
    Postfix ≥ 3.4. See SSL_CTX_set_options(3).
    + +
    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM tlsmgr_service_name tlsmgr + +

    The name of the tlsmgr(8) service entry in master.cf. This +service maintains TLS session caches and other information in support +of TLS.

    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM lmtp_connection_reuse_count_limit 0 + +

    The LMTP-specific version of the smtp_connection_reuse_count_limit +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM smtp_connection_reuse_count_limit 0 + +

    When SMTP connection caching is enabled, the number of times +that an SMTP session may be reused before it is closed, or zero (no +limit). With a reuse count limit of N, a connection is used up to +N+1 times.

    + +

    NOTE: This feature is unsafe. When a high-volume destination +has multiple inbound MTAs, then the slowest inbound MTA will attract +the most connections to that destination. This limitation does not +exist with the smtp_connection_reuse_time_limit feature.

    + +

    This feature is available in Postfix 2.11.

    + +%PARAM lmtp_tls_force_insecure_host_tlsa_lookup no + +

    The LMTP-specific version of the smtp_tls_force_insecure_host_tlsa_lookup +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM smtp_tls_force_insecure_host_tlsa_lookup no + +

    Lookup the associated DANE TLSA RRset even when a hostname is +not an alias and its address records lie in an unsigned zone. This +is unlikely to ever yield DNSSEC validated results, since child +zones of unsigned zones are also unsigned in the absence of DLV or +locally configured non-root trust-anchors. We anticipate that such +mechanisms will not be used for just the "_tcp" subdomain of a host. +Suppressing the TLSA RRset lookup reduces latency and avoids potential +interoperability problems with nameservers for unsigned zones that +are not prepared to handle the new TLSA RRset.

    + +

    This feature is available in Postfix 2.11.

    + +%PARAM tls_dane_digest_agility on + +

    Configure RFC7671 DANE TLSA digest algorithm agility. +Do not change this setting from its default value.

    + +

    See Section 8 of RFC7671 for correct key rotation procedures.

    + +

    This feature is available in Postfix 2.11 through 3.1. Postfix +3.2 and later ignore this configuration parameter and behave as +though it were set to "on".

    + +%PARAM tls_dane_digests sha512 sha256 + +

    DANE TLSA (RFC 6698, RFC 7671, RFC 7672) resource-record "matching +type" digest algorithms in descending preference order. All the +specified algorithms must be supported by the underlying OpenSSL +library, otherwise the Postfix SMTP client will not support DANE +TLSA security.

    + +

    Specify a list of digest names separated by commas and/or +whitespace. Each digest name may be followed by an optional +"=<number>" suffix. For example, "sha512" may instead be specified +as "sha512=2" and "sha256" may instead be specified as "sha256=1". +The optional number must match the IANA assigned TLSA matching type number the algorithm in question. +Postfix will check this constraint for the algorithms it knows about. +Additional matching type algorithms registered with IANA can be added +with explicit numbers provided they are supported by OpenSSL.

    + +

    Invalid list elements are logged with a warning and disable DANE +support. TLSA RRs that specify digests not included in the list are +ignored with a warning.

    + +

    Note: It is unwise to omit sha256 from the digest list. This +digest algorithm is the only mandatory to implement digest algorithm +in RFC 6698, and many servers are expected publish TLSA records +with just sha256 digests. Unless one of the standard digests is +seriously compromised and servers have had ample time to update their +TLSA records you should not omit any standard digests, just arrange +them in order from strongest to weakest.

    + +

    This feature is available in Postfix 2.11 and later.

    + +%PARAM tls_session_ticket_cipher Postfix ≥ 3.0: aes-256-cbc, Postfix < 3.0: aes-128-cbc + +

    Algorithm used to encrypt RFC5077 TLS session tickets. This +algorithm must use CBC mode, have a 128-bit block size, and must +have a key length between 128 and 256 bits. The default is +aes-256-cbc. Overriding the default to choose a different algorithm +is discouraged.

    + +

    Setting this parameter empty disables session ticket support +in the Postfix SMTP server. Another way to disable session ticket +support is via the tls_ssl_options parameter.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM tls_fast_shutdown_enable yes + +

    A workaround for implementations that hang Postfix while shuting +down a TLS session, until Postfix times out. With this enabled, +Postfix will not wait for the remote TLS peer to respond to a TLS +'close' notification. This behavior is recommended for TLSv1.0 and +later.

    + +

    This feature was introduced with Postfix 3.4.6, 3.3.5, 3.2.10, +and 3.1.13.

    + +%PARAM default_delivery_status_filter + +

    Optional filter to replace the delivery status code or explanatory +text of successful or unsuccessful deliveries. This does not allow +the replacement of a successful status code (2.X.X) with an +unsuccessful status code (4.X.X or 5.X.X) or vice versa.

    + +

    Note: the (smtp|lmtp)_delivery_status_filter is applied only +once per recipient: when delivery is successful, when delivery is +rejected with 5XX, or when there are no more alternate MX or A +destinations. Use smtp_reply_filter or lmtp_reply_filter to inspect +responses for all delivery attempts.

    + +

    The following parameters can be used to implement a filter for +specific delivery agents: lmtp_delivery_status_filter, +local_delivery_status_filter, pipe_delivery_status_filter, +smtp_delivery_status_filter or virtual_delivery_status_filter. These +parameters support the same filter syntax as described here.

    + +

    Specify zero or more "type:table" lookup table names, separated +by comma or whitespace. For each successful or unsuccessful delivery +to a recipient, the tables are queried in the specified order with +one line of text that is structured as follows:

    + +
    +enhanced-status-code SPACE explanatory-text +
    + +

    The first table match wins. The lookup result must have the +same structure as the query, a successful status code (2.X.X) must +be replaced with a successful status code, an unsuccessful status +code (4.X.X or 5.X.X) must be replaced with an unsuccessful status +code, and the explanatory text field must be non-empty. Other results +will result in a warning.

    + +

    Example 1: convert specific soft TLS errors into hard errors, +by overriding the first number in the enhanced status code.

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_delivery_status_filter = pcre:/etc/postfix/smtp_dsn_filter
+
    +
    + +
    +
    +/etc/postfix/smtp_dsn_filter:
+    /^4(\.\d+\.\d+ TLS is required, but host \S+ refused to start TLS: .+)/
+        5$1
+    /^4(\.\d+\.\d+ TLS is required, but was not offered by host .+)/
+        5$1
+    # Do not change the following into hard bounces. They may
+    # result from a local configuration problem.
+    # 4.\d+.\d+ TLS is required, but our TLS engine is unavailable
+    # 4.\d+.\d+ TLS is required, but unavailable
+    # 4.\d+.\d+ Cannot start TLS: handshake failure
+
    +
    + +

    Example 2: censor the per-recipient delivery status text so +that it does not reveal the destination command or filename +when a remote sender requests confirmation of successful delivery. +

    + +
    +
    +/etc/postfix/main.cf:
+    local_delivery_status_filter = pcre:/etc/postfix/local_dsn_filter
+
    +
    + +
    +
    +/etc/postfix/local_dsn_filter:
+    /^(2\S+ delivered to file).+/    $1
+    /^(2\S+ delivered to command).+/ $1
+
    +
    + +

    Notes:

    + +
      + +

    • This feature will NOT override the soft_bounce safety net.

      + +

    • This feature will change the enhanced status code and text +that is logged to the maillog file, and that is reported to the +sender in delivery confirmation or non-delivery notifications. +

      + +
    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtp_delivery_status_filter $default_delivery_status_filter + +

    Optional filter for the smtp(8) delivery agent to change the +delivery status code or explanatory text of successful or unsuccessful +deliveries. See default_delivery_status_filter for details.

    + +

    NOTE: This feature modifies Postfix SMTP client error or non-error +messages that may or may not be derived from remote SMTP server +responses. In contrast, the smtp_reply_filter feature modifies +remote SMTP server responses only.

    + +%PARAM lmtp_delivery_status_filter + +

    The LMTP-specific version of the smtp_delivery_status_filter +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM pipe_delivery_status_filter $default_delivery_status_filter + +

    Optional filter for the pipe(8) delivery agent to change the +delivery status code or explanatory text of successful or unsuccessful +deliveries. See default_delivery_status_filter for details.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM virtual_delivery_status_filter $default_delivery_status_filter + +

    Optional filter for the virtual(8) delivery agent to change the +delivery status code or explanatory text of successful or unsuccessful +deliveries. See default_delivery_status_filter for details.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM local_delivery_status_filter $default_delivery_status_filter + +

    Optional filter for the local(8) delivery agent to change the +status code or explanatory text of successful or unsuccessful +deliveries. See default_delivery_status_filter for details.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM shlib_directory see 'postconf -d' output + +

    The location of Postfix dynamically-linked libraries +(libpostfix-*.so), and the default location of Postfix database +plugins (postfix-*.so) that have a relative pathname in the +dynamicmaps.cf file. The shlib_directory parameter defaults to +"no" when Postfix dynamically-linked libraries and database plugins +are disabled at compile time, otherwise it typically defaults to +/usr/lib/postfix or /usr/local/lib/postfix.

    + +

    Notes:

    + +
      + +

    • The directory specified with shlib_directory should contain +only Postfix-related files. Postfix dynamically-linked libraries +and database plugins should not be installed in a "public" system +directory such as /usr/lib or /usr/local/lib. Linking Postfix +dynamically-linked library files or database plugins into non-Postfix +programs is not supported. Postfix dynamically-linked libraries +and database plugins implement a Postfix-internal API that changes +without maintaining compatibility.

      + +

    • You can change the shlib_directory value after Postfix is +built. However, you may have to run ldconfig or equivalent to prevent +Postfix programs from failing because the libpostfix-*.so files are +not found. No ldconfig command is needed if you keep the libpostfix-*.so +files in the compiled-in default $shlib_directory location.

      + +
    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM meta_directory see 'postconf -d' output + +

    The location of non-executable files that are shared among +multiple Postfix instances, such as postfix-files, dynamicmaps.cf, +and the multi-instance template files main.cf.proto and master.cf.proto. +This directory should contain only Postfix-related files. Typically, +the meta_directory parameter has the same default as the config_directory +parameter (/etc/postfix or /usr/local/etc/postfix).

    + +

    For backwards compatibility with Postfix versions 2.6..2.11, +specify "meta_directory = $daemon_directory" in main.cf before +installing or upgrading Postfix, or specify "meta_directory = +/path/name" on the "make makefiles", "make install" or "make upgrade" +command line.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtpd_policy_service_default_action 451 4.3.5 Server configuration problem + +

    The default action when an SMTPD policy service request fails. +Specify "DUNNO" to behave as if the failed SMTPD policy service +request was not sent, and to continue processing other access +restrictions, if any.

    + +

    Limitations:

    + +
      + +

    • This parameter may specify any value that would be a valid +SMTPD policy server response (or access(5) map lookup result). An +access(5) map or policy server in this parameter value may need to +be declared in advance with a restriction_class setting.

      + +

    • If the specified action invokes another check_policy_service +request, that request will have the built-in default action.

      + +
    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtpd_policy_service_try_limit 2 + +

    The maximal number of attempts to send an SMTPD policy service +request before giving up. Specify a value greater than zero.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtpd_policy_service_retry_delay 1s + +

    The delay between attempts to resend a failed SMTPD policy +service request. Specify a value greater than zero.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtputf8_enable yes + +

    Enable preliminary SMTPUTF8 support for the protocols described +in RFC 6531..6533. This requires that Postfix is built to support +these protocols.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM strict_smtputf8 no + +

    Enable stricter enforcement of the SMTPUTF8 protocol. The Postfix +SMTP server accepts UTF8 sender or recipient addresses only when +the client requests an SMTPUTF8 mail transaction.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtputf8_autodetect_classes sendmail, verify + +

    Detect that a message requires SMTPUTF8 support for the specified +mail origin classes. This is a workaround to avoid chicken-and-egg +problems during the initial SMTPUTF8 roll-out in environments with +pre-existing mail flows that contain UTF8. Those mail flows should +not break because Postfix suddenly refuses to deliver such mail +to down-stream MTAs that don't announce SMTPUTF8 support.

    + +

    The problem is that Postfix cannot rely solely on the sender's +declaration that a message requires SMTPUTF8 support, because UTF8 +may be introduced during local processing (for example, the client +hostname in Postfix's Received: header, adding @$myorigin or +.$mydomain to an incomplete address, address rewriting, alias +expansion, automatic BCC recipients, local forwarding, and changes +made by header checks or Milter applications).

    + +

    For now, the default is to enable "SMTPUTF8 required" autodetection +only for Postfix sendmail command-line submissions and address +verification probes. This may change once SMTPUTF8 support achieves +world domination. However, sites that add UTF8 content via local +processing (see above) should autodetect the need for SMTPUTF8 +support for all email.

    + +

    Specify one or more of the following:

    + +
    + +
    sendmail
    Submission with the Postfix +sendmail(1) command.
    + +
    smtpd
    Mail received with the smtpd(8) +daemon.
    + +
    qmqpd
    Mail received with the qmqpd(8) +daemon.
    + +
    forward
    Local forwarding or aliasing. When +a message is received with "SMTPUTF8 required", then the forwarded +(aliased) message always has "SMTPUTF8 required".
    + +
    bounce
    Submission by the bounce(8) daemon. +When a message is received with "SMTPUTF8 required", then the +delivery status notification always has "SMTPUTF8 required".
    + +
    notify
    Postmaster notification from the +smtp(8) or smtpd(8) daemon.
    + +
    verify
    Address verification probe from the +verify(8) daemon.
    + +
    all
    Enable SMTPUTF8 autodetection for all +mail.
    + +
    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM compatibility_level 0 + +

    A safety net that causes Postfix to run with backwards-compatible +default settings after an upgrade to a newer Postfix version.

    + +

    With backwards compatibility turned on (the main.cf compatibility_level +value is less than the Postfix built-in value), Postfix looks for +settings that are left at their implicit default value, and logs a +message when a backwards-compatible default setting is required. +

    + +
    +
    +using backwards-compatible default setting name=value
+    to [accept a specific client request]
+
+using backwards-compatible default setting name=value
+    to [enable specific Postfix behavior]
+
    +
    + +

    See COMPATIBILITY_README for specific message details. If such +a message is logged in the context of a legitimate request, the +system administrator should make the backwards-compatible setting +permanent in main.cf or master.cf, for example:

    + +
    +
    +# postconf name=value
+# postfix reload
+
    +
    + +

    When no more backwards-compatible settings need to be made +permanent, the administrator should turn off backwards compatibility +by updating the compatibility_level setting in main.cf:

    + +
    +
    +# postconf compatibility_level=N
+# postfix reload
+
    +
    + +

    For N specify the number that is logged in your postfix(1) +warning message:

    + +
    +
    +warning: To disable backwards compatibility use "postconf
+    compatibility_level=N" and "postfix reload"
+
    +
    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM message_drop_headers bcc, content-length, resent-bcc, return-path + +

    Names of message headers that the cleanup(8) daemon will remove +after applying header_checks(5) and before invoking Milter applications. +The default setting is compatible with Postfix < 3.0.

    + +

    Specify a list of header names, separated by comma or space. +Names are matched in a case-insensitive manner. The list of supported +header names is limited only by available memory.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM nullmx_reject_code 556 + +

    The numerical reply code when the Postfix SMTP server rejects +a sender or recipient address because its domain has a nullmx DNS +record (an MX record with an empty hostname). This is one of the +possible replies from the restrictions reject_unknown_sender_domain +and reject_unknown_recipient_domain.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtpd_dns_reply_filter + +

    Optional filter for Postfix SMTP server DNS lookup results. +See smtp_dns_reply_filter for details including an example. +

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM lmtp_dns_reply_filter + +

    Optional filter for Postfix LMTP client DNS lookup results. +See smtp_dns_reply_filter for details including an example.

    + +

    This feature is available in Postfix 3.0 and later.

    + +#%PARAM postscreen_dns_reply_filter +# +#

    Optional filter for postscreen(8) DNS lookup results. +#See smtp_dns_reply_filter for details including an example. +#

    +# +#

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtp_dns_reply_filter + +

    Optional filter for Postfix SMTP client DNS lookup results. +Specify zero or more lookup tables. The lookup tables are searched +in the given order for a match with the DNS lookup result, converted +to the following form:

    + +
    +    name ttl class type preference value
+
    + +

    The class field is always "IN", the preference +field exists only for MX records, the names of hosts, domains, etc. +end in ".", and those names are in ASCII form (xn--mumble form in +the case of UTF8 names).

    + +

    When a match is found, the table lookup result specifies an +action. By default, the table query and the action name are +case-insensitive. Currently, only the IGNORE action is +implemented.

    + +

    Notes:

    + +
      + +

    • Postfix DNS reply filters have no effect on implicit DNS +lookups through nsswitch.conf or equivalent mechanisms.

      + +

    • The Postfix SMTP/LMTP client uses smtp_dns_reply_filter +and lmtp_dns_reply_filter only to discover a remote SMTP or LMTP +service (record types MX, A, AAAAA, and TLSA). These lookups are +also made to implement the features reject_unverified_sender and +reject_unverified_recipient.

      + +

    • The Postfix SMTP/LMTP client defers mail delivery when +a filter removes all lookup results from a successful query.

      + +

    • Postfix SMTP server uses smtpd_dns_reply_filter only to +look up MX, A, AAAAA, and TXT records to implement the features +reject_unknown_helo_hostname, reject_unknown_sender_domain, +reject_unknown_recipient_domain, reject_rbl_*, and reject_rhsbl_*. +

      + +

    • The Postfix SMTP server logs a warning or defers mail +delivery when a filter removes all lookup results from a successful +query.

      + +
    + +

    Example: ignore Google AAAA records in Postfix SMTP client DNS +lookups, because Google sometimes hard-rejects mail from IPv6 clients +with valid PTR etc. records.

    + +
    +/etc/postfix/main.cf:
+    smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter
+
    + +
    +/etc/postfix/smtp_dns_reply_filter:
+    # /domain ttl IN AAAA address/ action, all case-insensitive.
+    # Note: the domain name ends in ".".
+    /^\S+\.google\.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
+
    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtp_tls_wrappermode no + +

    Request that the Postfix SMTP client connects using the +legacy SMTPS protocol instead of using the STARTTLS command.

    + +

    This mode requires "smtp_tls_security_level = encrypt" or +stronger.

    + +

    Example: deliver all remote mail via a provider's server +"mail.example.com".

    + +
    +/etc/postfix/main.cf:
+    # Client-side SMTPS requires "encrypt" or stronger.
+    smtp_tls_security_level = encrypt
+    smtp_tls_wrappermode = yes
+    # The [] suppress MX lookups.
+    relayhost = [mail.example.com]:465
+
    + +

    More examples are in TLS_README, including examples for older +Postfix versions.

    + +

    This feature is available in Postfix 3.0 and later.

    + +%PARAM smtp_tls_connection_reuse no + +

    Try to make multiple deliveries per TLS-encrypted connection. +This uses the tlsproxy(8) service to encrypt an SMTP connection, +uses the scache(8) service to save that connection, and relies on +hints from the qmgr(8) daemon.

    + +

    See "Client-side +TLS connection reuse" for background details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM lmtp_tls_connection_reuse no + +

    The LMTP-specific version of the smtp_tls_connection_reuse configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM virtual_alias_address_length_limit 1000 + +

    +The maximal length of an email address after virtual alias expansion. +This stops virtual aliasing loops that increase the address length +exponentially. +

    + +

    +This feature is available in Postfix 3.0 and later. +

    + +%PARAM dns_ncache_ttl_fix_enable no + +

    Enable a workaround for future libc incompatibility. The Postfix +implementation of RFC 2308 negative reply caching relies on the +promise that res_query() and res_search() invoke res_send(), which +returns the server response in an application buffer even if the +requested record does not exist. If this promise is broken, specify +"yes" to enable a workaround for DNS reputation lookups.

    + +

    +This feature is available in Postfix 3.1 and later. +

    + +%PARAM smtpd_policy_service_policy_context + +

    Optional information that the Postfix SMTP server specifies in +the "policy_context" attribute of a policy service request (originally, +to share the same service endpoint among multiple check_policy_service +clients).

    + +

    +This feature is available in Postfix 3.1 and later. +

    + +%PARAM smtp_tls_dane_insecure_mx_policy see "postconf -d" output + +

    The TLS policy for MX hosts with "secure" TLSA records when the +nexthop destination security level is dane, but the MX +record was found via an "insecure" MX lookup. The choices are: +

    + +
    +
    may
    +
    The TLSA records will be ignored and TLS will be optional. If +the MX host does not appear to support STARTTLS, or the STARTTLS +handshake fails, mail may be sent in the clear.
    +
    encrypt
    +
    The TLSA records will signal a requirement to use TLS. While +TLS encryption will be required, authentication will not be performed. +
    +
    dane (default)
    +
    The TLSA records will be used just as with "secure" MX records. +TLS encryption will be required, and, if at least one of the TLSA +records is "usable", authentication will be required. When +authentication succeeds, it will be logged only as "Trusted", not +"Verified", because the MX host name could have been forged.
    +
    + +

    The default setting for Postfix ≥ 3.6 is "dane" with +"smtp_tls_security_level = dane", otherwise "may". This behavior +was backported to Postfix versions 3.5.9, 3.4.19, 3.3.16. 3.2.21. +With earlier +Postfix versions the default setting was always "dane".

    + +

    Though with "insecure" MX records an active attacker can +compromise SMTP transport security by returning forged MX records, +such attacks are "tamper-evident" since any forged MX hostnames +will be recorded in the mail logs. Attackers who place a high value +staying hidden may be deterred from forging MX records.

    + +

    +This feature is available in Postfix 3.1 and later. The may +policy is backwards-compatible with earlier Postfix versions. +

    + +%PARAM openssl_path openssl + +

    +The location of the OpenSSL command line program openssl(1). This +is used by the "postfix tls" command to create private keys, +certificate signing requests, self-signed certificates, and to +compute public key digests for DANE TLSA records. In multi-instance +environments, this parameter is always determined from the configuration +of the default Postfix instance. +

    + +

    Example:

    + +
    +
    +/etc/postfix/main.cf:
+    # NetBSD pkgsrc:
+    openssl_path = /usr/pkg/bin/openssl
+    # Local build:
+    openssl_path = /usr/local/bin/openssl
+
    +
    + +

    +This feature is available in Postfix 3.1 and later. +

    + +%PARAM address_verify_pending_request_limit see "postconf -d" output + +

    A safety limit that prevents address verification requests from +overwhelming the Postfix queue. By default, the number of pending +requests is limited to 1/4 of the active queue maximum size +(qmgr_message_active_limit). The queue manager enforces the limit +by tempfailing requests that exceed the limit. This affects only +unknown addresses and inactive addresses that have expired, because +the verify(8) daemon automatically refreshes an active address +before it expires.

    + +

    This feature is available in Postfix 3.1 and later.

    + +%PARAM smtpd_milter_maps + +

    Lookup tables with Milter settings per remote SMTP client IP +address. The lookup result overrides the smtpd_milters setting, +and has the same syntax.

    + +

    Note: lookup tables cannot return empty responses. Specify a +lookup result of DISABLE (case does not matter) to indicate that +Milter support should be disabled.

    + +

    Example to disable Milters for local clients:

    + +
    +/etc/postfix/main.cf:
+    smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_map
+    smtpd_milters = inet:host:port, { inet:host:port, ... }, ...
+
    + +
    +/etc/postfix/smtpd_milter_map:
+    # Disable Milters for local clients.
+    127.0.0.0/8    DISABLE
+    192.168.0.0/16 DISABLE
+    ::/64          DISABLE
+    2001:db8::/32  DISABLE
+
    + +

    This feature is available in Postfix 3.2 and later.

    + +%PARAM enable_idna2003_compatibility no + +

    Enable 'transitional' compatibility between IDNA2003 and IDNA2008, +when converting UTF-8 domain names to/from the ASCII form that is +used for DNS lookups. Specify "yes" for compatibility with Postfix +≤ 3.1 (not recommended). This affects the conversion of domain +names that contain for example the German sz and the Greek zeta. +See http://unicode.org/cldr/utility/idna.jsp for more examples. +

    + +

    This feature is available in Postfix 3.2 and later.

    + +%PARAM smtp_balance_inet_protocols yes + +

    When a remote destination resolves to a combination of IPv4 and +IPv6 addresses, ensure that the Postfix SMTP client can try both +address types before it runs into the smtp_mx_address_limit.

    + +

    This avoids an interoperability problem when a destination resolves +to primarily IPv6 addresses, the smtp_address_limit feature eliminates +most or all IPv4 addresses, and the destination is not reachable over +IPv6.

    + +

    This feature is available in Postfix 3.3 and later.

    + +%PARAM lmtp_balance_inet_protocols yes + +

    The LMTP-specific version of the smtp_balance_inet_protocols +configuration parameter. See there for details.

    + +

    This feature is available in Postfix 3.3 and later.

    + +%PARAM header_from_format standard + +

    The format of the Postfix-generated From: header. This +setting affects the appearance of 'full name' information when a +local program such as /bin/mail submits a message without From: +header through the Postfix sendmail(1) command.

    + +

    Specify one of the following:

    + +
    + +
    standard (default)
    Produce a header formatted +as "From: name <address>". +This is the default as of Postfix 3.3.
    + +
    obsolete
    Produce a header formatted as "From: +address (name)". This is the behavior +prior to Postfix 3.3.
    + +
    + +

    Notes:

    + +
      + +

    • Postfix generates the format "From: address" +when name information is unavailable or the envelope sender +address is empty. This is the same behavior as prior to Postfix +3.3.

      + +

    • In the standard form, the name will be quoted +if it contains specials as defined in RFC 5322, or the "!%" +address operators.

      + +

    • The Postfix sendmail(1) command gets name information +from the -F command-line option, from the NAME +environment variable, or from the UNIX password file.

      + +
    + +

    This feature is available in Postfix 3.3 and later.

    + +%PARAM tlsproxy_client_CAfile $smtp_tls_CAfile + +

    A file containing CA certificates of root CAs trusted to sign +either remote TLS server certificates or intermediate CA certificates. +See smtp_tls_CAfile for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_CApath $smtp_tls_CApath + +

    Directory with PEM format Certification Authority certificates +that the Postfix tlsproxy(8) client uses to verify a remote TLS +server certificate. See smtp_tls_CApath for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_cert_file $smtp_tls_cert_file + +

    File with the Postfix tlsproxy(8) client RSA certificate in PEM +format. See smtp_tls_cert_file for further details. The preferred way +to configure tlsproxy client keys and certificates is via the +"tlsproxy_client_chain_files" parameter.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_key_file $smtp_tls_key_file + +

    File with the Postfix tlsproxy(8) client RSA private key in PEM +format. See smtp_tls_key_file for further details. The preferred way to +configure tlsproxy client keys and certificates is via the +"tlsproxy_client_chain_files" parameter.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_dcert_file $smtp_tls_dcert_file + +

    File with the Postfix tlsproxy(8) client DSA certificate in PEM +format. See smtp_tls_dcert_file for further details. DSA is obsolete and +should not be used.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_dkey_file $smtp_tls_dkey_file + +

    File with the Postfix tlsproxy(8) client DSA private key in PEM +format. See smtp_tls_dkey_file for further details. DSA is obsolete and +should not be used.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_eccert_file $smtp_tls_eccert_file + +

    File with the Postfix tlsproxy(8) client ECDSA certificate in PEM +format. See smtp_tls_eccert_file for further details. The preferred way +to configure tlsproxy client keys and certificates is via the +"tlsproxy_client_chain_files" parameter.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_eckey_file $smtp_tls_eckey_file + +

    File with the Postfix tlsproxy(8) client ECDSA private key in PEM +format. See smtp_tls_eckey_file for further details. The preferred way +to configure tlsproxy client keys and certificates is via the +"tlsproxy_client_chain_files" parameter.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_fingerprint_digest $smtp_tls_fingerprint_digest + +

    The message digest algorithm used to construct remote TLS server +certificate fingerprints. See smtp_tls_fingerprint_digest for +further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_loglevel $smtp_tls_loglevel + +

    Enable additional Postfix tlsproxy(8) client logging of TLS +activity. See smtp_tls_loglevel for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_loglevel_parameter smtp_tls_loglevel + +

    The name of the parameter that provides the tlsproxy_client_loglevel +value.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_scert_verifydepth $smtp_tls_scert_verifydepth + +

    The verification depth for remote TLS server certificates. +See smtp_tls_scert_verifydepth for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_security_level $smtp_tls_security_level + +

    The default TLS security level for the Postfix tlsproxy(8) +client. See smtp_tls_security_level for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_per_site $smtp_tls_per_site + +

    Optional lookup tables with the Postfix tlsproxy(8) client TLS +usage policy by next-hop destination and by remote TLS server +hostname. See smtp_tls_per_site for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_policy_maps $smtp_tls_policy_maps + +

    Optional lookup tables with the Postfix tlsproxy(8) client TLS +security policy by next-hop destination. See smtp_tls_policy_maps +for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_use_tls $smtp_use_tls + +

    Opportunistic mode: use TLS when a remote server announces TLS +support. See smtp_use_tls for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_enforce_tls $smtp_enforce_tls + +

    Enforcement mode: require that SMTP servers use TLS encryption. +See smtp_enforce_tls for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM smtpd_tls_chain_files + +

    List of one or more PEM files, each holding one or more private keys +directly followed by a corresponding certificate chain. The file names +are separated by commas and/or whitespace. This parameter obsoletes the +legacy algorithm-specific key and certificate file settings. When this +parameter is non-empty, the legacy parameters are ignored, and a warning +is logged if any are also non-empty.

    + +

    With the proliferation of multiple private key algorithms—which, +as of OpenSSL 1.1.1, include DSA (obsolete), RSA, ECDSA, Ed25519 +and Ed448—it is increasingly impractical to use separate +parameters to configure the key and certificate chain for each +algorithm. Therefore, Postfix now supports storing multiple keys and +corresponding certificate chains in a single file or in a set of files. + +

    Each key must appear immediately before the corresponding +certificate, optionally followed by additional issuer certificates that +complete the certificate chain for that key. When multiple files are +specified, they are equivalent to a single file that is concatenated +from those files in the given order. Thus, while a key must always +precede its certificate and issuer chain, it can be in a separate file, +so long as that file is listed immediately before the file that holds +the corresponding certificate chain. Once all the files are +concatenated, the sequence of PEM objects must be: key1, cert1, +[chain1], key2, cert2, [chain2], ..., keyN, certN, [chainN].

    + +

    Storing the private key in the same file as the corresponding +certificate is more reliable. With the key and certificate in separate +files, there is a chance that during key rollover a Postfix process +might load a private key and certificate from separate files that don't +match. Various operational errors may even result in a persistent +broken configuration in which the certificate does not match the private +key.

    + +

    The file or files must contain at most one key of each type. If, +for example, two or more RSA keys and corresponding chains are listed, +depending on the version of OpenSSL either only the last one will be +used or an configuration error may be detected. Note that while +"Ed25519" and "Ed448" are considered separate algorithms, the various +ECDSA curves (typically one of prime256v1, secp384r1 or secp521r1) are +considered as different parameters of a single "ECDSA" algorithm, so it +is not presently possible to configure keys for more than one ECDSA +curve.

    + +

    RSA is still the most widely supported algorithm. Presently (late +2018), ECDSA support is common, but not yet universal, and Ed25519 and +Ed448 support is mostly absent. Therefore, an RSA key should generally +be configured, along with any additional keys for the other algorithms +when desired.

    + +

    +Example (separate files for each key and corresponding certificate chain): +

    +
    +
    +/etc/postfix/main.cf:
+    smtpd_tls_chain_files =
+        ${config_directory}/ed25519.pem,
+        ${config_directory}/ed448.pem,
+        ${config_directory}/rsa.pem
+
    +
    + +
    +
    +/etc/postfix/ed25519.pem:
+    -----BEGIN PRIVATE KEY-----
+    MC4CAQAwBQYDK2VwBCIEIEJfbbO4BgBQGBg9NAbIJaDBqZb4bC4cOkjtAH+Efbz3
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBKzCB3qADAgECAhQaw+rflRreYuUZBp0HuNn/e5rMZDAFBgMrZXAwFDESMBAG
+    ...
+    nC0egv51YPDWxEHom4QA
+    -----END CERTIFICATE-----
+
    +
    + +
    +
    +/etc/postfix/ed448.pem:
+    -----BEGIN PRIVATE KEY-----
+    MEcCAQAwBQYDK2VxBDsEOQf+m0P+G0qi+NZ0RolyeiE5zdlPQR8h8y4jByBifpIe
+    LNler7nzHQJ1SLcOiXFHXlxp/84VZuh32A==
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBdjCB96ADAgECAhQSv4oP972KypOZPNPF4fmsiQoRHzAFBgMrZXEwFDESMBAG
+    ...
+    pQcWsx+4J29e6YWH3Cy/CdUaexKP4RPCZDrPX7bk5C2BQ+eeYOxyThMA
+    -----END CERTIFICATE-----
+
    +
    + +
    +
    +/etc/postfix/rsa.pem:
+    -----BEGIN PRIVATE KEY-----
+    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDc4QusgkahH9rL
+    ...
+    ahQkZ3+krcaJvDSMgvu0tDc=
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIC+DCCAeCgAwIBAgIUIUkrbk1GAemPCT8i9wKsTGDH7HswDQYJKoZIhvcNAQEL
+    ...
+    Rirz15HGVNTK8wzFd+nulPzwUo6dH2IU8KazmyRi7OGvpyrMlm15TRE2oyE=
+    -----END CERTIFICATE-----
+
    +
    + +

    +Example (all keys and certificates in a single file): +

    +
    +
    +/etc/postfix/main.cf:
+    smtpd_tls_chain_files = ${config_directory}/chains.pem
+
    +
    + +
    +
    +/etc/postfix/chains.pem:
+    -----BEGIN PRIVATE KEY-----
+    MC4CAQAwBQYDK2VwBCIEIEJfbbO4BgBQGBg9NAbIJaDBqZb4bC4cOkjtAH+Efbz3
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBKzCB3qADAgECAhQaw+rflRreYuUZBp0HuNn/e5rMZDAFBgMrZXAwFDESMBAG
+    ...
+    nC0egv51YPDWxEHom4QA
+    -----END CERTIFICATE-----
+    -----BEGIN PRIVATE KEY-----
+    MEcCAQAwBQYDK2VxBDsEOQf+m0P+G0qi+NZ0RolyeiE5zdlPQR8h8y4jByBifpIe
+    LNler7nzHQJ1SLcOiXFHXlxp/84VZuh32A==
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBdjCB96ADAgECAhQSv4oP972KypOZPNPF4fmsiQoRHzAFBgMrZXEwFDESMBAG
+    ...
+    pQcWsx+4J29e6YWH3Cy/CdUaexKP4RPCZDrPX7bk5C2BQ+eeYOxyThMA
+    -----END CERTIFICATE-----
+    -----BEGIN PRIVATE KEY-----
+    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDc4QusgkahH9rL
+    ...
+    ahQkZ3+krcaJvDSMgvu0tDc=
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIC+DCCAeCgAwIBAgIUIUkrbk1GAemPCT8i9wKsTGDH7HswDQYJKoZIhvcNAQEL
+    ...
+    Rirz15HGVNTK8wzFd+nulPzwUo6dH2IU8KazmyRi7OGvpyrMlm15TRE2oyE=
+    -----END CERTIFICATE-----
+
    +
    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM smtp_tls_chain_files + +

    List of one or more PEM files, each holding one or more private keys +directly followed by a corresponding certificate chain. The file names +are separated by commas and/or whitespace. This parameter obsoletes the +legacy algorithm-specific key and certificate file settings. When this +parameter is non-empty, the legacy parameters are ignored, and a warning +is logged if any are also non-empty.

    + +

    With the proliferation of multiple private key algorithms—which, +as of OpenSSL 1.1.1, include DSA (obsolete), RSA, ECDSA, Ed25519 +and Ed448—it is increasingly impractical to use separate +parameters to configure the key and certificate chain for each +algorithm. Therefore, Postfix now supports storing multiple keys and +corresponding certificate chains in a single file or in a set of files. + +

    Each key must appear immediately before the corresponding +certificate, optionally followed by additional issuer certificates that +complete the certificate chain for that key. When multiple files are +specified, they are equivalent to a single file that is concatenated +from those files in the given order. Thus, while a key must always +precede its certificate and issuer chain, it can be in a separate file, +so long as that file is listed immediately before the file that holds +the corresponding certificate chain. Once all the files are +concatenated, the sequence of PEM objects must be: key1, cert1, +[chain1], key2, cert2, [chain2], ..., keyN, certN, [chainN].

    + +

    Storing the private key in the same file as the corresponding +certificate is more reliable. With the key and certificate in separate +files, there is a chance that during key rollover a Postfix process +might load a private key and certificate from separate files that don't +match. Various operational errors may even result in a persistent +broken configuration in which the certificate does not match the private +key.

    + +

    The file or files must contain at most one key of each type. If, +for example, two or more RSA keys and corresponding chains are listed, +depending on the version of OpenSSL either only the last one will be +used or an configuration error may be detected. Note that while +"Ed25519" and "Ed448" are considered separate algorithms, the various +ECDSA curves (typically one of prime256v1, secp384r1 or secp521r1) are +considered as different parameters of a single "ECDSA" algorithm, so it +is not presently possible to configure keys for more than one ECDSA +curve.

    + +

    +Example (separate files for each key and corresponding certificate chain): +

    +
    +
    +/etc/postfix/main.cf:
+    smtp_tls_chain_files =
+        ${config_directory}/ed25519.pem,
+        ${config_directory}/ed448.pem,
+        ${config_directory}/rsa.pem
+
    +
    + +
    +
    +/etc/postfix/ed25519.pem:
+    -----BEGIN PRIVATE KEY-----
+    MC4CAQAwBQYDK2VwBCIEIEJfbbO4BgBQGBg9NAbIJaDBqZb4bC4cOkjtAH+Efbz3
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBKzCB3qADAgECAhQaw+rflRreYuUZBp0HuNn/e5rMZDAFBgMrZXAwFDESMBAG
+    ...
+    nC0egv51YPDWxEHom4QA
+    -----END CERTIFICATE-----
+
    +
    + +
    +
    +/etc/postfix/ed448.pem:
+    -----BEGIN PRIVATE KEY-----
+    MEcCAQAwBQYDK2VxBDsEOQf+m0P+G0qi+NZ0RolyeiE5zdlPQR8h8y4jByBifpIe
+    LNler7nzHQJ1SLcOiXFHXlxp/84VZuh32A==
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBdjCB96ADAgECAhQSv4oP972KypOZPNPF4fmsiQoRHzAFBgMrZXEwFDESMBAG
+    ...
+    pQcWsx+4J29e6YWH3Cy/CdUaexKP4RPCZDrPX7bk5C2BQ+eeYOxyThMA
+    -----END CERTIFICATE-----
+
    +
    + +
    +
    +/etc/postfix/rsa.pem:
+    -----BEGIN PRIVATE KEY-----
+    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDc4QusgkahH9rL
+    ...
+    ahQkZ3+krcaJvDSMgvu0tDc=
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIC+DCCAeCgAwIBAgIUIUkrbk1GAemPCT8i9wKsTGDH7HswDQYJKoZIhvcNAQEL
+    ...
+    Rirz15HGVNTK8wzFd+nulPzwUo6dH2IU8KazmyRi7OGvpyrMlm15TRE2oyE=
+    -----END CERTIFICATE-----
+
    +
    + +

    +Example (all keys and certificates in a single file): +

    +
    +
    +/etc/postfix/main.cf:
+    smtp_tls_chain_files = ${config_directory}/chains.pem
+
    +
    + +
    +
    +/etc/postfix/chains.pem:
+    -----BEGIN PRIVATE KEY-----
+    MC4CAQAwBQYDK2VwBCIEIEJfbbO4BgBQGBg9NAbIJaDBqZb4bC4cOkjtAH+Efbz3
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBKzCB3qADAgECAhQaw+rflRreYuUZBp0HuNn/e5rMZDAFBgMrZXAwFDESMBAG
+    ...
+    nC0egv51YPDWxEHom4QA
+    -----END CERTIFICATE-----
+    -----BEGIN PRIVATE KEY-----
+    MEcCAQAwBQYDK2VxBDsEOQf+m0P+G0qi+NZ0RolyeiE5zdlPQR8h8y4jByBifpIe
+    LNler7nzHQJ1SLcOiXFHXlxp/84VZuh32A==
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIBdjCB96ADAgECAhQSv4oP972KypOZPNPF4fmsiQoRHzAFBgMrZXEwFDESMBAG
+    ...
+    pQcWsx+4J29e6YWH3Cy/CdUaexKP4RPCZDrPX7bk5C2BQ+eeYOxyThMA
+    -----END CERTIFICATE-----
+    -----BEGIN PRIVATE KEY-----
+    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDc4QusgkahH9rL
+    ...
+    ahQkZ3+krcaJvDSMgvu0tDc=
+    -----END PRIVATE KEY-----
+    -----BEGIN CERTIFICATE-----
+    MIIC+DCCAeCgAwIBAgIUIUkrbk1GAemPCT8i9wKsTGDH7HswDQYJKoZIhvcNAQEL
+    ...
+    Rirz15HGVNTK8wzFd+nulPzwUo6dH2IU8KazmyRi7OGvpyrMlm15TRE2oyE=
+    -----END CERTIFICATE-----
+
    +
    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM lmtp_tls_chain_files + +

    The LMTP-specific version of the smtp_tls_chain_files configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_client_chain_files $smtp_tls_chain_files + +

    Files with the Postfix tlsproxy(8) client keys and certificate +chains in PEM format. See smtp_tls_chain_files for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tlsproxy_tls_chain_files $smtpd_tls_chain_files + +

    Files with the Postfix tlsproxy(8) server keys and certificate +chains in PEM format. See smtpd_tls_chain_files for further details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM tls_server_sni_maps + +

    Optional lookup tables that map names received from remote SMTP +clients via the TLS Server Name Indication (SNI) extension to the +appropriate keys and certificate chains. This parameter is implemented +in the Postfix TLS library, and applies to both smtpd(8) and the SMTP +server mode of tlsproxy(8).

    + +

    The lookup key is either the verbatim SNI domain name or an +ancestor domain prefixed with a leading dot. For internationalized +domains, the lookup key must be in IDNA 2008 A-label form (as +required in the TLS SNI extension).

    + +

    When this parameter is non-empty, the Postfix SMTP server enables +SNI extension processing, and logs SNI values that are invalid or +don't match an entry in the the specified tables. When an entry +does match, the SNI name is logged as part of the connection summary +at log levels 1 and higher.

    + +

    Note that the SNI lookup tables should also have entries for +the domains that correspond to the Postfix SMTP server's default +certificate(s). This ensures that the remote SMTP client's TLS SNI +extension gets a positive response when it specifies one of the +Postfix SMTP server's default domains, and ensures that the Postfix +SMTP server will not log an SNI name mismatch for such a domain. +The Postfix SMTP server's default certificates are then only used +when the client sends no SNI or when it sends SNI with a domain +that the server knows no certificate(s) for.

    + +

    The mapping from an SNI domain name to a certificate chain is +typically indirect. In the input source files for "cdb", "hash", +"btree" or other tables that are converted to on-disk indexed files +via postmap(1), the value specified for each key is a list of +filenames. When postmap(1) is used with the -F option, the +generated table stores for each lookup key the base64-encoded +contents of the associated files. When querying tables via postmap +-Fq, the table value is decoded from base64, yielding the original +file content, plus a new line.

    + +

    With "regexp", "pcre", "inline", "texthash", "static" and similar +tables that are interpreted at run-time, and don't have a separate +source format, the table value is again a list files, that are read-in +when the table is opened.

    + +

    Thus, for example:

    + +
    +
    +$ postmap -Fq "" static:/etc/postfix/chain.pem | openssl dgst -sha1
+(stdin)= da39a3ee5e6b4b0d3255bfef95601890afd80709
+
    +
    + +

    produces the same output as:

    + +
    +
    +$ (cat /etc/postfix/chain.pem; echo) | openssl dgst -sha1
+(stdin)= da39a3ee5e6b4b0d3255bfef95601890afd80709
+
    +
    + +

    With tables whose content is managed outside of Postfix, such +as LDAP, MySQL, PostgreSQL, socketmap and tcp, the value must be a +concatenation of the desired PEM keys and certificate chains, that +is then further encoded to yield a single-line base64 string. +Creation of such tables and secure storage are outside the +responsibility of Postfix. With "socketmap" and "tcp" the data +would be transmitted in the clear. With LDAP and SQL, you should +generally use TLS to protect the sensitive data in transit.

    + +

    Typically there is only private key and its chain of certificates +starting with the "leaf" certificate corresponding to that key, and +continuing with the appropriate intermediate issuer CA certificates, +with each certificate ideally followed by its issuer. Servers +that have keys and certificates for more than one algorithm (e.g. +both an RSA key and an ECDSA key, or even RSA, ECDSA and Ed25519) +can use multiple chains concatenated together, with the key always +listed before the corresponding certificates.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM smtp_tls_servername + +

    Optional name to send to the remote SMTP server in the TLS Server +Name Indication (SNI) extension. The SNI extension is always on when +DANE is used to authenticate the server, and in that case the SNI name +sent is the one required by RFC7672 and this parameter is ignored.

    + +

    Some SMTP servers use the received SNI name to select an appropriate +certificate chain to present to the client. While this may improve +interoperability with such servers, it may reduce interoperability with +other servers that choose to abort the connection when they don't have a +certificate chain configured for the requested name. Such servers +should select a default certificate chain and continue the handshake, +but some may not. Therefore, absent DANE, no SNI name is sent by +default.

    + +

    The SNI name must be either a valid DNS hostname, or else one of the +special values hostname or nexthop, which select either the +remote hostname or the nexthop domain respectively. DNS names for SNI must be +in A-label (punycode) form. Invalid DNS names log a configuration error +warning and mail delivery is deferred.

    + +

    Except when using a relayhost to forward all email, the only +sensible non-empty main.cf setting for this parameter is +hostname. Other non-empty values are only practical on a +per-destination basis via the servername attribute of the Postfix +TLS policy table. When +in doubt, leave this parameter empty, and configure per-destination SNI +as needed.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM lmtp_tls_servername + +

    The LMTP-specific version of the smtp_tls_servername configuration +parameter. See there for details.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM maillog_file + +

    The name of an optional logfile that is written by the Postfix +postlogd(8) service. An empty value selects logging to syslogd(8). +Specify "/dev/stdout" to select logging to standard output. Stdout +logging requires that Postfix is started with "postfix start-fg". +

    + +

    Note 1: The maillog_file parameter value must contain a prefix +that is specified with the maillog_file_prefixes parameter.

    + +

    Note 2: Some Postfix non-daemon programs may still log information +to syslogd(8), before they have processed their configuration +parameters and command-line options.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM postlog_service_name postlog + +

    The name of the postlogd(8) service entry in master.cf. +This service appends logfile records to the file specified +with the maillog_file parameter.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM postlogd_watchdog_timeout 10s + +

    How much time a postlogd(8) process may take to process a request +before it is terminated by a built-in watchdog timer. This is a +safety mechanism that prevents postlogd(8) from becoming non-responsive +due to a bug in Postfix itself or in system software. This limit +cannot be set under 10s.

    + +

    Specify a non-zero time value (an integral value plus an optional +one-letter suffix that specifies the time unit). Time units: s +(seconds), m (minutes), h (hours), d (days), w (weeks).

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM maillog_file_prefixes /var, /dev/stdout + +

    A list of allowed prefixes for a maillog_file value. This is a +safety feature to contain the damage from a single configuration +mistake. Specify one or more prefix strings, separated by comma or +whitespace.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM maillog_file_compressor gzip + +

    The program to run after rotating $maillog_file with "postfix +logrotate". The command is run with the rotated logfile name as its +first argument.

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM maillog_file_rotate_suffix %Y%m%d-%H%M%S + +

    The format of the suffix to append to $maillog_file while rotating +the file with "postfix logrotate". See strftime(3) for syntax. The +default suffix, YYYYMMDD-HHMMSS, allows logs to be rotated frequently. +

    + +

    This feature is available in Postfix 3.4 and later.

    + +%PARAM dnssec_probe ns:. + +

    The DNS query type (default: "ns") and DNS query name (default: +".") that Postfix may use to determine whether DNSSEC validation +is available. +

    + +

    Background: DNSSEC validation is needed for Postfix DANE support; +this ensures that Postfix receives TLSA records with secure TLS +server certificate info. When DNSSEC validation is unavailable, +mail deliveries using opportunistic DANE will not be protected +by server certificate info in TLSA records, and mail deliveries +using mandatory DANE will not be made at all.

    + +

    By default, a Postfix process will send a DNSSEC probe after +1) the process made a DNS query that requested DNSSEC validation, +2) the process did not receive a DNSSEC validated response to this +query or to an earlier query, and 3) the process did not already +send a DNSSEC probe.

    + +

    When the DNSSEC probe has no response, or when the response is +not DNSSEC validated, Postfix logs a warning that DNSSEC validation +may be unavailable.

    + +

    Example:

    + +
    +warning: DNSSEC validation may be unavailable
+warning: reason: dnssec_probe 'ns:.' received a response that is not DNSSEC validated
+warning: reason: dnssec_probe 'ns:.' received no response: Server failure
+
    + +

    Possible reasons why DNSSEC validation may be unavailable:

    + +
      + +
    • The local /etc/resolv.conf file specifies a DNS resolver that +does not validate DNSSEC signatures (that's +$queue_directory/etc/resolv.conf when a Postfix daemon runs in a +chroot jail). + +
    • The local system library does not pass on the "DNSSEC validated" +bit to Postfix, or Postfix does not know how to ask the library to +do that. + +
    + +

    By default, the DNSSEC probe asks for the DNS root zone NS +records, because resolvers should always have that information +cached. If Postfix runs on a network where the DNS root zone is not +reachable, specify a different probe, or specify an empty dnssec_probe +value to disable the feature.

    + +

    This feature was backported from Postfix 3.6 to Postfix versions +3.5.9, 3.4.19, 3.3.16. 3.2.21.

    diff --git a/proto/postfix-wrapper b/proto/postfix-wrapper new file mode 100644 index 0000000..177282e --- /dev/null +++ b/proto/postfix-wrapper @@ -0,0 +1,290 @@ +#++ +# NAME +# postfix-wrapper 5 +# SUMMARY +# Postfix multi-instance API +# DESCRIPTION +# Support for managing multiple Postfix instances is available +# as of version 2.6. Instances share executable files and +# documentation, but have their own directories for configuration, +# queue and data files. +# +# This document describes how the familiar "postfix start" +# etc. user interface can be used to manage one or multiple +# Postfix instances, and gives details of an API to coordinate +# activities between the postfix(1) command and a multi-instance +# manager program. +# +# With multi-instance support, the default Postfix instance +# is always required. This instance is identified by the +# config_directory parameter's default value. +# GENERAL OPERATION +# .ad +# .fi +# Multi-instance support is backwards compatible: when you +# run only one Postfix instance, commands such as "postfix +# start" will not change behavior at all. +# +# Even with multiple Postfix instances, you can keep using +# the same postfix commands in boot scripts, upgrade procedures, +# and other places. The commands do more work, but humans are +# not forced to learn new tricks. +# +# For example, to start all Postfix instances, use: +# .IP +# # postfix start +# .PP +# Other postfix(1) commands also work as expected. For example, +# to find out what Postfix instances exist in a multi-instance +# configuration, use: +# .IP +# # postfix status +# .PP +# This enumerates the status of all Postfix instances within +# a multi-instance configuration. +# MANAGING AN INDIVIDUAL POSTFIX INSTANCE +# .ad +# .fi +# To manage a specific Postfix instance, specify its configuration +# directory on the postfix(1) command line: +# .IP +# # postfix -c \fI/path/to/config_directory command\fR +# .PP +# Alternatively, the postfix(1) command accepts the instance's +# configuration directory via the MAIL_CONFIG environment +# variable (the -c command-line option has higher precedence). +# +# Otherwise, the postfix(1) command will operate on all Postfix +# instances. +# ENABLING POSTFIX(1) MULTI-INSTANCE MODE +# .ad +# .fi +# By default, the postfix(1) command operates in single-instance +# mode. In this mode the command invokes the postfix-script +# file directly (currently installed in the daemon directory). +# This file contains the commands that start or stop one +# Postfix instance, that upgrade the configuration of one +# Postfix instance, and so on. +# +# When the postfix(1) command operates in multi-instance mode +# as discussed below, the command needs to execute start, +# stop, etc. commands for each Postfix instance. This +# multiplication of commands is handled by a multi-instance +# manager program. +# +# Turning on postfix(1) multi-instance mode goes as follows: +# in the default Postfix instance's main.cf file, 1) specify +# the pathname of a multi-instance manager program with the +# multi_instance_wrapper parameter; 2) populate the +# multi_instance_directories parameter with the configuration +# directory pathnames of additional Postfix instances. For +# example: +# .IP +# .nf +# /etc/postfix/main.cf: +# multi_instance_wrapper = $daemon_directory/postfix-wrapper +# multi_instance_directories = /etc/postfix-test +# .fi +# .PP +# The $daemon_directory/postfix-wrapper file implements a +# simple manager and contains instructions for creating Postfix +# instances by hand. The postmulti(1) command provides a +# more extensive implementation including support for life-cycle +# management. +# +# The multi_instance_directories and other main.cf parameters +# are listed below in the CONFIGURATION PARAMETERS section. +# +# In multi-instance mode, the postfix(1) command invokes the +# $multi_instance_wrapper command instead of the postfix-script +# file. This multi-instance manager in turn executes the +# postfix(1) command in single-instance mode for each Postfix +# instance. +# +# To illustrate the main ideas behind multi-instance operation, +# below is an example of a simple but useful multi-instance +# manager implementation: +# .IP +# .nf +# #!/bin/sh +# +# : ${command_directory?"do not invoke this command directly"} +# +# POSTCONF=$command_directory/postconf +# POSTFIX=$command_directory/postfix +# instance_dirs=\`$POSTCONF -h multi_instance_directories | +# sed 's/,/ /'\` || exit 1 +# +# err=0 +# for dir in $config_directory $instance_dirs +# do +# case "$1" in +# stop|abort|flush|reload|drain) +# test "\`$POSTCONF -c $dir -h multi_instance_enable\`" \e +# = yes || continue;; +# start) +# test "\`$POSTCONF -c $dir -h multi_instance_enable\`" \e +# = yes || { +# $POSTFIX -c $dir check || err=$? +# continue +# };; +# esac +# $POSTFIX -c $dir "$@" || err=$? +# done +# +# exit $err +# .fi +# PER-INSTANCE MULTI-INSTANCE MANAGER CONTROLS +# .ad +# .fi +# Each Postfix instance has its own main.cf file with parameters +# that control how the multi-instance manager operates on +# that instance. This section discusses the most important +# settings. +# +# The setting "multi_instance_enable = yes" allows the +# multi-instance manager to start (stop, etc.) the corresponding +# Postfix instance. For safety reasons, this setting is not +# the default. +# +# The default setting "multi_instance_enable = no" is useful +# for manual testing with "postfix -c \fI/path/name\fR start" +# etc. The multi-instance manager will not start such an +# instance, and it will skip commands such as "stop" or "flush" +# that require a running Postfix instance. The multi-instance +# manager will execute commands such as "check", "set-permissions" +# or "upgrade-configuration", and it will replace "start" by +# "check" so that problems will be reported even when the +# instance is disabled. +# MAINTAINING SHARED AND NON-SHARED FILES +# .ad +# .fi +# Some files are shared between Postfix instances, such as +# executables and manpages, and some files are per-instance, +# such as configuration files, mail queue files, and data +# files. See the NON-SHARED FILES section below for a list +# of per-instance files. +# +# Before Postfix multi-instance support was implemented, the +# executables, manpages, etc., have always been maintained +# as part of the default Postfix instance. +# +# With multi-instance support, we simply continue to do this. +# Specifically, a Postfix instance will not check or update +# shared files when that instance's config_directory value is +# listed with the default main.cf file's multi_instance_directories +# parameter. +# +# The consequence of this approach is that the default Postfix +# instance should be checked and updated before any other +# instances. +# MULTI-INSTANCE API SUMMARY +# .ad +# .fi +# Only the multi-instance manager implements support for the +# multi_instance_enable configuration parameter. The +# multi-instance manager will start only Postfix instances +# whose main.cf file has "multi_instance_enable = yes". A +# setting of "no" allows a Postfix instance to be tested by +# hand. +# +# The postfix(1) command operates on only one Postfix instance +# when the -c option is specified, or when MAIL_CONFIG is +# present in the process environment. This is necessary to +# terminate recursion. +# +# Otherwise, when the multi_instance_directories parameter +# value is non-empty, the postfix(1) command executes the +# command specified with the multi_instance_wrapper parameter, +# instead of executing the commands in postfix-script. +# +# The multi-instance manager skips commands such as "stop" +# or "reload" that require a running Postfix instance, when +# an instance does not have "multi_instance_enable = yes". +# This avoids false error messages. +# +# The multi-instance manager replaces a "start" command by +# "check" when a Postfix instance's main.cf file does not +# have "multi_instance_enable = yes". This substitution ensures +# that problems will be reported even when the instance is +# disabled. +# +# No Postfix command or script will update or check shared +# files when its config_directory value is listed in the +# default main.cf's multi_instance_directories parameter +# value. Therefore, the default instance should be checked +# and updated before any Postfix instances that depend on it. +# +# Set-gid commands such as postdrop(1) and postqueue(1) +# effectively append the multi_instance_directories parameter +# value to the legacy alternate_config_directories parameter +# value. The commands use this information to determine whether +# a -c option or MAIL_CONFIG environment setting specifies a +# legitimate value. +# +# The legacy alternate_config_directories parameter remains +# necessary for non-default Postfix instances that are running +# different versions of Postfix, or that are not managed +# together with the default Postfix instance. +# ENVIRONMENT VARIABLES +# .ad +# .fi +# .IP MAIL_CONFIG +# When present, this forces the postfix(1) command to operate +# only on the specified Postfix instance. This environment +# variable is exported by the postfix(1) -c option, so that +# postfix(1) commands in descendant processes will work +# correctly. +# CONFIGURATION PARAMETERS +# .ad +# .fi +# The text below provides only a parameter summary. See +# postconf(5) for more details. +# .IP "\fBmulti_instance_directories (empty)\fR" +# An optional list of non-default Postfix configuration directories; +# these directories belong to additional Postfix instances that share +# the Postfix executable files and documentation with the default +# Postfix instance, and that are started, stopped, etc., together +# with the default Postfix instance. +# .IP "\fBmulti_instance_wrapper (empty)\fR" +# The pathname of a multi-instance manager command that the +# \fBpostfix\fR(1) command invokes when the multi_instance_directories +# parameter value is non-empty. +# .IP "\fBmulti_instance_name (empty)\fR" +# The optional instance name of this Postfix instance. +# .IP "\fBmulti_instance_group (empty)\fR" +# The optional instance group name of this Postfix instance. +# .IP "\fBmulti_instance_enable (no)\fR" +# Allow this Postfix instance to be started, stopped, etc., by a +# multi-instance manager. +# NON-SHARED FILES +# .ad +# .fi +# .IP "\fBconfig_directory (see 'postconf -d' output)\fR" +# The default location of the Postfix main.cf and master.cf +# configuration files. +# .IP "\fBdata_directory (see 'postconf -d' output)\fR" +# The directory with Postfix-writable data files (for example: +# caches, pseudo-random numbers). +# .IP "\fBqueue_directory (see 'postconf -d' output)\fR" +# The location of the Postfix top-level queue directory. +# SEE ALSO +# postfix(1) Postfix control program +# postmulti(1) full-blown multi-instance manager +# $daemon_directory/postfix-wrapper simple multi-instance manager +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this +# software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/regexp_table b/proto/regexp_table new file mode 100644 index 0000000..88fcded --- /dev/null +++ b/proto/regexp_table @@ -0,0 +1,178 @@ +#++ +# NAME +# regexp_table 5 +# SUMMARY +# format of Postfix regular expression tables +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" regexp:/etc/postfix/\fIfilename\fR +# +# \fBpostmap -q - regexp:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting, mail routing, or access control. These tables +# are usually in \fBdbm\fR or \fBdb\fR format. +# +# Alternatively, lookup tables can be specified in POSIX regular +# expression form. In this case, each input is compared against a +# list of patterns. When a match is found, the corresponding +# result is returned and the search is terminated. +# +# To find out what types of lookup tables your Postfix system +# supports use the "\fBpostconf -m\fR" command. +# +# To test lookup tables, use the "\fBpostmap -q\fR" command +# as described in the SYNOPSIS above. Use "\fBpostmap -hmq +# -\fR <\fIfile\fR" for header_checks(5) patterns, and +# "\fBpostmap -bmq -\fR <\fIfile\fR" for body_checks(5) +# (Postfix 2.6 and later). +# COMPATIBILITY +# .ad +# .fi +# With Postfix version 2.2 and earlier specify "\fBpostmap +# -fq\fR" to query a table that contains case sensitive +# patterns. Patterns are case insensitive by default. +# TABLE FORMAT +# .ad +# .fi +# The general form of a Postfix regular expression table is: +# .IP "\fB/\fIpattern\fB/\fIflags result\fR" +# When \fIpattern\fR matches the input string, +# use the corresponding \fIresult\fR value. +# .IP "\fB!/\fIpattern\fB/\fIflags result\fR" +# When \fIpattern\fR does \fBnot\fR match the input string, +# use the corresponding \fIresult\fR value. +# .IP "\fBif /\fIpattern\fB/\fIflags\fR" +# .IP "\fBendif\fR" +# If the input string matches /\fIpattern\fR/, then match that +# input string against the patterns between \fBif\fR and +# \fBendif\fR. The \fBif\fR..\fBendif\fR can nest. +# .sp +# Note: do not prepend whitespace to patterns inside +# \fBif\fR..\fBendif\fR. +# .sp +# This feature is available in Postfix 2.1 and later. +# .IP "\fBif !/\fIpattern\fB/\fIflags\fR" +# .IP "\fBendif\fR" +# If the input string does not match /\fIpattern\fR/, then +# match that input string against the patterns between \fBif\fR +# and \fBendif\fR. The \fBif\fR..\fBendif\fR can nest. +# .sp +# Note: do not prepend whitespace to patterns inside +# \fBif\fR..\fBendif\fR. +# .sp +# This feature is available in Postfix 2.1 and later. +# .IP "blank lines and comments" +# Empty lines and whitespace-only lines are ignored, as +# are lines whose first non-whitespace character is a `#'. +# .IP "multi-line text" +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# .PP +# Each pattern is a POSIX regular expression enclosed by a pair of +# delimiters. The regular expression syntax is documented in +# \fBre_format\fR(7) with 4.4BSD, in \fBregex\fR(5) with Solaris, and in +# \fBregex\fR(7) with Linux. Other systems may use other document names. +# +# The expression delimiter can be any non-alphanumerical +# character, except whitespace +# or characters that have special meaning (traditionally the forward +# slash is used). The regular expression can contain whitespace. +# +# By default, matching is case-insensitive, and newlines are not +# treated as special characters. The behavior is controlled by flags, +# which are toggled by appending one or more of the following +# characters after the pattern: +# .IP "\fBi\fR (default: on)" +# Toggles the case sensitivity flag. By default, matching is case +# insensitive. +# .IP "\fBm\fR (default: off)" +# Toggle the multi-line mode flag. When this flag is on, the \fB^\fR +# and \fB$\fR metacharacters match immediately after and immediately +# before a newline character, respectively, in addition to +# matching at the start and end of the input string. +# .IP "\fBx\fR (default: on)" +# Toggles the extended expression syntax flag. By default, support +# for extended expression syntax is enabled. +# TABLE SEARCH ORDER +# .ad +# .fi +# Patterns are applied in the order as specified in the table, until a +# pattern is found that matches the input string. +# +# Each pattern is applied to the entire input string. +# Depending on the application, that string is an entire client +# hostname, an entire client IP address, or an entire mail address. +# Thus, no parent domain or parent network search is done, and +# \fIuser@domain\fR mail addresses are not broken up into their +# \fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR +# broken up into \fIuser\fR and \fIfoo\fR. +# TEXT SUBSTITUTION +# .ad +# .fi +# Substitution of substrings (text that matches patterns +# inside "()") from the matched expression into the result +# string is requested with $1, $2, etc.; specify $$ to produce +# a $ character as output. +# The macros in the result string may need to be written as +# ${n} or $(n) if they aren't followed by whitespace. +# +# Note: since negated patterns (those preceded by \fB!\fR) return a +# result when the expression does not match, substitutions are not +# available for negated patterns. +# EXAMPLE SMTPD ACCESS MAP +# # Disallow sender-specified routing. This is a must if you relay mail +# # for other domains. +# /[%!@].*[%!@]/ 550 Sender-specified routing rejected +# +# # Postmaster is OK, that way they can talk to us about how to fix +# # their problem. +# /^postmaster@/ OK +# +# # Protect your outgoing majordomo exploders +# if !/^owner-/ +# /^(.*)-outgoing@(.*)$/ 550 Use ${1}@${2} instead +# endif +# EXAMPLE HEADER FILTER MAP +# # These were once common in junk mail. +# /^Subject: make money fast/ REJECT +# /^To: friend@public\\.com/ REJECT +# EXAMPLE BODY FILTER MAP +# # First skip over base 64 encoded text to save CPU cycles. +# ~^[[:alnum:]+/]{60,}$~ OK +# +# # Put your own body patterns here. +# SEE ALSO +# postmap(1), Postfix lookup table manager +# pcre_table(5), format of PCRE tables +# cidr_table(5), format of CIDR tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# AUTHOR(S) +# The regexp table lookup code was originally written by: +# LaMont Jones +# lamont@hp.com +# +# That code was based on the PCRE dictionary contributed by: +# Andrew McNamara +# andrewm@connect.com.au +# connect.com.au Pty. Ltd. +# Level 3, 213 Miller St +# North Sydney, NSW, Australia +# +# Adopted and adapted by: +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/relocated b/proto/relocated new file mode 100644 index 0000000..c716a21 --- /dev/null +++ b/proto/relocated @@ -0,0 +1,163 @@ +#++ +# NAME +# relocated 5 +# SUMMARY +# Postfix relocated table format +# SYNOPSIS +# \fBpostmap /etc/postfix/relocated\fR +# DESCRIPTION +# The optional \fBrelocated\fR(5) table provides the information that is +# used in "user has moved to \fInew_location\fR" bounce messages. +# +# Normally, the \fBrelocated\fR(5) table is specified as a text file +# that serves as input to the \fBpostmap\fR(1) command. +# The result, an indexed file in \fBdbm\fR or \fBdb\fR format, +# is used for fast searching by the mail system. Execute the command +# "\fBpostmap /etc/postfix/relocated\fR" to rebuild an indexed +# file after changing the corresponding relocated table. +# +# When the table is provided via other means such as NIS, LDAP +# or SQL, the same lookups are done as for ordinary indexed files. +# +# Alternatively, the table can be provided as a regular-expression +# map where patterns are given as regular expressions, or lookups +# can be directed to TCP-based server. In those case, the lookups +# are done in a slightly different way as described below under +# "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES". +# +# Table lookups are case insensitive. +# CASE FOLDING +# .ad +# .fi +# The search string is folded to lowercase before database +# lookup. As of Postfix 2.3, the search string is not case +# folded with database types such as regexp: or pcre: whose +# lookup fields can match both upper and lower case. +# TABLE FORMAT +# .ad +# .fi +# The input format for the \fBpostmap\fR(1) command is as follows: +# .IP \(bu +# An entry has one of the following form: +# +# .nf +# \fIpattern new_location\fR +# .fi +# +# Where \fInew_location\fR specifies contact information such as +# an email address, or perhaps a street address or telephone number. +# .IP \(bu +# Empty lines and whitespace-only lines are ignored, as +# are lines whose first non-whitespace character is a `#'. +# .IP \(bu +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# TABLE SEARCH ORDER +# .ad +# .fi +# With lookups from indexed files such as DB or DBM, or from networked +# tables such as NIS, LDAP or SQL, patterns are tried in the order as +# listed below: +# .IP \fIuser\fR@\fIdomain\fR +# Matches \fIuser\fR@\fIdomain\fR. This form has precedence over all +# other forms. +# .IP \fIuser\fR +# Matches \fIuser\fR@\fIsite\fR when \fIsite\fR is $\fBmyorigin\fR, +# when \fIsite\fR is listed in $\fBmydestination\fR, or when \fIsite\fR +# is listed in $\fBinet_interfaces\fR or $\fBproxy_interfaces\fR. +# .IP @\fIdomain\fR +# Matches other addresses in \fIdomain\fR. This form has the lowest +# precedence. +# ADDRESS EXTENSION +# .fi +# .ad +# When a mail address localpart contains the optional recipient delimiter +# (e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes: +# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR, +# \fIuser\fR, and @\fIdomain\fR. +# REGULAR EXPRESSION TABLES +# .ad +# .fi +# This section describes how the table lookups change when the table +# is given in the form of regular expressions or when lookups are +# directed to a TCP-based server. For a description of regular +# expression lookup table syntax, see \fBregexp_table\fR(5) or +# \fBpcre_table\fR(5). For a description of the TCP client/server +# table lookup protocol, see \fBtcp_table\fR(5). +# This feature is not available up to and including Postfix version 2.4. +# +# Each pattern is a regular expression that is applied to the entire +# address being looked up. Thus, \fIuser@domain\fR mail addresses are not +# broken up into their \fIuser\fR and \fI@domain\fR constituent parts, +# nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. +# +# Patterns are applied in the order as specified in the table, until a +# pattern is found that matches the search string. +# +# Results are the same as with indexed file lookups, with +# the additional feature that parenthesized substrings from the +# pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on. +# TCP-BASED TABLES +# .ad +# .fi +# This section describes how the table lookups change when lookups +# are directed to a TCP-based server. For a description of the TCP +# client/server lookup protocol, see \fBtcp_table\fR(5). +# This feature is not available up to and including Postfix version 2.4. +# +# Each lookup operation uses the entire address once. Thus, +# \fIuser@domain\fR mail addresses are not broken up into their +# \fIuser\fR and \fI@domain\fR constituent parts, nor is +# \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. +# +# Results are the same as with indexed file lookups. +# BUGS +# The table format does not understand quoting conventions. +# CONFIGURATION PARAMETERS +# .ad +# .fi +# The following \fBmain.cf\fR parameters are especially relevant. +# The text below provides only a parameter summary. See +# \fBpostconf\fR(5) for more details including examples. +# .IP \fBrelocated_maps\fR +# List of lookup tables for relocated users or sites. +# .PP +# Other parameters of interest: +# .IP \fBinet_interfaces\fR +# The network interface addresses that this system receives mail on. +# You need to stop and start Postfix when this parameter changes. +# .IP \fBmydestination\fR +# List of domains that this mail system considers local. +# .IP \fBmyorigin\fR +# The domain that is appended to locally-posted mail. +# .IP \fBproxy_interfaces\fR +# Other interfaces that this machine receives mail on by way of a +# proxy agent or network address translator. +# SEE ALSO +# trivial-rewrite(8), address resolver +# postmap(1), Postfix lookup table manager +# postconf(5), configuration parameters +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# ADDRESS_REWRITING_README, address rewriting guide +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/socketmap_table b/proto/socketmap_table new file mode 100644 index 0000000..be01054 --- /dev/null +++ b/proto/socketmap_table @@ -0,0 +1,96 @@ +#++ +# NAME +# socketmap_table 5 +# SUMMARY +# Postfix socketmap table lookup client +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" socketmap:inet:\fIhost\fB:\fIport\fB:\fIname\fR +# .br +# \fBpostmap -q "\fIstring\fB" socketmap:unix:\fIpathname\fB:\fIname\fR +# +# \fBpostmap -q - socketmap:inet:\fIhost\fB:\fIport\fB:\fIname\fB <\fIinputfile\fR +# .br +# \fBpostmap -q - socketmap:unix:\fIpathname\fB:\fIname\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting. mail routing or policy lookup. +# +# The Postfix socketmap client expects TCP endpoint names of +# the form \fBinet:\fIhost\fB:\fIport\fB:\fIname\fR, or +# UNIX-domain endpoints of the form \fBunix:\fIpathname\fB:\fIname\fR. +# In both cases, \fIname\fR specifies the name field in a +# socketmap client request (see "REQUEST FORMAT" below). +# PROTOCOL +# .ad +# .fi +# Socketmaps use a simple protocol: the client sends one +# request, and the server sends one reply. Each request and +# each reply are sent as one netstring object. +# REQUEST FORMAT +# .ad +# .fi +# The socketmap protocol supports only the lookup request. +# The request has the following form: +# +# .IP "\fB\fIname\fB \fIkey\fR" +# Search the named socketmap for the specified key. +# .PP +# Postfix will not generate partial search keys such as domain +# names without one or more subdomains, network addresses +# without one or more least-significant octets, or email +# addresses without the localpart, address extension or domain +# portion. This behavior is also found with cidr:, pcre:, and +# regexp: tables. +# REPLY FORMAT +# .ad +# .fi +# The Postfix socketmap client requires that replies are not +# longer than 100000 characters (not including the netstring +# encapsulation). Replies must have the following form: +# .IP "\fBOK \fIdata\fR" +# The requested data was found. +# .IP "\fBNOTFOUND " +# The requested data was not found. +# .IP "\fBTEMP \fIreason\fR" +# .IP "\fBTIMEOUT \fIreason\fR" +# .IP "\fBPERM \fIreason\fR" +# The request failed. The reason, if non-empty, is descriptive +# text. +# SECURITY +# This map cannot be used for security-sensitive information, +# because neither the connection nor the server are authenticated. +# SEE ALSO +# http://cr.yp.to/proto/netstrings.txt, netstring definition +# postconf(1), Postfix supported lookup tables +# postmap(1), Postfix lookup table manager +# regexp_table(5), format of regular expression tables +# pcre_table(5), format of PCRE tables +# cidr_table(5), format of CIDR tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# BUGS +# The protocol limits are not yet configurable. +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# HISTORY +# Socketmap support was introduced with Postfix version 2.10. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- + diff --git a/proto/sqlite_table b/proto/sqlite_table new file mode 100644 index 0000000..aeaba34 --- /dev/null +++ b/proto/sqlite_table @@ -0,0 +1,261 @@ +#++ +# NAME +# sqlite_table 5 +# SUMMARY +# Postfix SQLite configuration +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" sqlite:/etc/postfix/\fIfilename\fR +# +# \fBpostmap -q - sqlite:/etc/postfix/\fIfilename\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting or mail routing. These tables are usually in +# \fBdbm\fR or \fBdb\fR format. +# +# Alternatively, lookup tables can be specified as SQLite databases. +# In order to use SQLite lookups, define an SQLite source as a lookup +# table in main.cf, for example: +# .nf +# alias_maps = sqlite:/etc/sqlite-aliases.cf +# .fi +# +# The file /etc/postfix/sqlite-aliases.cf has the same format as +# the Postfix main.cf file, and can specify the parameters +# described below. +# LIST MEMBERSHIP +# .ad +# .fi +# When using SQL to store lists such as $mynetworks, +# $mydestination, $relay_domains, $local_recipient_maps, +# etc., it is important to understand that the table must +# store each list member as a separate key. The table lookup +# verifies the *existence* of the key. See "Postfix lists +# versus tables" in the DATABASE_README document for a +# discussion. +# +# Do NOT create tables that return the full list of domains +# in $mydestination or $relay_domains etc., or IP addresses +# in $mynetworks. +# +# DO create tables with each matching item as a key and with +# an arbitrary value. With SQL databases it is not uncommon to +# return the key itself or a constant value. +# SQLITE PARAMETERS +# .ad +# .fi +# .IP "\fBdbpath\fR" +# The SQLite database file location. Example: +# .nf +# dbpath = customer_database +# .fi +# .IP "\fBquery\fR" +# The SQL query template used to search the database, where \fB%s\fR +# is a substitute for the address Postfix is trying to resolve, +# e.g. +# .nf +# query = SELECT replacement FROM aliases WHERE mailbox = '%s' +# .fi +# +# This parameter supports the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. +# .IP "\fB%s\fR" +# This is replaced by the input key. +# SQL quoting is used to make sure that the input key does not +# add unexpected metacharacters. +# .IP "\fB%u\fR" +# When the input key is an address of the form user@domain, \fB%u\fR +# is replaced by the SQL quoted local part of the address. +# Otherwise, \fB%u\fR is replaced by the entire search string. +# If the localpart is empty, the query is suppressed and returns +# no results. +# .IP "\fB%d\fR" +# When the input key is an address of the form user@domain, \fB%d\fR +# is replaced by the SQL quoted domain part of the address. +# Otherwise, the query is suppressed and returns no results. +# .IP "\fB%[SUD]\fR" +# The upper-case equivalents of the above expansions behave in the +# \fBquery\fR parameter identically to their lower-case counter-parts. +# With the \fBresult_format\fR parameter (see below), they expand the +# input key rather than the result value. +# .IP "\fB%[1-9]\fR" +# The patterns %1, %2, ... %9 are replaced by the corresponding +# most significant component of the input key's domain. If the +# input key is \fIuser@mail.example.com\fR, then %1 is \fBcom\fR, +# %2 is \fBexample\fR and %3 is \fBmail\fR. If the input key is +# unqualified or does not have enough domain components to satisfy +# all the specified patterns, the query is suppressed and returns +# no results. +# .RE +# .IP +# The \fBdomain\fR parameter described below limits the input +# keys to addresses in matching domains. When the \fBdomain\fR +# parameter is non-empty, SQL queries for unqualified addresses +# or addresses in non-matching domains are suppressed +# and return no results. +# +# This parameter is available with Postfix 2.2. In prior releases +# the SQL query was built from the separate parameters: +# \fBselect_field\fR, \fBtable\fR, \fBwhere_field\fR and +# \fBadditional_conditions\fR. The mapping from the old parameters +# to the equivalent query is: +# +# .nf +# SELECT [\fBselect_field\fR] +# FROM [\fBtable\fR] +# WHERE [\fBwhere_field\fR] = '%s' +# [\fBadditional_conditions\fR] +# .fi +# +# The '%s' in the \fBWHERE\fR clause expands to the escaped search string. +# With Postfix 2.2 these legacy parameters are used if the \fBquery\fR +# parameter is not specified. +# +# NOTE: DO NOT put quotes around the query parameter. +# .IP "\fBresult_format (default: \fB%s\fR)\fR" +# Format template applied to result attributes. Most commonly used +# to append (or prepend) text to the result. This parameter supports +# the following '%' expansions: +# .RS +# .IP "\fB%%\fR" +# This is replaced by a literal '%' character. +# .IP "\fB%s\fR" +# This is replaced by the value of the result attribute. When +# result is empty it is skipped. +# .IP "\fB%u\fR +# When the result attribute value is an address of the form +# user@domain, \fB%u\fR is replaced by the local part of the +# address. When the result has an empty localpart it is skipped. +# .IP "\fB%d\fR" +# When a result attribute value is an address of the form +# user@domain, \fB%d\fR is replaced by the domain part of +# the attribute value. When the result is unqualified it +# is skipped. +# .IP "\fB%[SUD1-9]\fR" +# The upper-case and decimal digit expansions interpolate +# the parts of the input key rather than the result. Their +# behavior is identical to that described with \fBquery\fR, +# and in fact because the input key is known in advance, queries +# whose key does not contain all the information specified in +# the result template are suppressed and return no results. +# .RE +# .IP +# For example, using "result_format = smtp:[%s]" allows one +# to use a mailHost attribute as the basis of a transport(5) +# table. After applying the result format, multiple values +# are concatenated as comma separated strings. The expansion_limit +# and parameter explained below allows one to restrict the number +# of values in the result, which is especially useful for maps that +# must return at most one value. +# +# The default value \fB%s\fR specifies that each result value should +# be used as is. +# +# This parameter is available with Postfix 2.2 and later. +# +# NOTE: DO NOT put quotes around the result format! +# .IP "\fBdomain (default: no domain list)\fR" +# This is a list of domain names, paths to files, or +# dictionaries. When specified, only fully qualified search +# keys with a *non-empty* localpart and a matching domain +# are eligible for lookup: 'user' lookups, bare domain lookups +# and "@domain" lookups are not performed. This can significantly +# reduce the query load on the SQLite server. +# .nf +# domain = postfix.org, hash:/etc/postfix/searchdomains +# .fi +# +# It is best not to use SQL to store the domains eligible +# for SQL lookups. +# +# This parameter is available with Postfix 2.2 and later. +# +# NOTE: DO NOT define this parameter for local(8) aliases, +# because the input keys are always unqualified. +# .IP "\fBexpansion_limit (default: 0)\fR" +# A limit on the total number of result elements returned +# (as a comma separated list) by a lookup against the map. +# A setting of zero disables the limit. Lookups fail with a +# temporary error if the limit is exceeded. Setting the +# limit to 1 ensures that lookups do not return multiple +# values. +# OBSOLETE MAIN.CF PARAMETERS +# .ad +# .fi +# For compatibility with other Postfix lookup tables, SQLite +# parameters can also be defined in main.cf. In order to do that, +# specify as SQLite source a name that doesn't begin with a slash +# or a dot. The SQLite parameters will then be accessible as the +# name you've given the source in its definition, an underscore, +# and the name of the parameter. For example, if the map is +# specified as "sqlite:\fIsqlitename\fR", the parameter "query" +# would be defined in main.cf as "\fIsqlitename\fR_query". +# OBSOLETE QUERY INTERFACE +# .ad +# .fi +# This section describes an interface that is deprecated as +# of Postfix 2.2. It is replaced by the more general \fBquery\fR +# interface described above. If the \fBquery\fR parameter +# is defined, the legacy parameters described here ignored. +# Please migrate to the new interface as the legacy interface +# may be removed in a future release. +# +# The following parameters can be used to fill in a +# SELECT template statement of the form: +# +# .nf +# SELECT [\fBselect_field\fR] +# FROM [\fBtable\fR] +# WHERE [\fBwhere_field\fR] = '%s' +# [\fBadditional_conditions\fR] +# .fi +# +# The specifier %s is replaced by the search string, and is +# escaped so if it contains single quotes or other odd characters, +# it will not cause a parse error, or worse, a security problem. +# .IP "\fBselect_field\fR" +# The SQL "select" parameter. Example: +# .nf +# \fBselect_field\fR = forw_addr +# .fi +# .IP "\fBtable\fR" +# The SQL "select .. from" table name. Example: +# .nf +# \fBtable\fR = mxaliases +# .fi +# .IP "\fBwhere_field\fR +# The SQL "select .. where" parameter. Example: +# .nf +# \fBwhere_field\fR = alias +# .fi +# .IP "\fBadditional_conditions\fR +# Additional conditions to the SQL query. Example: +# .nf +# \fBadditional_conditions\fR = AND status = 'paid' +# .fi +# SEE ALSO +# postmap(1), Postfix lookup table maintenance +# postconf(5), configuration parameters +# ldap_table(5), LDAP lookup tables +# mysql_table(5), MySQL lookup tables +# pgsql_table(5), PostgreSQL lookup tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# SQLITE_README, Postfix SQLITE howto +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# HISTORY +# SQLite support was introduced with Postfix version 2.8. +# AUTHOR(S) +# Original implementation by: +# Axel Steiner +#-- diff --git a/proto/stop b/proto/stop new file mode 100644 index 0000000..85a3d56 --- /dev/null +++ b/proto/stop @@ -0,0 +1,1539 @@ +DHCP +DNS +IMAP +IP +ISP +MX +PPP +RC +README +RFC +Sendmail's +Wietse +cdb +cf +com +db +dbm +dialup +dns +domainname +download +firewalled +generic +grep +hostname +html +http +inet +intranet +ip +isp +janes +joes +localdomain +localhost +localpart +mailhost +mailq +mydestination +mydomain +myhostname +mynetworks +myorigin +newaliases +nullclient +org +postconf +postmap +relayhost +sbin +sendmail +smtp +smtpd +smtprelay +someprovider +subdomains +tld +unauth +usr +wietse +www +Bcc +Firstname +LDAP +LINUX +LMTP +Lastname +NIS +SQL +SYSV +Venema +bangpath +firstname +hosta +hostb +lastname +ldap +lmtp +luser +mysql +nis +otherdomain +otheruser +pcre +pgsql +privs +qmgr +qmqpd +regexp +std +sysadmin +userid +username +Autoreplies +CDB +DBM +Howto +MAILDROP +MYSQL +Maildir +MySQL +PGSQL +PgSQL +Postfix's +Spammers +UID +argv +autoreplies +autoreply +berkeley +chroot +com's +hostnames +internet +jim +listname +mailBOX +mailDIRs +maildir +maildrop +majordomo +maxproc +spam +uid +unix +unpriv +var +vhosts +vmailbox +vs +wildcard +AG +AHRlc +AUTH +AUXLIBS +BITMIME +CCARGS +DUSE +Daia +EHLO +ESMTP +ETRN +Franke +FreeBSD +Hoos +Linux +Liviu +MMIME +OTP +RedHat +RwYXNz +SASL +SASL's +Solaris +Strace +SuSE +UCE +ZXN +andrew +auth +auxprop +chrooted +cmu +conf +cpan +dGVzdAB +docs +edu +elses +exampleuser +ftp +ktrace +ld +lib +lsasl +maillog +mech +metamail +mmencode +passwd +perl +plaintext +plugin +plugins +printf +pwcheck +sasl +saslauthd +sasldb +sasldblistusers +saslpasswd +sql +su +symlink +tarball +testpass +CC +CONFIG +DDEF +DEF +DFD +DIR +Debian +FD +FILIO +FIONREAD +FREEBSD +GCC +HTML +IRIX +MAILQ +MANPAGE +MANPATH +MacOSX +NEWALIAS +NEXTSTEP +NetBSD +OPENSTEP +OSF +OSX +PCRE +Perl +PostgreSQL +SENDMAIL +SETSIZE +SUNOS +SUNWspro +SYSTEMTYPE +Sendmail +Slackware +SunOS +TLS +UX +ansic +bd +bi +bp +cc +ccs +cd +chmod +config +defs +egrep +ifdef +init +libexec +lndir +logfile +logfiles +mailserver +makedefs +manpage +mantools +mv +postdrop +postprocessing +postqueue +pre +pwd +qwhatever +readme +setenv +syslog +syslogd +util +DoS +Duchovni +FF +MTA +QSHAPE +Requeing +SYN +algonet +aristotle +backoff +bbde +bcc +bitmask +cn +extremepricecuts +fr +gjr +google +gotdns +gov +gzd +heyhihellothere +highvolume +hinet +hotmail +ids +malware +meri +misconfiguring +ms +msg +msn +nexthop +osn +paknet +pk +pleazerzoneprod +postsuper +qshape +reprocessing +setgid +sourceforge +spammers +timestamp +toppoint +transport's +transportname +undeliverables +uwasa +winnersdaily +worldnet +FAQ +MB +SMTPD +args +fd +fs +helo +ipc +maxfiles +maxfilesperproc +maxsockets +nl +nmbclusters +proc +rcpts +resolv +rlim +solaris +sysctl +Ctrl +ECC +XAUTHORITY +Xauthority +anonymize +cont +csh +gdb +loopback +ltrace +oqmgr +postfinger +sotruss +strace +tcpdump +BUILTIN +SPAM +website +HELO +Mozilla +Netscape +VirusWarning +dk +dkuug +spammer +txt +wtf +PERL +Rq +TEMPFAIL +XFORWARD +inetd +rm +smtpprox +sysexits +xforward +xxx +yyy +DSN +RBL +RCPT +ehlo +proxying +SPF +Whitelisting +XCLIENT +etrn +greylisting +rfc +unreplyable +websites +whitelisting +DUNNO +Greylisting +VRFY +aol +attr +bigfoot +chown +dunno +greylist +headername +headertext +lc +mkdir +mta +neohapsis +obj +pl +pobox +securityfocus +spf +tmp +ttl +AOL +VERP +btree +interruptus +mis +sender's +whitelist +rbl +spoofing +IDs +Oct +mx +nrcpt +qRdestination +qRdomain +sdestination +sdomain +LinxNet +SSL +Sanders's +Seymour's +au +jdp +jimsun +recipien +rmail +stunnel +taz +tcp +uux +dir +foobar +pag +postalias +proxymap +BerkeleyDB +DHAS +MBytes +UNIXWARE +UNIXes +bsd +condattr +fcntl +kBytes +ldb +linux +lpthread +mutex +mutexattr +pthread +setpshared +sleepycat +trylock +DN +Guesdon +Haahtinen +Hensley +Hery +Hoeger +KTH +Kerberos +LDAPv +LaMont +Linux's +Maildrops +Mattice +OpenLDAP +Prabhat +Rakotoarisoa +SDKs +STARTTLS +Sami +Tardieu +URL +accountingstaff +dc +defaultrecipient +dirsvcs +dn +hmmmm +kerberos +ldapuser +libdns +libldap +libldapssl +llber +lldap +mailacceptinggeneralid +mailacceptinggeneralids +maildrops +maillist +mylist +normaluser +objectclass +openldap +realuser +slapd +slurpd +someserver +theother +tls +umich +virtualaccount +wildcards +IC +addr +dbname +downloads +forw +libm +libz +lm +lmysqlclient +lz +mxaliases +mysqlclient +POSIX +ac +csx +lpcre +uk +Sethman +libpq +lpq +QMQP +XVERP +cr +ezmlm +prefixuser +qmail +qmqp +verp +yourname +yp +Procmail +Syslogd +devel +procmail +MTAs +Netapp +dotlock +DECstation +NOFILE +RLIMIT +Roques +getdtablesize +getrlimit +von +zsh +DRhu +Earnshaw +Maildrop +Mosemann +Tonni +someother +userdb +vmail +bv +dest +ination +makemap +postcat +postkick +postlock +postlog +postsomething +showq +BCC +CR +Cc +Helo +LF +LHLO +LOGNAME +MicroSoft +PID +PTR +RFCs +RSET +SCO +Subdomain +TZ +YYYYMMDD +admin +ain +aliasname +bitmime +cl +dequoted +faqs +fetchmail +fqdn +gethostbyname +gethostname +hopcount +hostaddress +ient +ifconfig +ish +lhlo +localparts +lockfile +mailtool +minfree +multipart +mydom +mysmtp +netmask +noactive +noanonymous +nodictionary +noplaintext +ns +nsswitch +octets +partialdomainname +patchlevel +pid +provider's +rcpt +relayhostname +ress +rfcs +rhsbl +rset +sendmail's +servername +smrsh +spams +ss +subdomain +uucphost +vrfy +xclient +xfer +ipaddress +gz +gzip +outputfile +umask +xargs +xvpf +Patrik +Rak +Rak's +emails +nqmgr +AAE +ADDR +CF +IPV +IPv +MTA's +SP +TEMPUNAVAIL +xtext +CIDR +FQDN +Hildebrandt +OpenBSD +Pflogsumm +Pflogsumm's +Zeikat +cidr +faq +howto +linxnet +mailhub +mpack +nt +pflogg +pflogsumm +recipie +spoofed +ACK +Ac +BDFORhqu +BSMTP +DNs +DOTALL +Dtv +Dv +ENDONLY +EOF +Fpath +Fsome +Gouaux +IFRAME +INET +INT +IPC +Idem +Jozsef +KFKI +Kadlecsik +MAILDIR +MC +MULTILINE +McNamara +Mirapoint +Modra +NN +NSW +NY +Nfinoprvw +ONELEVEL +OQMGR +OpenSSL +PEM +POSTALIAS +POSTCAT +POSTCONF +POSTDROP +POSTKICK +POSTLOCK +POSTLOG +POSTMAP +POSTQUEUE +POSTSUPER +PROXYMAP +Prindeville +Pty +QMAIL +QMGR +QMQPD +REGEXP +REQ +ROMANIA +RS +Requeue +SHOWQ +SIGHUP +SIGTERM +TARPIT +TX +URLs +Vxy +alnum +andrewm +awk +bH +bh +blackhole +bm +bs +cert +checkpointed +cid +cv +debuglevel +dhmlnv +dsn +eb +eef +ef +endif +eoctal +eol +ev +exe +exploders +fq +groupname +headervalue +hp +hqu +hu +ident +idx +iframe +inode +inputfile +kadlec +kfki +lamont +ldapi +ldaps +ldapsearch +ldapsource +localname +mailHost +mapname +maptype +metacharacter +metacharacters +mysqlname +netstring +oA +oAalias +oi +pgsqlname +postfixpw +psv +pw +qR +qRsite +qSsite +qinterval +queueid +regcomp +regex +requeue +requeued +requeues +rv +searchdomains +sitename +src +sytem +textfile +tr +unzip +usernames +vbs +vq +CERT +NOQUEUE +NS +Qmail +Tarpit +Verisign +Verisign's +dd +itd +AU +CAcert +CAfile +CApath +CAs +CNAME +CommonName +Cottbus +DH +DSA +EE +EGD +GMT +IA +Lutz +Lutz's +NOPEERMATCH +Nov +OPENSSL +PRNG +PosgreSQL +RSA +SubjectAlternativeName +Uing +Widgits +Wietse's +aet +cacert +ccert +certs +cipherlist +clientcerts +cnf +commonName +compat +cottbus +countryName +cp +dNSNames +dcert +demoCA +dh +dkey +dsa +eg +egd +emailAddress +exch +fifos +gendh +infiles +kbytes +keyout +lcrypto +libcrypto +libssl +localityName +loglevel +lssl +lutzpc +misc +newca +nicke +ok +openssl +organizationName +peername +pem +prng +req +scache +scert +sdbm +smtps +ssl +sslclient +sslserver +starttls +stateOrProvinceName +tlsmgr +unencrypted +unpassworded +urandom +verifydepth +wrappermode +AAAA +DNSBL +GETIFADDRS +Hagino +Huizer +Jaenicke's +Lutz +PLD +SIOCGIF +SIOCGLIF +Strik +Strik's +Tru +USAGI +compat +ff +ffff +getifaddrs +ichiro +ifndef +ipnet +ipv +itojun +netmasks +kluges +APPENDDEF +EOH +EOM +MSGIDUNKNOWN +Milters +SMFIS +SenderID +authen +confINCDIRS +confLIBDIRS +ctx +dnl +eoh +eom +getpriv +getsymval +gzcat +jobid +libmilter +ments +milters +mlfi +msgid +optionneg +portnumber +ptr +sid +smfi +smfilter +strcmp +tempfail +vx +wich +xf +xxxxx +yy +zz +AAAREADME +API +DAEMONs +DHE +DSL +DataBase +EMSTP +EST +HTTPS +JOBIDUNKNOWN +Jänicke +Koetter +Leandro +MSA +MUAs +Netinfo +ODRhu +Outlook's +PQexec +Procontrol +REJECTs +Requeuing +SDBM +SSLv +Santi +Sirainen +TCL +TEMPFAILs +TLSv +Tallon +Tinycdb +Tokarev +Wrobel +aNULL +agroup +alloc +antiantivirus +apps +arandom +arounds +auser +beb +bgroup +buser +callouts +cctx +cli +cname +corpit +cuser +ddd +dfc +dkim +dmS +domainkeys +duser +epoll +esmtp +exim +gssapi +heraccount +herisp +hisaccount +hisisp +ietf +imc +interoperate +keysize +koetter +kqueue +ldapgroup +libcdb +libdb +lpr +mailwrapper +mctx +memberaddr +memberdn +mjt +mlm +msa +myisp +myname +netinfo +nisplus +noatime +nopeer +obs +openspf +orig +passdb +patrick +preloading +rpm +saslfinger +securetls +spamware +systemtype +tinycdb +unencoded +uniquename +william +xxxxxxx +yulszqocfzsficvzzju +yyyyyy +zzzzzz +BC +DKIM +DomainKeys +Hmm +Jnicke +QAdGVzdHBhc +RBL's +RBLs +RST +SMTPS +Spamhaus +Ss +Ubuntu +blocklists +botnet +botnets +bx +cb +co +dest +foreach +int +jp +le +mind's +nqmgr's +overinflating +portscan +preemptions +ps +qf +refcount +ru +spamhaus +stddev +sysadmins +timeline +todo +tt +unsubscribe +wl +zen +Blocklist +DNSBLs +MailChannels +Postscreen +Spambots +WHITELISTED +blocklist +dnsbl +dnsblog +postscreen +postscreen's +spambots +spamd +texthash +ul +whitelisted +whitelists +Amavisd +MUA +Mailserver +SpamAssassin +barracudacentral +bl +spamcop +tlsproxy +AEIOUaeiou +AF +ASN +BB +CB +CBC +CRYPTOPRO +CTX +CVE +DER +DES +DNSSEC +Diffie +EC +ECDH +ECDSA +EDNS +EECDH +FB +GOST +Hellman +LMDB +MSIE +Mmm +NODATA +NXDOMAIN +Nexthop +OP +OTIFY +OpenSSL's +Postix +Pt +SECG +SSLEAY +SSLREF +SSLV +TLSEXT +VXxznjll +Whitelist +XYZ +YYYYMMDDHHMMSS +aRSA +authcid +authcid's +authentiCation +authoriZation +authzid +bc +blockquote +certfile +cfm +cipherlists +ciphertext +crypto +dane +defnames +dgst +dl +dnsrch +dnssec +dnswl +dotcrlf +dt +eNULL +eccert +ecdsa +eckey +ecparam +eecdh +fc +fixup +getaddrinfo +haproxy +headerbody +hh +hyperlinked +ia +kEDH +lmdb +localtime +mN +matchlists +md +mechs +memcache +mylmtp +nginx +noout +nsa +pkey +postlink +postmulti +proxywrite +pubin +pubkey +queueID +rsa +secp +stdin +tarpit +uncached +unzipping +windowsize +xpostconf +TLSA +tafile +VPN +Dukhovni +Exim +NIST +PFS +Snowden +Viktor +XP +cron +dhparam +inadvisably +ADH +AECDH +CN +DSS +ECDHE +GCM +Jnicke's +Kx +PKI +XXX +YYY +ZZZ +kEECDH +EXIM +DLV +IANA +RRs +RRset +RRsets +SNI +tlsa +TSIG +ciphersuite +ciphersuites +nlnetlabs +resolver's +tempfails +Chu +LMDB's +NDBM +dict +kbyte +llmdb +lockfiles +slmdb +DEVPOLL +DNO +EPOLL +GETPW +KQUEUE +MacOS +NISPLUS +SHLIB +SIGSETJMP +SQLITE +SQLite +deinstalling +dynamicmaps +gcc +getpwnam +getpwuid +ldconfig +libpostfix +longjmp +nonprod +setjmp +shlib +siglongjmp +sigsetjmp +sqlite +unversioned +versioned +DNSWL +cbc +ADDRCPT +Ae +AES +Arnt +ASLR +authz +authzTo +autodetect +autodetection +backend +backends +backscatter +BACKSCATTER +balancer +byname +cakey +casefold +casefolding +caseless +Centos +CFLAGS +changetype +characterset +CHGFROM +cmusaslsecretMECHNAME +CNNIC +concurrencies +cryptanalytic +cryptographic +cryptographically +customizations +cyrus +DB's +de +decrypts +deinstall +dev +DMARC +EAI +EDH +encodings +ENHANCEDSTATUSCODES +environ +esac +etcetera +exchanger +executables +Executables +filename +filenames +fPIC +fred +genrsa +GSSAPI +Gulbrandsen +Gulbrandsen's +helpdesk +icu +icuuc +imap +infeasible +interoperability +interoperable +invasiveness +jetmore +Jetmore +KERBEROS +kern +launchd +ldapadd +ldapdb +ldapmodify +libc +libicu +liblogin +libplain +libsasl +libsasl's +login +Login +LOGIN +logins +lookup +Lookup +lookups +Makefile +makefiles +Makefiles +mary +matcher +maxprocperuid +mdash +MECHNAME +Memcache +Mf +milter +Milter +misconfigured +multi +mux +namen +nameserver +nameserver's +ndash +ne +newkey +nicke's +NOOP +nroff +ntlm +NTLM +Ok +opendkim +OpenDKIM +OpenDMARC +optimizations +ou +outform +pam +param +pathname +pathnames +performant +pipelined +pipelining +PIPELINING +pipemap +Plaintext +postfix +Postfix +POSTSCREEN +Pre +prepend +PREPEND +PROTO +proxyuser +randmap +rc +REJ +REPLBODY +resultn +Rhein +RHEL +rimap +rpath +RPATH +runpath +runtime +SASLv +scalable +scanf +sha +SHA +SMFIC +SMFIP +SMFIR +SMTP +smtputf +SMTPUTF +socketdir +socketmap +startup +subdirectory +subnet +subnetworks +substring +sys +SYS +sysconfig +TCP +testsaslauthd +Timo +tradeoff +typechecks +typen +ulimit +undeliverable +Unencrypted +unionmap +uniqueIdentifier +unpatched +untrusted +Untrusted +unvailable +uri +userPassword +UTF +uucp +UUCP +wakeup +Westchester +whitespace +Wl +xFFFFFFFF +xn +xyy +xzz +ymd +INLINE +SNPRINTF +inline +mtime +snprintf +sprintf diff --git a/proto/tcp_table b/proto/tcp_table new file mode 100644 index 0000000..d1ddb81 --- /dev/null +++ b/proto/tcp_table @@ -0,0 +1,108 @@ +#++ +# NAME +# tcp_table 5 +# SUMMARY +# Postfix client/server table lookup protocol +# SYNOPSIS +# \fBpostmap -q "\fIstring\fB" tcp:\fIhost:port\fR +# +# \fBpostmap -q - tcp:\fIhost:port\fB <\fIinputfile\fR +# DESCRIPTION +# The Postfix mail system uses optional tables for address +# rewriting or mail routing. These tables are usually in +# \fBdbm\fR or \fBdb\fR format. Alternatively, table lookups +# can be directed to a TCP server. +# +# To find out what types of lookup tables your Postfix system +# supports use the "\fBpostconf -m\fR" command. +# +# To test lookup tables, use the "\fBpostmap -q\fR" command as +# described in the SYNOPSIS above. +# PROTOCOL DESCRIPTION +# .ad +# .fi +# The TCP map class implements a very simple protocol: the client +# sends a request, and the server sends one reply. Requests and +# replies are sent as one line of ASCII text, terminated by the +# ASCII newline character. Request and reply parameters (see below) +# are separated by whitespace. +# +# Send and receive operations must complete in 100 seconds. +# REQUEST FORMAT +# .ad +# .fi +# The tcp_table protocol supports only the lookup request. +# The request has the following form: +# .IP "\fBget\fR SPACE \fIkey\fR NEWLINE" +# Look up data under the specified key. +# .PP +# Postfix will not generate partial search keys such as domain +# names without one or more subdomains, network addresses +# without one or more least-significant octets, or email +# addresses without the localpart, address extension or domain +# portion. This behavior is also found with cidr:, pcre:, and +# regexp: tables. +# REPLY FORMAT +# .ad +# .fi +# Each reply specifies a status code and text. Replies must be no +# longer than 4096 characters including the newline terminator. +# .IP "\fB500\fR SPACE \fItext\fR NEWLINE" +# In case of a lookup request, the requested data does not exist. +# The text describes the nature of the problem. +# .IP "\fB400\fR SPACE \fItext\fR NEWLINE" +# This indicates an error condition. The text describes the nature of +# the problem. The client should retry the request later. +# .IP "\fB200\fR SPACE \fItext\fR NEWLINE" +# The request was successful. In the case of a lookup request, +# the text contains an encoded version of the requested data. +# ENCODING +# .ad +# .fi +# In request and reply parameters, the character %, each non-printing +# character, and each whitespace character must be replaced by %XX, +# where XX is the corresponding ASCII hexadecimal character value. The +# hexadecimal codes can be specified in any case (upper, lower, mixed). +# +# The Postfix client always encodes a request. +# The server may omit the encoding as long as the reply +# is guaranteed to not contain the % or NEWLINE character. +# SECURITY +# .ad +# .fi +# Do not use TCP lookup tables for security critical purposes. +# The client-server connection is not protected and the server +# is not authenticated. +# BUGS +# Only the lookup method is currently implemented. +# +# The client does not hang up when the connection is idle for +# a long time. +# SEE ALSO +# postmap(1), Postfix lookup table manager +# regexp_table(5), format of regular expression tables +# pcre_table(5), format of PCRE tables +# cidr_table(5), format of CIDR tables +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# DATABASE_README, Postfix lookup table overview +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#--*/ diff --git a/proto/transport b/proto/transport new file mode 100644 index 0000000..be07711 --- /dev/null +++ b/proto/transport @@ -0,0 +1,289 @@ +#++ +# NAME +# transport 5 +# SUMMARY +# Postfix transport table format +# SYNOPSIS +# \fBpostmap /etc/postfix/transport\fR +# +# \fBpostmap -q "\fIstring\fB" /etc/postfix/transport\fR +# +# \fBpostmap -q - /etc/postfix/transport <\fIinputfile\fR +# DESCRIPTION +# The optional \fBtransport\fR(5) table specifies a mapping from email +# addresses to message delivery transports and next-hop destinations. +# Message delivery transports such as \fBlocal\fR or \fBsmtp\fR +# are defined in the \fBmaster.cf\fR file, and next-hop +# destinations are typically hosts or domain names. The +# table is searched by the \fBtrivial-rewrite\fR(8) daemon. +# +# This mapping overrides the default \fItransport\fR:\fInexthop\fR +# selection that is built into Postfix: +# .IP "\fBlocal_transport (default: local:$myhostname)\fR" +# This is the default for final delivery to domains listed +# with \fBmydestination\fR, and for [\fIipaddress\fR] +# destinations that match \fB$inet_interfaces\fR or +# \fB$proxy_interfaces\fR. The default \fInexthop\fR destination +# is the MTA hostname. +# .IP "\fBvirtual_transport (default: virtual:)\fR" +# This is the default for final delivery to domains listed +# with \fBvirtual_mailbox_domains\fR. The default \fInexthop\fR +# destination is the recipient domain. +# .IP "\fBrelay_transport (default: relay:)\fR" +# This is the default for remote delivery to domains listed +# with \fBrelay_domains\fR. In order of decreasing precedence, +# the \fInexthop\fR destination is taken from \fBrelay_transport\fR, +# \fBsender_dependent_relayhost_maps\fR, \fBrelayhost\fR, or from the +# recipient domain. +# .IP "\fBdefault_transport (default: smtp:)\fR" +# This is the default for remote delivery to other destinations. +# In order of decreasing precedence, the \fInexthop\fR +# destination is taken from \fBsender_dependent_default_transport_maps, +# \fBdefault_transport\fR, \fBsender_dependent_relayhost_maps\fR, +# \fBrelayhost\fR, or from the recipient domain. +# .PP +# Normally, the \fBtransport\fR(5) table is specified as a text file +# that serves as input to the \fBpostmap\fR(1) command. +# The result, an indexed file in \fBdbm\fR or \fBdb\fR format, is used +# for fast searching by the mail system. Execute the command +# "\fBpostmap /etc/postfix/transport\fR" to rebuild an indexed +# file after changing the corresponding transport table. +# +# When the table is provided via other means such as NIS, LDAP +# or SQL, the same lookups are done as for ordinary indexed files. +# +# Alternatively, the table can be provided as a regular-expression +# map where patterns are given as regular expressions, or lookups +# can be directed to TCP-based server. In those case, the lookups +# are done in a slightly different way as described below under +# "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES". +# CASE FOLDING +# .ad +# .fi +# The search string is folded to lowercase before database +# lookup. As of Postfix 2.3, the search string is not case +# folded with database types such as regexp: or pcre: whose +# lookup fields can match both upper and lower case. +# TABLE FORMAT +# .ad +# .fi +# The input format for the \fBpostmap\fR(1) command is as follows: +# .IP "\fIpattern result\fR" +# When \fIpattern\fR matches the recipient address or domain, use the +# corresponding \fIresult\fR. +# .IP "blank lines and comments" +# Empty lines and whitespace-only lines are ignored, as +# are lines whose first non-whitespace character is a `#'. +# .IP "multi-line text" +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# .PP +# The \fIpattern\fR specifies an email address, a domain name, or +# a domain name hierarchy, as described in section "TABLE LOOKUP". +# +# The \fIresult\fR is of the form \fItransport:nexthop\fR and +# specifies how or where to deliver mail. This is described in +# section "RESULT FORMAT". +# TABLE SEARCH ORDER +# .ad +# .fi +# With lookups from indexed files such as DB or DBM, or from networked +# tables such as NIS, LDAP or SQL, patterns are tried in the order as +# listed below: +# .IP "\fIuser+extension@domain transport\fR:\fInexthop\fR" +# Deliver mail for \fIuser+extension@domain\fR through +# \fItransport\fR to +# \fInexthop\fR. +# .IP "\fIuser@domain transport\fR:\fInexthop\fR" +# Deliver mail for \fIuser@domain\fR through \fItransport\fR to +# \fInexthop\fR. +# .IP "\fIdomain transport\fR:\fInexthop\fR" +# Deliver mail for \fIdomain\fR through \fItransport\fR to +# \fInexthop\fR. +# .IP "\fI.domain transport\fR:\fInexthop\fR" +# Deliver mail for any subdomain of \fIdomain\fR through +# \fItransport\fR to \fInexthop\fR. This applies only when the +# string \fBtransport_maps\fR is not listed in the +# \fBparent_domain_matches_subdomains\fR configuration setting. +# Otherwise, a domain name matches itself and its subdomains. +# .IP "\fB*\fI transport\fR:\fInexthop\fR" +# The special pattern \fB*\fR represents any address (i.e. it +# functions as the wild-card pattern, and is unique to Postfix +# transport tables). +# .PP +# Note 1: the null recipient address is looked up as +# \fB$empty_address_recipient\fR@\fB$myhostname\fR (default: +# mailer-daemon@hostname). +# +# Note 2: \fIuser@domain\fR or \fIuser+extension@domain\fR +# lookup is available in Postfix 2.0 and later. +# RESULT FORMAT +# .ad +# .fi +# The lookup result is of the form \fItransport\fB:\fInexthop\fR. +# The \fItransport\fR field specifies a mail delivery transport +# such as \fBsmtp\fR or \fBlocal\fR. The \fInexthop\fR field +# specifies where and how to deliver mail. +# +# The transport field specifies the name of a mail delivery transport +# (the first name of a mail delivery service entry in the Postfix +# \fBmaster.cf\fR file). +# +# The interpretation of the nexthop field is transport +# dependent. In the case of SMTP, specify a service on a non-default +# port as \fIhost\fR:\fIservice\fR, and disable MX (mail exchanger) +# DNS lookups with [\fIhost\fR] or [\fIhost\fR]:\fIport\fR. The [] form +# is required when you specify an IP address instead of a hostname. +# +# A null \fItransport\fR and null \fInexthop\fR result means "do +# not change": use the delivery transport and nexthop information +# that would be used when the entire transport table did not exist. +# +# A non-null \fItransport\fR field with a null \fInexthop\fR field +# resets the nexthop information to the recipient domain. +# +# A null \fItransport\fR field with non-null \fInexthop\fR field +# does not modify the transport information. +# EXAMPLES +# .ad +# .fi +# In order to deliver internal mail directly, while using a +# mail relay for all other mail, specify a null entry for +# internal destinations (do not change the delivery transport or +# the nexthop information) and specify a wildcard for all other +# destinations. +# +# .nf +# \fB\&my.domain :\fR +# \fB\&.my.domain :\fR +# \fB* smtp:outbound-relay.my.domain\fR +# .fi +# +# In order to send mail for \fBexample.com\fR and its subdomains +# via the \fBuucp\fR transport to the UUCP host named \fBexample\fR: +# +# .nf +# \fBexample.com uucp:example\fR +# \fB\&.example.com uucp:example\fR +# .fi +# +# When no nexthop host name is specified, the destination domain +# name is used instead. For example, the following directs mail for +# \fIuser\fR@\fBexample.com\fR via the \fBslow\fR transport to a mail +# exchanger for \fBexample.com\fR. The \fBslow\fR transport could be +# configured to run at most one delivery process at a time: +# +# .nf +# \fBexample.com slow:\fR +# .fi +# +# When no transport is specified, Postfix uses the transport that +# matches the address domain class (see DESCRIPTION +# above). The following sends all mail for \fBexample.com\fR and its +# subdomains to host \fBgateway.example.com\fR: +# +# .nf +# \fBexample.com :[gateway.example.com]\fR +# \fB\&.example.com :[gateway.example.com]\fR +# .fi +# +# In the above example, the [] suppress MX lookups. +# This prevents mail routing loops when your machine is primary MX +# host for \fBexample.com\fR. +# +# In the case of delivery via SMTP, one may specify +# \fIhostname\fR:\fIservice\fR instead of just a host: +# +# .nf +# \fBexample.com smtp:bar.example:2025\fR +# .fi +# +# This directs mail for \fIuser\fR@\fBexample.com\fR to host \fBbar.example\fR +# port \fB2025\fR. Instead of a numerical port a symbolic name may be +# used. Specify [] around the hostname if MX lookups must be disabled. +# +# The error mailer can be used to bounce mail: +# +# .nf +# \fB\&.example.com error:mail for *.example.com is not deliverable\fR +# .fi +# +# This causes all mail for \fIuser\fR@\fIanything\fB.example.com\fR +# to be bounced. +# REGULAR EXPRESSION TABLES +# .ad +# .fi +# This section describes how the table lookups change when the table +# is given in the form of regular expressions. For a description of +# regular expression lookup table syntax, see \fBregexp_table\fR(5) +# or \fBpcre_table\fR(5). +# +# Each pattern is a regular expression that is applied to the entire +# address being looked up. Thus, \fIsome.domain.hierarchy\fR is not +# looked up via its parent domains, +# nor is \fIuser+foo@domain\fR looked up as \fIuser@domain\fR. +# +# Patterns are applied in the order as specified in the table, until a +# pattern is found that matches the search string. +# +# The \fBtrivial-rewrite\fR(8) server disallows regular +# expression substitution of $1 etc. in regular expression +# lookup tables, because that could open a security hole +# (Postfix version 2.3 and later). +# TCP-BASED TABLES +# .ad +# .fi +# This section describes how the table lookups change when lookups +# are directed to a TCP-based server. For a description of the TCP +# client/server lookup protocol, see \fBtcp_table\fR(5). +# This feature is not available up to and including Postfix version 2.4. +# +# Each lookup operation uses the entire recipient address once. Thus, +# \fIsome.domain.hierarchy\fR is not looked up via its parent domains, +# nor is \fIuser+foo@domain\fR looked up as \fIuser@domain\fR. +# +# Results are the same as with indexed file lookups. +# CONFIGURATION PARAMETERS +# .ad +# .fi +# The following \fBmain.cf\fR parameters are especially relevant. +# The text below provides only a parameter summary. See +# \fBpostconf\fR(5) for more details including examples. +# .IP \fBempty_address_recipient\fR +# The address that is looked up instead of the null sender address. +# .IP \fBparent_domain_matches_subdomains\fR +# List of Postfix features that use \fIdomain.tld\fR patterns +# to match \fIsub.domain.tld\fR (as opposed to +# requiring \fI.domain.tld\fR patterns). +# .IP \fBtransport_maps\fR +# List of transport lookup tables. +# SEE ALSO +# trivial-rewrite(8), rewrite and resolve addresses +# master(5), master.cf file format +# postconf(5), configuration parameters +# postmap(1), Postfix lookup table manager +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# ADDRESS_REWRITING_README, address rewriting guide +# DATABASE_README, Postfix lookup table overview +# FILTER_README, external content filter +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- diff --git a/proto/virtual b/proto/virtual new file mode 100644 index 0000000..8f04732 --- /dev/null +++ b/proto/virtual @@ -0,0 +1,302 @@ +#++ +# NAME +# virtual 5 +# SUMMARY +# Postfix virtual alias table format +# SYNOPSIS +# \fBpostmap /etc/postfix/virtual\fR +# +# \fBpostmap -q "\fIstring\fB" /etc/postfix/virtual\fR +# +# \fBpostmap -q - /etc/postfix/virtual <\fIinputfile\fR +# DESCRIPTION +# The optional \fBvirtual\fR(5) alias table rewrites recipient +# addresses for all local, all virtual, and all remote mail +# destinations. +# This is unlike the \fBaliases\fR(5) table which is used +# only for \fBlocal\fR(8) delivery. Virtual aliasing is +# recursive, and is implemented by the Postfix \fBcleanup\fR(8) +# daemon before mail is queued. +# +# The main applications of virtual aliasing are: +# .IP \(bu +# To redirect mail for one address to one or more addresses. +# .IP \(bu +# To implement virtual alias domains where all addresses are aliased +# to addresses in other domains. +# .sp +# Virtual alias domains are not to be confused with the virtual mailbox +# domains that are implemented with the Postfix \fBvirtual\fR(8) mail +# delivery agent. With virtual mailbox domains, each recipient address +# can have its own mailbox. +# .PP +# Virtual aliasing is applied only to recipient +# envelope addresses, and does not affect message headers. +# Use \fBcanonical\fR(5) +# mapping to rewrite header and envelope addresses in general. +# +# Normally, the \fBvirtual\fR(5) alias table is specified as a text file +# that serves as input to the \fBpostmap\fR(1) command. +# The result, an indexed file in \fBdbm\fR or \fBdb\fR format, +# is used for fast searching by the mail system. Execute the command +# "\fBpostmap /etc/postfix/virtual\fR" to rebuild an indexed +# file after changing the corresponding text file. +# +# When the table is provided via other means such as NIS, LDAP +# or SQL, the same lookups are done as for ordinary indexed files. +# +# Alternatively, the table can be provided as a regular-expression +# map where patterns are given as regular expressions, or lookups +# can be directed to TCP-based server. In those case, the lookups +# are done in a slightly different way as described below under +# "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES". +# CASE FOLDING +# .ad +# .fi +# The search string is folded to lowercase before database +# lookup. As of Postfix 2.3, the search string is not case +# folded with database types such as regexp: or pcre: whose +# lookup fields can match both upper and lower case. +# TABLE FORMAT +# .ad +# .fi +# The input format for the \fBpostmap\fR(1) command is as follows: +# .IP "\fIpattern address, address, ...\fR" +# When \fIpattern\fR matches a mail address, replace it by the +# corresponding \fIaddress\fR. +# .IP "blank lines and comments" +# Empty lines and whitespace-only lines are ignored, as +# are lines whose first non-whitespace character is a `#'. +# .IP "multi-line text" +# A logical line starts with non-whitespace text. A line that +# starts with whitespace continues a logical line. +# TABLE SEARCH ORDER +# .ad +# .fi +# With lookups from indexed files such as DB or DBM, or from networked +# tables such as NIS, LDAP or SQL, each \fIuser\fR@\fIdomain\fR +# query produces a sequence of query patterns as described below. +# +# Each query pattern is sent to each specified lookup table +# before trying the next query pattern, until a match is +# found. +# .IP "\fIuser\fR@\fIdomain address, address, ...\fR" +# Redirect mail for \fIuser\fR@\fIdomain\fR to \fIaddress\fR. +# This form has the highest precedence. +# .IP "\fIuser address, address, ...\fR" +# Redirect mail for \fIuser\fR@\fIsite\fR to \fIaddress\fR when +# \fIsite\fR is equal to $\fBmyorigin\fR, when \fIsite\fR is listed in +# $\fBmydestination\fR, or when it is listed in $\fBinet_interfaces\fR +# or $\fBproxy_interfaces\fR. +# .sp +# This functionality overlaps with functionality of the local +# \fIaliases\fR(5) database. The difference is that \fBvirtual\fR(5) +# mapping can be applied to non-local addresses. +# .IP "@\fIdomain address, address, ...\fR" +# Redirect mail for other users in \fIdomain\fR to \fIaddress\fR. +# This form has the lowest precedence. +# .sp +# Note: @\fIdomain\fR is a wild-card. With this form, the +# Postfix SMTP server accepts +# mail for any recipient in \fIdomain\fR, regardless of whether +# that recipient exists. This may turn your mail system into +# a backscatter source: Postfix first accepts mail for +# non-existent recipients and then tries to return that mail +# as "undeliverable" to the often forged sender address. +# .sp +# To avoid backscatter with mail for a wild-card domain, +# replace the wild-card mapping with explicit 1:1 mappings, +# or add a reject_unverified_recipient restriction for that +# domain: +# +# .nf +# smtpd_recipient_restrictions = +# ... +# reject_unauth_destination +# check_recipient_access +# inline:{example.com=reject_unverified_recipient} +# unverified_recipient_reject_code = 550 +#.fi +# +# In the above example, Postfix may contact a remote server +# if the recipient is aliased to a remote address. +# RESULT ADDRESS REWRITING +# .ad +# .fi +# The lookup result is subject to address rewriting: +# .IP \(bu +# When the result has the form @\fIotherdomain\fR, the +# result becomes the same \fIuser\fR in \fIotherdomain\fR. +# This works only for the first address in a multi-address +# lookup result. +# .IP \(bu +# When "\fBappend_at_myorigin=yes\fR", append "\fB@$myorigin\fR" +# to addresses without "@domain". +# .IP \(bu +# When "\fBappend_dot_mydomain=yes\fR", append +# "\fB.$mydomain\fR" to addresses without ".domain". +# ADDRESS EXTENSION +# .fi +# .ad +# When a mail address localpart contains the optional recipient delimiter +# (e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes: +# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR, +# \fIuser\fR, and @\fIdomain\fR. +# +# The \fBpropagate_unmatched_extensions\fR parameter controls whether +# an unmatched address extension (\fI+foo\fR) is propagated to the +# result of table lookup. +# VIRTUAL ALIAS DOMAINS +# .ad +# .fi +# Besides virtual aliases, the virtual alias table can also be used +# to implement virtual alias domains. With a virtual alias domain, all +# recipient addresses are aliased to addresses in other domains. +# +# Virtual alias domains are not to be confused with the virtual mailbox +# domains that are implemented with the Postfix \fBvirtual\fR(8) mail +# delivery agent. With virtual mailbox domains, each recipient address +# can have its own mailbox. +# +# With a virtual alias domain, the virtual domain has its +# own user name space. Local (i.e. non-virtual) usernames are not +# visible in a virtual alias domain. In particular, local +# \fBaliases\fR(5) and local mailing lists are not visible as +# \fIlocalname@virtual-alias.domain\fR. +# +# Support for a virtual alias domain looks like: +# +# .nf +# /etc/postfix/main.cf: +# virtual_alias_maps = hash:/etc/postfix/virtual +# .fi +# +# Note: some systems use \fBdbm\fR databases instead of \fBhash\fR. +# See the output from "\fBpostconf -m\fR" for available database types. +# +# .nf +# /etc/postfix/virtual: +# \fIvirtual-alias.domain anything\fR (right-hand content does not matter) +# \fIpostmaster@virtual-alias.domain postmaster\fR +# \fIuser1@virtual-alias.domain address1\fR +# \fIuser2@virtual-alias.domain address2, address3\fR +# .fi +# .sp +# The \fIvirtual-alias.domain anything\fR entry is required for a +# virtual alias domain. \fBWithout this entry, mail is rejected +# with "relay access denied", or bounces with +# "mail loops back to myself".\fR +# +# Do not specify virtual alias domain names in the \fBmain.cf +# mydestination\fR or \fBrelay_domains\fR configuration parameters. +# +# With a virtual alias domain, the Postfix SMTP server +# accepts mail for \fIknown-user@virtual-alias.domain\fR, and rejects +# mail for \fIunknown-user\fR@\fIvirtual-alias.domain\fR as undeliverable. +# +# Instead of specifying the virtual alias domain name via +# the \fBvirtual_alias_maps\fR table, you may also specify it via +# the \fBmain.cf virtual_alias_domains\fR configuration parameter. +# This latter parameter uses the same syntax as the \fBmain.cf +# mydestination\fR configuration parameter. +# REGULAR EXPRESSION TABLES +# .ad +# .fi +# This section describes how the table lookups change when the table +# is given in the form of regular expressions. For a description of +# regular expression lookup table syntax, see \fBregexp_table\fR(5) +# or \fBpcre_table\fR(5). +# +# Each pattern is a regular expression that is applied to the entire +# address being looked up. Thus, \fIuser@domain\fR mail addresses are not +# broken up into their \fIuser\fR and \fI@domain\fR constituent parts, +# nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. +# +# Patterns are applied in the order as specified in the table, until a +# pattern is found that matches the search string. +# +# Results are the same as with indexed file lookups, with +# the additional feature that parenthesized substrings from the +# pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on. +# TCP-BASED TABLES +# .ad +# .fi +# This section describes how the table lookups change when lookups +# are directed to a TCP-based server. For a description of the TCP +# client/server lookup protocol, see \fBtcp_table\fR(5). +# This feature is not available up to and including Postfix version 2.4. +# +# Each lookup operation uses the entire address once. Thus, +# \fIuser@domain\fR mail addresses are not broken up into their +# \fIuser\fR and \fI@domain\fR constituent parts, nor is +# \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. +# +# Results are the same as with indexed file lookups. +# BUGS +# The table format does not understand quoting conventions. +# CONFIGURATION PARAMETERS +# .ad +# .fi +# The following \fBmain.cf\fR parameters are especially relevant to +# this topic. See the Postfix \fBmain.cf\fR file for syntax details +# and for default values. Use the "\fBpostfix reload\fR" command after +# a configuration change. +# .IP "\fBvirtual_alias_maps ($virtual_maps)\fR" +# Optional lookup tables that alias specific mail addresses or domains +# to other local or remote address. +# .IP "\fBvirtual_alias_domains ($virtual_alias_maps)\fR" +# Postfix is final destination for the specified list of virtual +# alias domains, that is, domains for which all addresses are aliased +# to addresses in other local or remote domains. +# .IP "\fBpropagate_unmatched_extensions (canonical, virtual)\fR" +# What address lookup tables copy an address extension from the lookup +# key to the lookup result. +# .PP +# Other parameters of interest: +# .IP "\fBinet_interfaces (all)\fR" +# The network interface addresses that this mail system receives +# mail on. +# .IP "\fBmydestination ($myhostname, localhost.$mydomain, localhost)\fR" +# The list of domains that are delivered via the $local_transport +# mail delivery transport. +# .IP "\fBmyorigin ($myhostname)\fR" +# The domain name that locally-posted mail appears to come +# from, and that locally posted mail is delivered to. +# .IP "\fBowner_request_special (yes)\fR" +# Enable special treatment for owner-\fIlistname\fR entries in the +# \fBaliases\fR(5) file, and don't split owner-\fIlistname\fR and +# \fIlistname\fR-request address localparts when the recipient_delimiter +# is set to "-". +# .IP "\fBproxy_interfaces (empty)\fR" +# The network interface addresses that this mail system receives mail +# on by way of a proxy or network address translation unit. +# SEE ALSO +# cleanup(8), canonicalize and enqueue mail +# postmap(1), Postfix lookup table manager +# postconf(5), configuration parameters +# canonical(5), canonical address mapping +# README FILES +# .ad +# .fi +# Use "\fBpostconf readme_directory\fR" or +# "\fBpostconf html_directory\fR" to locate this information. +# .na +# .nf +# ADDRESS_REWRITING_README, address rewriting guide +# DATABASE_README, Postfix lookup table overview +# VIRTUAL_README, domain hosting guide +# LICENSE +# .ad +# .fi +# The Secure Mailer license must be distributed with this software. +# AUTHOR(S) +# Wietse Venema +# IBM T.J. Watson Research +# P.O. Box 704 +# Yorktown Heights, NY 10598, USA +# +# Wietse Venema +# Google, Inc. +# 111 8th Avenue +# New York, NY 10011, USA +#-- -- cgit v1.2.3