From: Wietse Venema Date: Mon, 8 Feb 2010 05:00:00 +0000 (-0500) Subject: postfix-2.8-20100208 X-Git-Tag: v2.8.0-RC1~41 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bde0246003b3d8c8368fee40869fe9fa191a3e67;p=thirdparty%2Fpostfix.git postfix-2.8-20100208 --- diff --git a/postfix/HISTORY b/postfix/HISTORY index 9522f47f1..b4d0af9c3 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -15709,3 +15709,17 @@ Apologies for any names omitted. Documentation: major revision of SASL_README with many details on how to configure Cyrus SASL internals. Patrick Koetter. File: proto/SASL_README.html + +20100204 + + Feature: added "forward_secrecy" option for Cyrus SASL. + File: xsasl/xsasl_cyrus_security.c. + +20100206 + + Bugfix (from day zero): the local delivery agent returned + undeliverable mail to the envelope sender instead of the + owner- alias, when delivering to command or file. This + reuses the workaround that was implemented to report a + Delivered-To: loop. Files: local/file.c, local/command.c, + local/recipient.c, local/bounce_workaround.c. diff --git a/postfix/README_FILES/SASL_README b/postfix/README_FILES/SASL_README index 9f7c4289d..cfa810dce 100644 --- a/postfix/README_FILES/SASL_README +++ b/postfix/README_FILES/SASL_README @@ -12,19 +12,17 @@ may be worth considering. HHooww PPoossttffiixx uusseess SSAASSLL aauutthheennttiiccaattiioonn -When an SMTP client connects to an SMTP server, the server needs to decide -whether that client is authorized to send mail to remote destinations, or -whether the client can send mail only to the destinations that the server -itself is responsible for. Usually, the SMTP server will allow mail to remote -destinations only if the client's IP address is in the "same network" as the -server's IP address. - -Sometimes the SMTP client and server are in different networks, but the client -still needs "same network" privileges. To address this problem, 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 the client is -authenticated the server can give it "same network" privileges. +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 allow mail to remote destinations when +the client's IP address is in the "same network" as the server's IP address. + +Sometimes an SMTP client needs "same network" privileges when it connects from +elsewhere. To address this problem, 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 @@ -76,7 +74,7 @@ You can read more about the following topics: * Enabling SASL authentication and authorization in the Postfix SMTP server o Enabling SASL authentication in the Postfix SMTP server - o Postfix SMTP Server Authentication Policy + o Postfix SMTP Server policy - SASL mechanism properties o Enabling SASL authorization in the Postfix SMTP server o Additional SMTP Server SASL options @@ -367,9 +365,9 @@ plugins. TThhee ssaassllddbb pplluuggiinn -The sasldb auxprop plugin authenticates credentials stored in a Berkeley DB -database. The database schema is specific to Cyrus SASL. The database is -usually located at /etc/sasldb2. +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. NNoottee @@ -422,17 +420,16 @@ Configure libsasl to use sasldb with the following instructions: TThhee ssqqll pplluuggiinn The sql auxprop plugin is a generic SQL plugin. It provides access to -credentials stored in a MySQL, a PostgreSQL or a SQLite database. - - NNoottee - - The shared-secret mechanisms (CRAM-MD5, etc.) require that the SASL client - passwords are stored as plaintext. +credentials stored in a MySQL, PostgreSQL or SQLite database. This plugin +requires that SASL client passwords are stored as plaintext. TTiipp - Use "saslauthd > pam > (pam database module)" to verify encrypted passwords - in an SQL database. + If you must store encrypted passwords, 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: @@ -442,7 +439,8 @@ to a PostgreSQL server: 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_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' @@ -510,22 +508,32 @@ available: TThhee llddaappddbb pplluuggiinn -The ldapdb auxprop plugin provides access to credentials stored in an OpenLDAP -LDAP server. It is the only plugin that implements proxy authorization. +The ldapdb auxprop plugin provides access to credentials stored in an LDAP +server. This plugin requires that SASL client passwords are stored as +plaintext. + + TTiipp -Proxy authorization in this context means: The ldapdb plugin must SASL -authenticate with the OpenLDAP server. The server then decides if the ldapdb -plugin should be authorized to read the authenticating user's password. Once -the ldapdb plugin has gone through proxy authorization it may proceed and -authenticate the remote SMTP client's credentials. + If you must store encrypted passwords, you can use "saslauthd -a ldap" to + query the LDAP database directly, with appropriate configuration in + saslauthd.conf. This may be documented in a later version of this document. + 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 OpenLDAP slapd server to -authenticate and authorize the ldapdb plugin. +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 OpenLDAP server: +connect to an LDAP server: /etc/sasl2/smtpd.conf: pwcheck_method: auxprop @@ -565,13 +573,11 @@ The following is a summary of applicable smtpd.conf file entries: LDAP server (proxy authorization). ldapdb_mech - The mechanism to authenticate the ldapdb plugin to the OpenLDAP slapd - server. + The mechanism to authenticate the ldapdb plugin to the LDAP server. NNoottee - Specify a mechanism here that is supported by the OpenLDAP slapd - server. + 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 @@ -701,10 +707,30 @@ capability twice - once for compliant and once for broken clients: 250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5 ... -PPoossttffiixx SSMMTTPP SSeerrvveerr AAuutthheennttiiccaattiioonn PPoolliiccyy - -The Postfix SMTP server provides a way to specify the properties of SASL -mechanisms that can be made available to the remote SMTP client. +PPoossttffiixx SSMMTTPP SSeerrvveerr ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess + +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. + + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + |PPrrooppeerrttyy |DDeessccrriippttiioonn | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |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. | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | UUnneennccrryypptteedd SSMMTTPP sseessssiioonn @@ -721,25 +747,6 @@ for those based on anonymous authentication: server can give strangers the same authorization as a properly- authenticated client. -Postfix can enforce the following policies on SASL authentication mechanisms: - - 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 - Use only mechanisms that support forward secrecy (Dovecot SASL only). - - mutual_auth - Use only mechanisms that authenticate both the client and the server to - each other. - EEnnccrryypptteedd SSMMTTPP sseessssiioonn ((TTLLSS)) A separate parameter controls Postfix SASL mechanism policy during a TLS- @@ -791,9 +798,9 @@ smtpd_recipient_restrictions as follows: EEnnvveellooppee sseennddeerr aaddddrreessss aauutthhoorriizzaattiioonn 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 remte SMTP -client hostname and IP address, but not the user who controls the remote SMTP -client. +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 @@ -811,8 +818,8 @@ authenticated client is allowed to use a particular envelope sender address: reject_unauth_destination ... -The controlled_envelope_senders table specifies the binding between the sender -envelope addresses and its their SASL login names: +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) @@ -935,14 +942,26 @@ You can read more about the following topics: * Enabling SASL authentication in the Postfix SMTP/LMTP client * Configuring sender-dependent SASL authentication - * Postfix SMTP/LMTP client authentication policy - * Filtering server mechanism names in the Postfix SMTP/LMTP client + * Postfix SMTP/LMTP client policy - SASL mechanism pprrooppeerrttiieess + * Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt This section shows a typical scenario where the Postfix SMTP client sends all -messages via a mail gateway server that requires SASL authentication. To make -the example more readable we introduce it in two parts. +messages via a mail gateway server that requires SASL authentication. + + TTrroouubbllee ssoollvviinngg ttiippss:: + + * If your SASL logins fail with "SASL authentication failure: No worthy + mechs found" in the mail logfile, then see the section "Postfix SMTP/ + LMTP client policy - SASL mechanism pprrooppeerrttiieess". + + * For a solution to a more obscure class of SASL authentication failures, + see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess". + +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 @@ -1057,10 +1076,26 @@ final resort. * Execute the command "postmap /etc/postfix/sender_relay" whenever you change the sender_relay table. -PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt aauutthheennttiiccaattiioonn ppoolliiccyy +PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess Just like the Postfix SMTP server, the SMTP client has a policy that determines -which SASL mechanisms are acceptable and which are not. +which SASL mechanisms are acceptable, based on their properties. The next two +sections give examples of how these policies are used. + + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + |PPrrooppeerrttyy |DDeessccrriippttiioonn | + |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |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. | + |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | UUnneennccrryypptteedd SSMMTTPP sseessssiioonn @@ -1070,38 +1105,18 @@ mechanisms are not allowed (nor is any anonymous mechanism): /etc/postfix/main.cf: smtp_sasl_security_options = noplaintext, noanonymous -Postfix can enforce the following policies on SASL authentication mechanisms: - - 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. - -With the default policy shown above, the Postfix SMTP client will not send its -password over an unencrypted connection. This sometimes leads to authentication -failures if the remote server only offers plaintext authentication mechanisms. -In such cases the SMTP client will log the following error message: +This default policy leads to authentication failures if the remote server only +offers plaintext authentication mechanisms. In such cases the SMTP client will +log the following error message: SASL authentication failure: No worthy mechs found -The less secure approach to deal with this is to lower the security standards -and permit plaintext authentication mechanisms: +The less secure approach is to lower the security standards and permit +plaintext authentication mechanisms: /etc/postfix/main.cf: smtp_sasl_security_options = noanonymous -Needless to say, sending a username and password over an insecure channel is -undesirable. - If the remote server supports TLS, you can protect the plaintext username and password by turning on TLS in the Postfix SMTP client (see: TLS_README), and configuring the client as discussed next. @@ -1122,16 +1137,18 @@ encrypted connection: smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous -FFiilltteerriinngg sseerrvveerr mmeecchhaanniissmm nnaammeess iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt +PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm nnaammeess -Cyrus SASL always attempts to use the most secure authentication mechanism that -the remote SMTP server offers - even if the client side was not configured to -handle it! In such cases authentication will definitely fail. +Unfortunately, Postfix needs a second client policy for SASL mechanism +selection. Reason: the Cyrus SASL library will choose the most secure +authentication mechanism that both the SMTP client and server implement - even +if one of the parties was not configured for that mechanism. -To prevent this, the Postfix SMTP client can filter the list of authentication -mechanism names 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 filter passes through. +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: diff --git a/postfix/README_FILES/SOHO_README b/postfix/README_FILES/SOHO_README index 3c40eb560..b18b44b38 100644 --- a/postfix/README_FILES/SOHO_README +++ b/postfix/README_FILES/SOHO_README @@ -152,8 +152,20 @@ virtual table. EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt This section shows a typical scenario where the Postfix SMTP client sends all -messages via a mail gateway server that requires SASL authentication. To make -the example more readable we introduce it in two parts. +messages via a mail gateway server that requires SASL authentication. + + TTrroouubbllee ssoollvviinngg ttiippss:: + + * If your SASL logins fail with "SASL authentication failure: No worthy + mechs found" in the mail logfile, then see the section "Postfix SMTP/ + LMTP client policy - SASL mechanism pprrooppeerrttiieess". + + * For a solution to a more obscure class of SASL authentication failures, + see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess". + +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 diff --git a/postfix/WISHLIST b/postfix/WISHLIST index a1ac0ca55..e5d402ce5 100644 --- a/postfix/WISHLIST +++ b/postfix/WISHLIST @@ -2,6 +2,12 @@ Wish list: Remove this file from the stable release. + instead of ipc_idle, reduce ipc_ttl. + + Add smtpd_sender_login_maps to proxy_read_maps. What other + parameters are worthy of being whitelisted for proxy access? + Is there a way to automate this decision? + The cleanup virtual alias expansion limit does not really deliver on its promises. 1) It promises to truncate the result without aborting delivery, which would be undesirable @@ -47,21 +53,17 @@ Wish list: Find a place to document all the mail routing mechanisms in one place so people can figure out how Postfix works. - owner-listname does not work for shell commands. - Investigate viability of Sendmail socket maps (the moral equivalent of tcp_table(5)), and dns maps. - The BCC action is marked "not stable", perhaps because - people would also expect BCC actions in header/body_checks. + The access map BCC action is marked "not stable", perhaps + because people would also expect BCC actions in header/body_checks. How much would it take to make the queue file editing code generally usable? Move smtpd_command_filter into smtpd_chat_query() and update the session transcript (see smtp_chat_reply() for an example). - Add smtpd_sender_login_maps to proxy_read_maps. - SMTP connection caching without storing connections, to improve TLS mail delivery performance. diff --git a/postfix/conf/post-install b/postfix/conf/post-install index 6e818671a..ed9a4b57d 100644 --- a/postfix/conf/post-install +++ b/postfix/conf/post-install @@ -737,7 +737,7 @@ q EOF } - # Postfix 2.7. + # Postfix 2.8. # Add missing postscreen service to master.cf. grep '^#*smtp.*postscreen' $config_directory/master.cf >/dev/null || { @@ -747,7 +747,7 @@ EOF EOF } - # Postfix 2.7. + # Postfix 2.8. # Add missing smtpd (unix-domain) service to master.cf. grep '^#*smtpd.*smtpd' $config_directory/master.cf >/dev/null || { @@ -757,7 +757,7 @@ EOF EOF } - # Postfix 2.7. + # Postfix 2.8. # Add temporary dnsblog (unix-domain) service to master.cf. grep '^#*dnsblog.*dnsblog' $config_directory/master.cf >/dev/null || { diff --git a/postfix/html/SASL_README.html b/postfix/html/SASL_README.html index b475ab3d7..454107e82 100644 --- a/postfix/html/SASL_README.html +++ b/postfix/html/SASL_README.html @@ -26,21 +26,19 @@ considering.

How Postfix uses SASL authentication

-

When an SMTP client connects to an SMTP server, the server needs -to decide whether that client is authorized to send mail to remote -destinations, or whether the client can send mail only to the -destinations that the server itself is responsible for. Usually, -the SMTP server will allow mail to remote destinations only if the -client's IP address is in the "same network" as the server's IP -address.

- -

Sometimes the SMTP client and server are in different networks, -but the client still needs "same network" privileges. To address -this problem, 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 the client is authenticated -the server can give it "same network" privileges.

+

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 allow +mail to remote destinations when the client's IP address is in the +"same network" as the server's IP address.

+ +

Sometimes an SMTP client needs "same network" privileges when +it connects from elsewhere. To address this problem, 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 @@ -131,12 +129,13 @@ authorization in the Postfix SMTP server the Postfix SMTP server

  • Postfix SMTP Server -Authentication Policy
    • +policy - SASL mechanism properties -
  • Enabling SASL authorization in the Postfix -SMTP server
    • +
  • Enabling SASL authorization in the +Postfix SMTP server
    • -
  • Additional SMTP Server SASL options
    • +
  • Additional SMTP Server SASL +options
    • @@ -146,7 +145,8 @@ SMTP server -

    Which SASL Implementations are supported?

    +

    Which SASL Implementations are +supported?

    Currently the Postfix SMTP server supports the Cyrus SASL and Dovecot SASL implementations.

    @@ -453,7 +453,7 @@ locations are /etc/sysconfig/saslauthd or -

    Using saslauthd with /etc/shadow

    +

    Using saslauthd with /etc/shadow

    Access to the /etc/shadow system password file requires root privileges. The Postfix SMTP server @@ -480,7 +480,7 @@ authentication backend /etc/shadow if started like this:

    See section "Testing saslauthd authentication" for test instructions.

    -

    Using saslauthd with PAM

    +

    Using saslauthd with PAM

    Cyrus SASL can use the PAM framework to authenticate credentials. saslauthd uses the PAM framework when started like @@ -505,7 +505,7 @@ document.

    See section "Testing saslauthd authentication" for test instructions.

    -

    Using saslauthd with an IMAP server

    +

    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, @@ -617,9 +617,10 @@ stored in encrypted form.

    The sasldb plugin

    -

    The sasldb auxprop plugin authenticates credentials stored in a Berkeley -DB database. The database schema is specific to Cyrus SASL. The -database is usually located at /etc/sasldb2.

    +

    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.

    @@ -709,31 +710,25 @@ 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, a PostgreSQL or a SQLite -database.

    - -
    - -Note - -

    The shared-secret mechanisms (CRAM-MD5, etc.) require that the -SASL client passwords are stored as plaintext.

    - -
    +access to credentials stored in a MySQL, PostgreSQL or SQLite +database. This plugin requires that SASL client passwords are +stored as plaintext.

    Tip - - -

    Use "saslauthd > pam > (pam database module)" to -verify encrypted passwords in an SQL database.

    +

    If you must store encrypted passwords, 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:

    +

    The following example configures libsasl to use the sql plugin +and connects it to a PostgreSQL server: 

    @@ -742,7 +737,8 @@ it to a PostgreSQL server: 
    
     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_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'
@@ -893,24 +889,37 @@ username. 
    
 
    The ldapdb plugin
    
 
 
     The ldapdb auxprop plugin provides access to credentials stored
-in an OpenLDAP LDAP server. It is the only plugin that implements
-proxy authorization. 
    
+in an LDAP server. This plugin requires that SASL client passwords are
+stored as plaintext. 
    
+
+
    
+
+Tip
 
-
     Proxy authorization in this context means: The ldapdb plugin
-must SASL authenticate with the OpenLDAP server. The server then
-decides if the ldapdb plugin should be authorized to read the
-authenticating user's password.  Once the ldapdb plugin has gone
-through proxy authorization it may proceed and authenticate the
-remote SMTP client's credentials. 
    
+
     If you must store encrypted passwords, you can use "saslauthd
+-a ldap" to query the LDAP database directly, with appropriate
+configuration in saslauthd.conf. This may be documented
+in a later version of this document.  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 OpenLDAP slapd server to authenticate and
-authorize the ldapdb plugin. 
    
+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 OpenLDAP server: 
    
+the plugin to connect to an LDAP server: 
    
 
 
    
 
    @@ -975,14 +984,14 @@ plugin to the LDAP server (proxy authorization). 
     
 
    ldapdb_mech
    
 
 
     
     The mechanism to authenticate the ldapdb plugin to the
-OpenLDAP slapd server. 
    
+LDAP server. 
    
 
 
    
 
 Note
 
-
     Specify a mechanism here that is supported by the OpenLDAP slapd
-server. 
    
+
     Specify a mechanism here that is supported by the LDAP server.
+
    
 
 
    
 
@@ -1186,12 +1195,39 @@ clients: 
    
 
    
 
    
 
-
    Postfix SMTP Server
-Authentication Policy
    
+
    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. 
    
+
+
    
+
+
+
+
 
-
     The Postfix SMTP server provides a way to specify the properties
-of SASL mechanisms that can be made available to the remote SMTP
-client.  
    
+
+
+
+
+
+
+
+
+
+
+
     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
    
 
@@ -1216,46 +1252,6 @@ authorization as a properly-authenticated client.
    -

    Postfix can enforce the following policies on SASL authentication -mechanisms:

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

    Use only mechanisms that support forward secrecy (Dovecot -SASL only).

    - -
    - -
    mutual_auth
    - -

    Use only mechanisms that authenticate both the client and -the server to each other.

    - -
    - -
    -

    Encrypted SMTP session (TLS)

    A separate parameter controls Postfix SASL mechanism policy @@ -1307,7 +1303,7 @@ for. Examples of possible SMTP clients authorizations are:

    These permissions are not enabled by default.

    -

    Mail relay authorization

    +

    Mail relay authorization

    The permit_sasl_authenticated restriction allows SASL-authenticated SMTP clients to send mail to remote destinations. @@ -1326,11 +1322,12 @@ follows:

    -

    Envelope sender address authorization

    +

    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 remte SMTP client hostname and IP address, but not +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. @@ -1355,8 +1352,8 @@ use a particular envelope sender address:

    The controlled_envelope_senders table specifies -the binding between the sender envelope addresses and its their -SASL login names:

    +the binding between a sender envelope address and the SASL login +names that own that address: 

    @@ -1535,11 +1532,11 @@ the Postfix SMTP/LMTP client
 
  • Configuring sender-dependent SASL
 authentication
    • 
 
-
  • Postfix SMTP/LMTP client
-authentication policy
    • 
+
  • Postfix SMTP/LMTP client policy
+- SASL mechanism properties
    • 
 
-
  • Filtering server mechanism names
-in the Postfix SMTP/LMTP client
    • 
+
  • Postfix SMTP/LMTP client policy
+- SASL mechanism names
    • 
 
 
 
@@ -1548,8 +1545,30 @@ 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. To make the example more readable we introduce
-it in two parts. 
    
+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.  
    
 
 
    
 
    @@ -1713,65 +1732,53 @@ whenever you change the sender_relay table. 
    
 
 
 
-
    Postfix SMTP/LMTP client authentication
-policy
    
+
    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 and which are
-not. 
    
-
-
    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
-
    
-
    
-
-
     Postfix can enforce the following policies on SASL authentication
-mechanisms: 
    
+that determines which SASL mechanisms are acceptable, based on their 
+properties. The next two sections give examples of how these policies
+are used.  
    
 
 
    
 
-
    
-
-
    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. 
    
+
    
 
-
+
     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.  
    
 
-
    
-
    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
+
    
 
    
 
-
     With the default policy shown above, the Postfix SMTP client
-will not send its password over an unencrypted connection.  This
-sometimes leads to authentication failures if the remote server
-only offers plaintext authentication mechanisms.  In such cases the
-SMTP client will log the following error message: 
    
+
     This default policy leads to authentication failures if the
+remote server only offers plaintext authentication mechanisms.  In
+such cases the SMTP client will log the following error message:
+
    
 
 
    
 
    @@ -1779,9 +1786,8 @@ SASL authentication failure: No worthy mechs found
 
    
 
    
 
-
     The less secure approach to deal with this is to lower the
-security standards and permit plaintext authentication mechanisms:
-
    
+
     The less secure approach is to lower the security standards and
+permit plaintext authentication mechanisms: 
    
 
 
    
 
    @@ -1790,9 +1796,6 @@ security standards and permit plaintext authentication mechanisms:
 
    
 
    
 
-
     Needless to say, sending a username and password over an insecure
-channel is undesirable. 
    
-
 
     If the remote server supports TLS, you can protect the plaintext
 username and password by turning on TLS in the Postfix SMTP client
 (see: TLS_README), and configuring the client as discussed next.
@@ -1821,19 +1824,20 @@ only over a TLS-encrypted connection: 
    
 
    
 
    
 
-
    Filtering server mechanism names in
-the Postfix SMTP/LMTP client
    
+
    Postfix SMTP/LMTP client policy -
+SASL mechanism names
    
 
-
     Cyrus SASL always attempts to use the most secure authentication
-mechanism that the remote SMTP server offers - even if the client
-side was not configured to handle it! In such cases authentication
-will definitely fail. 
    
+
     Unfortunately, Postfix needs a second client policy for SASL
+mechanism selection.  Reason: the Cyrus SASL library will choose
+the most secure authentication mechanism that both the SMTP client
+and server implement - even if one of the parties was not configured
+for that mechanism. 
    
 
-
     To prevent this, the Postfix SMTP client can filter the list
-of authentication mechanism names from the remote SMTP server.  Used
+
     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 filter passes through.  
    
+Postfix SMTP client filter passes through.  
    
 
 
     The following example filters out everything but the mechanisms
 PLAIN and LOGIN: 
    
diff --git a/postfix/html/SOHO_README.html b/postfix/html/SOHO_README.html
index d4458aeeb..83f290d01 100644
--- a/postfix/html/SOHO_README.html
+++ b/postfix/html/SOHO_README.html
@@ -219,8 +219,30 @@ 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. To make the example more readable we introduce
-it in two parts. 
    
+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.  
    
 
 
    
 
    diff --git a/postfix/html/postmulti.1.html b/postfix/html/postmulti.1.html
index 645238e24..465ec1fab 100644
--- a/postfix/html/postmulti.1.html
+++ b/postfix/html/postmulti.1.html
@@ -10,13 +10,19 @@ POSTMULTI(1)                                                      POSTMULTI(1)
        postmulti - Postfix multi-instance manager
 
 SYNOPSIS
+       ENABLING MULTI-INSTANCE MANAGEMENT:
+
+       postmulti -e init [-v]
+
+       ITERATOR MODE:
+
        postmulti -l [-aRv] [-g group] [-i name]
 
        postmulti -p [-av] [-g group] [-i name] command...
 
        postmulti -x [-aRv] [-g group] [-i name] command...
 
-       postmulti -e init [-v]
+       LIFE-CYCLE MANAGEMENT:
 
        postmulti -e create [-av] [-g group] [-i name] [-G group]
        [-I name] [param=value ...]
diff --git a/postfix/man/man1/postmulti.1 b/postfix/man/man1/postmulti.1
index 9d7c8b399..8bafd70d6 100644
--- a/postfix/man/man1/postmulti.1
+++ b/postfix/man/man1/postmulti.1
@@ -9,6 +9,12 @@ Postfix multi-instance manager
 .na
 .nf
 .fi
+\fBENABLING MULTI-INSTANCE MANAGEMENT:\fR
+
+\fBpostmulti\fR \fB-e init\fR [\fB-v\fR]
+
+\fBITERATOR MODE:\fR
+
 \fBpostmulti\fR \fB-l\fR [\fB-aRv\fR] [\fB-g \fIgroup\fR]
 [\fB-i \fIname\fR]
 
@@ -18,7 +24,7 @@ Postfix multi-instance manager
 \fBpostmulti\fR \fB-x\fR [\fB-aRv\fR] [\fB-g \fIgroup\fR]
 [\fB-i \fIname\fR] \fIcommand...\fR
 
-\fBpostmulti\fR \fB-e init\fR [\fB-v\fR]
+\fBLIFE-CYCLE MANAGEMENT:\fR
 
 \fBpostmulti\fR \fB-e create\fR [\fB-av\fR]
 [\fB-g \fIgroup\fR] [\fB-i \fIname\fR] [\fB-G \fIgroup\fR]
diff --git a/postfix/mantools/make-relnotes b/postfix/mantools/make-relnotes
index 2cc5b4fe3..4d07e6632 100755
--- a/postfix/mantools/make-relnotes
+++ b/postfix/mantools/make-relnotes
@@ -18,7 +18,7 @@ $append_to = \%leader;
 
 while (<>) {
 
-    if (/^Incompatible changes with/) {
+    if (/^(Incompatible changes|Incompatibility) with/) {
 	die "No date found: $_" unless /(\d\d\d\d\d\d\d\d)/;
 	$append_to = \%body;
 	$prefix = "[Incompat $1] ";
diff --git a/postfix/proto/SASL_README.html b/postfix/proto/SASL_README.html
index 3c6e558e9..25efe1d74 100644
--- a/postfix/proto/SASL_README.html
+++ b/postfix/proto/SASL_README.html
@@ -26,21 +26,19 @@ considering. 
    
 
 
    How Postfix uses SASL authentication
    
 
-
     When an SMTP client connects to an SMTP server, the server needs
-to decide whether that client is authorized to send mail to remote
-destinations, or whether the client can send mail only to the
-destinations that the server itself is responsible for.  Usually,
-the SMTP server will allow mail to remote destinations only if the
-client's IP address is in the "same network" as the server's IP
-address.  
    
-
-
     Sometimes the SMTP client and server are in different networks,
-but the client still needs "same network" privileges.  To address
-this problem, 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 the client is authenticated
-the server can give it "same network" privileges.  
    
+
     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 allow
+mail to remote destinations when the client's IP address is in the
+"same network" as the server's IP address.  
    
+
+
     Sometimes an SMTP client needs "same network" privileges when
+it connects from elsewhere.  To address this problem, 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
@@ -131,12 +129,13 @@ authorization in the Postfix SMTP server
 the Postfix SMTP server
 
 
  • Postfix SMTP Server
-Authentication Policy
    • 
+policy - SASL mechanism properties
 
-
  • Enabling SASL authorization in the Postfix
-SMTP server
    • 
+
  • Enabling SASL authorization in the
+Postfix SMTP server
    • 
 
-
  • Additional SMTP Server SASL options
    • 
+
  • Additional SMTP Server SASL
+options
    • 
 
 
 
@@ -146,7 +145,8 @@ SMTP server
 
 
 
-
    Which SASL Implementations are supported?
    
+
    Which SASL Implementations are
+supported?
    
 
 
     Currently the Postfix SMTP server supports the Cyrus SASL and
 Dovecot SASL implementations. 
    
@@ -453,7 +453,7 @@ locations are /etc/sysconfig/saslauthd or
 
 
    
 
-
    Using saslauthd with /etc/shadow
    
+
    Using saslauthd with /etc/shadow
    
 
 
     Access to the /etc/shadow system password file
 requires root privileges.  The Postfix SMTP server
@@ -480,7 +480,7 @@ authentication backend /etc/shadow if started like this: 
    
 
     See section "Testing saslauthd
 authentication" for test instructions. 
    
 
-
    Using saslauthd with PAM
    
+
    Using saslauthd with PAM
    
 
 
     Cyrus SASL can use the PAM framework to authenticate credentials.
 saslauthd uses the PAM framework when started like
@@ -505,7 +505,7 @@ document. 
    
 
     See section "Testing saslauthd
 authentication" for test instructions. 
    
 
-
    Using saslauthd with an IMAP server
    
+
    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,
@@ -617,9 +617,10 @@ stored in encrypted form. 
    
 
 
    The sasldb plugin
    
 
-
     The sasldb auxprop plugin authenticates credentials stored in a Berkeley
-DB database. The database schema is specific to Cyrus SASL.  The
-database is usually located at /etc/sasldb2. 
    
+
     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. 
    
 
 
    
 
@@ -709,31 +710,25 @@ 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, a PostgreSQL or a SQLite
-database. 
    
-
-
    
-
-Note
-
-
     The shared-secret mechanisms (CRAM-MD5, etc.) require that the
-SASL client passwords are stored as plaintext.  
    
-
-
    
+access to credentials stored in a MySQL, PostgreSQL or SQLite
+database. This plugin requires that SASL client passwords are
+stored as plaintext. 
    
 
 
    
 
 Tip
 
-
-
-
     Use "saslauthd > pam > (pam database module)" to
-verify encrypted passwords in an SQL database. 
    
+
     If you must store encrypted passwords, 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: 
    
+
     The following example configures libsasl to use the sql plugin
+and connects it to a PostgreSQL server: 
    
 
 
    
 
    @@ -742,7 +737,8 @@ it to a PostgreSQL server: 
    
     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_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'
@@ -893,24 +889,37 @@ username. 
    
 
    The ldapdb plugin
    
 
 
     The ldapdb auxprop plugin provides access to credentials stored
-in an OpenLDAP LDAP server. It is the only plugin that implements
-proxy authorization. 
    
+in an LDAP server. This plugin requires that SASL client passwords are
+stored as plaintext. 
    
+
+
    
+
+Tip
 
-
     Proxy authorization in this context means: The ldapdb plugin
-must SASL authenticate with the OpenLDAP server. The server then
-decides if the ldapdb plugin should be authorized to read the
-authenticating user's password.  Once the ldapdb plugin has gone
-through proxy authorization it may proceed and authenticate the
-remote SMTP client's credentials. 
    
+
     If you must store encrypted passwords, you can use "saslauthd
+-a ldap" to query the LDAP database directly, with appropriate
+configuration in saslauthd.conf. This may be documented
+in a later version of this document.  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 OpenLDAP slapd server to authenticate and
-authorize the ldapdb plugin. 
    
+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 OpenLDAP server: 
    
+the plugin to connect to an LDAP server: 
    
 
 
    
 
    @@ -975,14 +984,14 @@ plugin to the LDAP server (proxy authorization). 
     
 
    ldapdb_mech
    
 
 
     
     The mechanism to authenticate the ldapdb plugin to the
-OpenLDAP slapd server. 
    
+LDAP server. 
    
 
 
    
 
 Note
 
-
     Specify a mechanism here that is supported by the OpenLDAP slapd
-server. 
    
+
     Specify a mechanism here that is supported by the LDAP server.
+
    
 
 
    
 
@@ -1186,12 +1195,39 @@ clients: 
    
 
    
 
    
 
-
    Postfix SMTP Server
-Authentication Policy
    
+
    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. 
    
+
+
    
+
+
+
+
 
-
     The Postfix SMTP server provides a way to specify the properties
-of SASL mechanisms that can be made available to the remote SMTP
-client.  
    
+
+
+
+
+
+
+
+
+
+
+
     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
    
 
@@ -1216,46 +1252,6 @@ authorization as a properly-authenticated client. 
    
 
 
    
 
-
     Postfix can enforce the following policies on SASL authentication
-mechanisms: 
    
-
-
    
-
-
    
-
-
    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
    
-
-
     
     Use only mechanisms that support forward secrecy (Dovecot
-SASL only).
    
-
-
    
-
-
    mutual_auth
    
-
-
     
     Use only mechanisms that authenticate both the client and
-the server to each other. 
     
    
-
-
    
-
-
    
-
 
    Encrypted SMTP session (TLS)
    
 
 
     A separate parameter controls Postfix SASL mechanism policy
@@ -1307,7 +1303,7 @@ for. Examples of possible SMTP clients authorizations are: 
    
 
 
     These permissions are not enabled by default. 
    
 
-
    Mail relay authorization
    
+
    Mail relay authorization
    
 
 
     The permit_sasl_authenticated restriction allows
 SASL-authenticated SMTP clients to send mail to remote destinations.
@@ -1326,11 +1322,12 @@ follows:
    -

    Envelope sender address authorization

    +

    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 remte SMTP client hostname and IP address, but not +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. @@ -1355,8 +1352,8 @@ use a particular envelope sender address:

    The controlled_envelope_senders table specifies -the binding between the sender envelope addresses and its their -SASL login names:

    +the binding between a sender envelope address and the SASL login +names that own that address: 

    @@ -1535,11 +1532,11 @@ the Postfix SMTP/LMTP client
 
  • Configuring sender-dependent SASL
 authentication
    • 
 
-
  • Postfix SMTP/LMTP client
-authentication policy
    • 
+
  • Postfix SMTP/LMTP client policy
+- SASL mechanism properties
    • 
 
-
  • Filtering server mechanism names
-in the Postfix SMTP/LMTP client
    • 
+
  • Postfix SMTP/LMTP client policy
+- SASL mechanism names
    • 
 
 
 
@@ -1548,8 +1545,30 @@ 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. To make the example more readable we introduce
-it in two parts. 
    
+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.  
    
 
 
    
 
    @@ -1713,65 +1732,53 @@ whenever you change the sender_relay table. 
    
 
 
 
-
    Postfix SMTP/LMTP client authentication
-policy
    
+
    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 and which are
-not. 
    
-
-
    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
-
    
-
    
-
-
     Postfix can enforce the following policies on SASL authentication
-mechanisms: 
    
+that determines which SASL mechanisms are acceptable, based on their 
+properties. The next two sections give examples of how these policies
+are used.  
    
 
 
    
 
-
    
-
-
    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. 
    
+
    
 
-
+
     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.  
    
 
-
    
-
    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
+
    
 
    
 
-
     With the default policy shown above, the Postfix SMTP client
-will not send its password over an unencrypted connection.  This
-sometimes leads to authentication failures if the remote server
-only offers plaintext authentication mechanisms.  In such cases the
-SMTP client will log the following error message: 
    
+
     This default policy leads to authentication failures if the
+remote server only offers plaintext authentication mechanisms.  In
+such cases the SMTP client will log the following error message:
+
    
 
 
    
 
    @@ -1779,9 +1786,8 @@ SASL authentication failure: No worthy mechs found
 
    
 
    
 
-
     The less secure approach to deal with this is to lower the
-security standards and permit plaintext authentication mechanisms:
-
    
+
     The less secure approach is to lower the security standards and
+permit plaintext authentication mechanisms: 
    
 
 
    
 
    @@ -1790,9 +1796,6 @@ security standards and permit plaintext authentication mechanisms:
 
    
 
    
 
-
     Needless to say, sending a username and password over an insecure
-channel is undesirable. 
    
-
 
     If the remote server supports TLS, you can protect the plaintext
 username and password by turning on TLS in the Postfix SMTP client
 (see: TLS_README), and configuring the client as discussed next.
@@ -1821,19 +1824,20 @@ only over a TLS-encrypted connection: 
    
 
    
 
    
 
-
    Filtering server mechanism names in
-the Postfix SMTP/LMTP client
    
+
    Postfix SMTP/LMTP client policy -
+SASL mechanism names
    
 
-
     Cyrus SASL always attempts to use the most secure authentication
-mechanism that the remote SMTP server offers - even if the client
-side was not configured to handle it! In such cases authentication
-will definitely fail. 
    
+
     Unfortunately, Postfix needs a second client policy for SASL
+mechanism selection.  Reason: the Cyrus SASL library will choose
+the most secure authentication mechanism that both the SMTP client
+and server implement - even if one of the parties was not configured
+for that mechanism. 
    
 
-
     To prevent this, the Postfix SMTP client can filter the list
-of authentication mechanism names from the remote SMTP server.  Used
+
     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 filter passes through.  
    
+Postfix SMTP client filter passes through.  
    
 
 
     The following example filters out everything but the mechanisms
 PLAIN and LOGIN: 
    
diff --git a/postfix/src/global/mail_version.h b/postfix/src/global/mail_version.h
index 73890d837..ff112740f 100644
--- a/postfix/src/global/mail_version.h
+++ b/postfix/src/global/mail_version.h
@@ -20,7 +20,7 @@
   * Patches change both the patchlevel and the release date. Snapshots have no
   * patchlevel; they change the release date only.
   */
-#define MAIL_RELEASE_DATE	"20100203"
+#define MAIL_RELEASE_DATE	"20100208"
 #define MAIL_VERSION_NUMBER	"2.8"
 
 #ifdef SNAPSHOT
diff --git a/postfix/src/local/Makefile.in b/postfix/src/local/Makefile.in
index 13a2788a1..544993de5 100644
--- a/postfix/src/local/Makefile.in
+++ b/postfix/src/local/Makefile.in
@@ -2,11 +2,11 @@ SHELL	= /bin/sh
 SRCS	= alias.c command.c dotforward.c file.c forward.c \
 	include.c indirect.c local.c mailbox.c recipient.c resolve.c token.c \
 	deliver_attr.c maildir.c biff_notify.c unknown.c \
-	local_expand.c
+	local_expand.c bounce_workaround.c
 OBJS	= alias.o command.o dotforward.o file.o forward.o \
 	include.o indirect.o local.o mailbox.o recipient.o resolve.o token.o \
 	deliver_attr.o maildir.o biff_notify.o unknown.o \
-	local_expand.o
+	local_expand.o bounce_workaround.c
 HDRS	= local.h
 TESTSRC	=
 DEFS	= -I. -I$(INC_DIR) -D$(SYSTYPE)
@@ -101,6 +101,37 @@ biff_notify.o: ../../include/msg.h
 biff_notify.o: ../../include/sys_defs.h
 biff_notify.o: biff_notify.c
 biff_notify.o: biff_notify.h
+bounce_workaround.o: ../../include/argv.h
+bounce_workaround.o: ../../include/attr.h
+bounce_workaround.o: ../../include/been_here.h
+bounce_workaround.o: ../../include/bounce.h
+bounce_workaround.o: ../../include/canon_addr.h
+bounce_workaround.o: ../../include/deliver_request.h
+bounce_workaround.o: ../../include/delivered_hdr.h
+bounce_workaround.o: ../../include/dict.h
+bounce_workaround.o: ../../include/dsn.h
+bounce_workaround.o: ../../include/dsn_buf.h
+bounce_workaround.o: ../../include/fold_addr.h
+bounce_workaround.o: ../../include/htable.h
+bounce_workaround.o: ../../include/mail_params.h
+bounce_workaround.o: ../../include/maps.h
+bounce_workaround.o: ../../include/mbox_conf.h
+bounce_workaround.o: ../../include/msg.h
+bounce_workaround.o: ../../include/msg_stats.h
+bounce_workaround.o: ../../include/mymalloc.h
+bounce_workaround.o: ../../include/recipient_list.h
+bounce_workaround.o: ../../include/resolve_clnt.h
+bounce_workaround.o: ../../include/split_addr.h
+bounce_workaround.o: ../../include/split_at.h
+bounce_workaround.o: ../../include/stringops.h
+bounce_workaround.o: ../../include/strip_addr.h
+bounce_workaround.o: ../../include/sys_defs.h
+bounce_workaround.o: ../../include/tok822.h
+bounce_workaround.o: ../../include/vbuf.h
+bounce_workaround.o: ../../include/vstream.h
+bounce_workaround.o: ../../include/vstring.h
+bounce_workaround.o: bounce_workaround.c
+bounce_workaround.o: local.h
 command.o: ../../include/argv.h
 command.o: ../../include/attr.h
 command.o: ../../include/been_here.h
diff --git a/postfix/src/local/bounce_workaround.c b/postfix/src/local/bounce_workaround.c
new file mode 100644
index 000000000..b09df7d41
--- /dev/null
+++ b/postfix/src/local/bounce_workaround.c
@@ -0,0 +1,143 @@
+/*++
+/* NAME
+/*	bounce_workaround 3
+/* SUMMARY
+/*	Send non-delivery notification with sender override
+/* SYNOPSIS
+/*	#include "local.h"
+/*
+/*	int	bounce_workaround(state)
+/*	LOCAL_STATE state;
+/* DESCRIPTION
+/*	This module works around a limitation in the bounce daemon
+/*	protocol, namely, the assumption that the envelope sender
+/*	address in a queue file is the delivery status notification
+/*	address for all recipients in that queue file. The assumption
+/*	is not valid when the local(8) delivery agent overrides the
+/*	envelope sender address by an owner- alias, for one or more
+/*	recipients in the queue file.
+/*
+/*	Sender address override is a problem only when delivering
+/*	to command or file, or when breaking a Delivered-To loop.
+/*	The local(8) delivery agent saves other recipients to a new
+/*	queue file, together with the replacement envelope sender
+/*	address; delivery then proceeds from that new queue file.
+/*
+/*	The workaround sends one non-delivery notification for each
+/*	failed delivery that has a replacement sender address.  The
+/*	notifications are not aggregated, unlike notifications to
+/*	non-replaced sender addresses). In practice, a local alias
+/*	rarely has more than one file or command destination (if
+/*	only because soft error handling is problematic).
+/*
+/*	Arguments:
+/* .IP state
+/*	The attributes that specify the message, recipient and more.
+/*	Attributes describing alias, include or forward expansion.
+/*	A table with the results from expanding aliases or lists.
+/*	A table with delivered-to: addresses taken from the message.
+/* DIAGNOSTICS
+/*	Fatal errors: out of memory. The result is non-zero when
+/*	the operation should be tried again. Warnings: malformed
+/*	address.
+/* BUGS
+/*	The proper fix is to record in the bounce logfile an error
+/*	return address for each individual recipient. This would
+/*	eliminate the need for VERP-specific bounce protocol code,
+/*	and would move complexity from the bounce client side to
+/*	the bounce server side where it more likely belongs.
+/* 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
+/*--*/
+
+/* System library. */
+
+#include 
+#include 
+
+/* Utility library. */
+
+#include 
+#include 
+#include 
+#include 
+
+/* Global library. */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Application-specific. */
+
+#include "local.h"
+
+int     bounce_workaround(LOCAL_STATE state)
+{
+    const char *myname = "bounce_workaround";
+    VSTRING *canon_owner = 0;
+    int     rcpt_stat;
+
+    /*
+     * Look up the substitute sender address.
+     */
+    if (var_ownreq_special) {
+	char   *stripped_recipient;
+	char   *owner_alias;
+	const char *owner_expansion;
+
+#define FIND_OWNER(lhs, rhs, addr) { \
+	lhs = concatenate("owner-", addr, (char *) 0); \
+	(void) split_at_right(lhs, '@'); \
+	rhs = maps_find(alias_maps, lhs, DICT_FLAG_NONE); \
+    }
+
+	FIND_OWNER(owner_alias, owner_expansion, state.msg_attr.rcpt.address);
+	if (owner_expansion == 0
+	    && (stripped_recipient = strip_addr(state.msg_attr.rcpt.address,
+						(char **) 0,
+						*var_rcpt_delim)) != 0) {
+	    myfree(owner_alias);
+	    FIND_OWNER(owner_alias, owner_expansion, stripped_recipient);
+	    myfree(stripped_recipient);
+	}
+	if (owner_expansion != 0) {
+	    canon_owner = canon_addr_internal(vstring_alloc(10),
+					      var_exp_own_alias ?
+					      owner_expansion : owner_alias);
+	    SET_OWNER_ATTR(state.msg_attr, STR(canon_owner), state.level);
+	}
+	myfree(owner_alias);
+    }
+
+    /*
+     * Send a delivery status notification with a single recipient to the
+     * substitute sender address, before completion of the delivery request.
+     */
+    if (canon_owner) {
+	rcpt_stat = bounce_one(BOUNCE_FLAGS(state.request),
+			       BOUNCE_ONE_ATTR(state.msg_attr));
+	vstring_free(canon_owner);
+    }
+
+    /*
+     * Send a regular delivery status notification, after completion of the
+     * delivery request.
+     */
+    else {
+	rcpt_stat = bounce_append(BOUNCE_FLAGS(state.request),
+				  BOUNCE_ATTR(state.msg_attr));
+    }
+    return (rcpt_stat);
+}
diff --git a/postfix/src/local/command.c b/postfix/src/local/command.c
index 7952583c2..707cec6c9 100644
--- a/postfix/src/local/command.c
+++ b/postfix/src/local/command.c
@@ -235,11 +235,13 @@ int     deliver_command(LOCAL_STATE state, USER_ATTR usr_attr, const char *comma
 	break;
     case PIPE_STAT_BOUNCE:
     case PIPE_STAT_DEFER:
-	deliver_status =
-	    (STR(why->status)[0] == '4' ?
-	     defer_append : bounce_append)
-	    (BOUNCE_FLAGS(state.request),
-	     BOUNCE_ATTR(state.msg_attr));
+	if (STR(why->status)[0] == '4')
+	    deliver_status =
+		defer_append(BOUNCE_FLAGS(state.request),
+			     BOUNCE_ATTR(state.msg_attr));
+	else
+	    /* Account for possible owner- sender address override. */
+	    deliver_status = bounce_workaround(state);
 	break;
     case PIPE_STAT_CORRUPT:
 	deliver_status = DEL_STAT_DEFER;
diff --git a/postfix/src/local/file.c b/postfix/src/local/file.c
index d93ae90b0..4adfdf819 100644
--- a/postfix/src/local/file.c
+++ b/postfix/src/local/file.c
@@ -111,8 +111,8 @@ int     deliver_file(LOCAL_STATE state, USER_ATTR usr_attr, char *path)
      */
     if ((local_file_deliver_mask & state.msg_attr.exp_type) == 0) {
 	dsb_simple(why, "5.7.1", "mail to file is restricted");
-	return (bounce_append(BOUNCE_FLAGS(state.request),
-			      BOUNCE_ATTR(state.msg_attr)));
+	/* Account for possible owner- sender address override. */
+	return (bounce_workaround(state));
     }
 
     /*
@@ -184,11 +184,13 @@ int     deliver_file(LOCAL_STATE state, USER_ATTR usr_attr, char *path)
     } else if (mail_copy_status != 0) {
 	vstring_sprintf_prepend(why->reason,
 				"cannot append message to file %s: ", path);
-	deliver_status =
-	    (STR(why->status)[0] == '4' ?
-	     defer_append : bounce_append)
-	    (BOUNCE_FLAGS(state.request),
-	     BOUNCE_ATTR(state.msg_attr));
+	if (STR(why->status)[0] == '4')
+	    deliver_status =
+		defer_append(BOUNCE_FLAGS(state.request),
+			     BOUNCE_ATTR(state.msg_attr));
+	else
+	    /* Account for possible owner- sender address override. */
+	    deliver_status = bounce_workaround(state);
     } else {
 	dsb_simple(why, "2.0.0", "delivered to file: %s", path);
 	deliver_status = sent(BOUNCE_FLAGS(state.request),
diff --git a/postfix/src/local/local.h b/postfix/src/local/local.h
index d63c99a65..0e9656de4 100644
--- a/postfix/src/local/local.h
+++ b/postfix/src/local/local.h
@@ -233,6 +233,11 @@ extern MAPS *alias_maps;
   */
 #define STR(s)	vstring_str(s)
 
+ /*
+  * bounce_workaround.c
+  */
+int     bounce_workaround(LOCAL_STATE);
+
 /* LICENSE
 /* .ad
 /* .fi
diff --git a/postfix/src/local/recipient.c b/postfix/src/local/recipient.c
index e279eef0e..f36d21023 100644
--- a/postfix/src/local/recipient.c
+++ b/postfix/src/local/recipient.c
@@ -230,47 +230,10 @@ int     deliver_recipient(LOCAL_STATE state, USER_ATTR usr_attr)
      * normal bounce sending procedure, but would simplify the code below.
      */
     if (delivered_hdr_find(state.loop_info, state.msg_attr.rcpt.address)) {
-	VSTRING *canon_owner = 0;
-
-	if (var_ownreq_special) {
-	    char   *stripped_recipient;
-	    char   *owner_alias;
-	    const char *owner_expansion;
-
-#define FIND_OWNER(lhs, rhs, addr) { \
-	lhs = concatenate("owner-", addr, (char *) 0); \
-	(void) split_at_right(lhs, '@'); \
-	rhs = maps_find(alias_maps, lhs, DICT_FLAG_NONE); \
-    }
-
-	    FIND_OWNER(owner_alias, owner_expansion, state.msg_attr.rcpt.address);
-	    if (owner_expansion == 0
-	    && (stripped_recipient = strip_addr(state.msg_attr.rcpt.address,
-						(char **) 0,
-						*var_rcpt_delim)) != 0) {
-		myfree(owner_alias);
-		FIND_OWNER(owner_alias, owner_expansion, stripped_recipient);
-		myfree(stripped_recipient);
-	    }
-	    if (owner_expansion != 0) {
-		canon_owner = canon_addr_internal(vstring_alloc(10),
-						  var_exp_own_alias ?
-					     owner_expansion : owner_alias);
-		SET_OWNER_ATTR(state.msg_attr, STR(canon_owner), state.level);
-	    }
-	    myfree(owner_alias);
-	}
-	dsb_simple(state.msg_attr.why, "5.4.6",	"mail forwarding loop for %s",
+	dsb_simple(state.msg_attr.why, "5.4.6", "mail forwarding loop for %s",
 		   state.msg_attr.rcpt.address);
-	if (canon_owner) {
-	    rcpt_stat = bounce_one(BOUNCE_FLAGS(state.request),
-				   BOUNCE_ONE_ATTR(state.msg_attr));
-	    vstring_free(canon_owner);
-	} else {
-	    rcpt_stat = bounce_append(BOUNCE_FLAGS(state.request),
-				      BOUNCE_ATTR(state.msg_attr));
-	}
-	return (rcpt_stat);
+	/* Account for possible owner- sender address override. */
+	return (bounce_workaround(state));
     }
 
     /*
diff --git a/postfix/src/postmulti/postmulti.c b/postfix/src/postmulti/postmulti.c
index d8f12e1a0..30633ae26 100644
--- a/postfix/src/postmulti/postmulti.c
+++ b/postfix/src/postmulti/postmulti.c
@@ -5,6 +5,12 @@
 /*	Postfix multi-instance manager
 /* SYNOPSIS
 /* .fi
+/*	\fBENABLING MULTI-INSTANCE MANAGEMENT:\fR
+/*
+/*	\fBpostmulti\fR \fB-e init\fR [\fB-v\fR]
+/*
+/*	\fBITERATOR MODE:\fR
+/*
 /*	\fBpostmulti\fR \fB-l\fR [\fB-aRv\fR] [\fB-g \fIgroup\fR]
 /*	[\fB-i \fIname\fR]
 /*
@@ -14,7 +20,7 @@
 /*	\fBpostmulti\fR \fB-x\fR [\fB-aRv\fR] [\fB-g \fIgroup\fR]
 /*	[\fB-i \fIname\fR] \fIcommand...\fR
 /*
-/*	\fBpostmulti\fR \fB-e init\fR [\fB-v\fR]
+/*	\fBLIFE-CYCLE MANAGEMENT:\fR
 /*
 /*	\fBpostmulti\fR \fB-e create\fR [\fB-av\fR]
 /*	[\fB-g \fIgroup\fR] [\fB-i \fIname\fR] [\fB-G \fIgroup\fR]
diff --git a/postfix/src/xsasl/xsasl_cyrus_security.c b/postfix/src/xsasl/xsasl_cyrus_security.c
index 617ff2fd9..7ca721653 100644
--- a/postfix/src/xsasl/xsasl_cyrus_security.c
+++ b/postfix/src/xsasl/xsasl_cyrus_security.c
@@ -25,6 +25,8 @@
 /* .IP nodictionary
 /*	Disallow authentication methods that are vulnerable to
 /*	passive dictionary attack.
+/* .IP forward_secrecy
+/*	Require forward secrecy between sessions.
 /* .IP noanonymous
 /*	Disallow anonymous logins.
 /* .RE
@@ -64,6 +66,9 @@ static const NAME_MASK xsasl_cyrus_sec_mask[] = {
     "noplaintext", SASL_SEC_NOPLAINTEXT,
     "noactive", SASL_SEC_NOACTIVE,
     "nodictionary", SASL_SEC_NODICTIONARY,
+#ifdef SASL_SEC_FORWARD_SECRECY
+    "forward_secrecy", SASL_SEC_FORWARD_SECRECY,
+#endif
     "noanonymous", SASL_SEC_NOANONYMOUS,
 #if SASL_VERSION_MAJOR >= 2
     "mutual_auth", SASL_SEC_MUTUAL_AUTH,