postfix-2.8-20100208

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.

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
+SMTP servers need to decide whether an SMTP client is authorized to send mail
-whether that client is authorized to send mail to remote destinations, or
+to remote destinations, or only to destinations that the server itself is
-whether the client can send mail only to the destinations that the server
+responsible for. Usually, SMTP servers allow mail to remote destinations when
-itself is responsible for. Usually, the SMTP server will allow mail to remote
+the client's IP address is in the "same network" as the server's IP address.
-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
+Sometimes an SMTP client needs "same network" privileges when it connects from
-still needs "same network" privileges. To address this problem, Postfix
+elsewhere. To address this problem, Postfix supports SASL authentication (RFC
-supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote
+4954, formerly RFC 2554). With this a remote SMTP client can authenticate to
-SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP
+the Postfix SMTP server, and the Postfix SMTP client can authenticate to a
-client can authenticate to a remote SMTP server. Once the client is
+remote SMTP server. Once a client is authenticated, a server can give it "same
-authenticated the server can give it "same network" privileges.
+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
+The sasldb auxprop plugin authenticates SASL clients against credentials that
-database. The database schema is specific to Cyrus SASL. The database is
+are stored in a Berkeley DB database. The database schema is specific to Cyrus
-usually located at /etc/sasldb2.
+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.
+credentials stored in a MySQL, PostgreSQL or SQLite database. This plugin
-
+requires that SASL client passwords are stored as plaintext.
-    NNoottee
-
-    The shared-secret mechanisms (CRAM-MD5, etc.) require that the SASL client
-    passwords are stored as plaintext.
 
     TTiipp
 
-    Use "saslauthd > pam > (pam database module)" to verify encrypted passwords
+    If you must store encrypted passwords, see section "Using saslauthd with
-    in an SQL database.
+    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
+The ldapdb auxprop plugin provides access to credentials stored in an LDAP
-LDAP server. It is the only plugin that implements proxy authorization.
+server. This plugin requires that SASL client passwords are stored as
+plaintext.
 
-Proxy authorization in this context means: The ldapdb plugin must SASL
+    TTiipp
-authenticate with the OpenLDAP server. The server then decides if the ldapdb
+
-plugin should be authorized to read the authenticating user's password. Once
+    If you must store encrypted passwords, you can use "saslauthd -a ldap" to
-the ldapdb plugin has gone through proxy authorization it may proceed and
+    query the LDAP database directly, with appropriate configuration in
-authenticate the remote SMTP client's credentials.
+    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
+authorize the remote SMTP client, and once in the LDAP server to authenticate
-authenticate and authorize the ldapdb plugin.
+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
+        The mechanism to authenticate the ldapdb plugin to the LDAP server.
-        server.
 
             NNoottee
 
-            Specify a mechanism here that is supported by the OpenLDAP slapd
+            Specify a mechanism here that is supported by the LDAP server.
-            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
+PPoossttffiixx SSMMTTPP SSeerrvveerr ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess
 
-The Postfix SMTP server provides a way to specify the properties of SASL
+The Postfix SMTP server supports policies that limit the SASL mechanisms that
-mechanisms that can be made available to the remote SMTP client.
+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
+FROM command. That is because the Postfix SMTP server only knows the remote
-client hostname and IP address, but not the user who controls the remote SMTP
+SMTP client hostname and IP address, but not the user who controls the remote
-client.
+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
+The controlled_envelope_senders table specifies the binding between a sender
-envelope addresses and its their SASL login names:
+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
+  * Postfix SMTP/LMTP client policy - SASL mechanism pprrooppeerrttiieess
-  * Filtering server mechanism names in the Postfix SMTP/LMTP client
+  * 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
+messages via a mail gateway server that requires SASL authentication.
-the example more readable we introduce it in two parts.
+
+    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:
+This default policy leads to authentication failures if the remote server only
-
+offers plaintext authentication mechanisms. In such cases the SMTP client will
-    noanonymous
+log the following error message:
-        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:
 
     SASL authentication failure: No worthy mechs found
 
-The less secure approach to deal with this is to lower the security standards
+The less secure approach is to lower the security standards and permit
-and permit plaintext authentication mechanisms:
+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
+Unfortunately, Postfix needs a second client policy for SASL mechanism
-the remote SMTP server offers - even if the client side was not configured to
+selection. Reason: the Cyrus SASL library will choose the most secure
-handle it! In such cases authentication will definitely fail.
+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
+To prevent this, the Postfix SMTP client can filter the names of the
-mechanism names from the remote SMTP server. Used correctly, the filter hides
+authentication mechanisms from the remote SMTP server. Used correctly, the
-unwanted mechanisms from the Cyrus SASL library, forcing the library to choose
+filter hides unwanted mechanisms from the Cyrus SASL library, forcing the
-from the mechanisms the Postfix filter passes through.
+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:

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
+messages via a mail gateway server that requires SASL authentication.
-the example more readable we introduce it in two parts.
+
+    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

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
+	The access map BCC action is marked "not stable", perhaps
-	people would also expect BCC actions in header/body_checks.
+	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.
 

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

postfix/html/SASL_README.html

@@ -26,21 +26,19 @@ considering. </p>
 
 <h2><a name="intro">How Postfix uses SASL authentication</a></h2>
 
-<p> When an SMTP client connects to an SMTP server, the server needs
+<p> SMTP servers need to decide whether an SMTP client is authorized
-to decide whether that client is authorized to send mail to remote
+to send mail to remote destinations, or only to destinations that
-destinations, or whether the client can send mail only to the
+the server itself is responsible for.  Usually, SMTP servers allow
-destinations that the server itself is responsible for.  Usually,
+mail to remote destinations when the client's IP address is in the
-the SMTP server will allow mail to remote destinations only if the
+"same network" as the server's IP address.  </p>
-client's IP address is in the "same network" as the server's IP
-address.  </p>
 
-<p> Sometimes the SMTP client and server are in different networks,
+<p> Sometimes an SMTP client needs "same network" privileges when
-but the client still needs "same network" privileges.  To address
+it connects from elsewhere.  To address this problem, Postfix
-this problem, Postfix supports SASL authentication (<a href="http://tools.ietf.org/html/rfc4954">RFC 4954</a>,
+supports SASL authentication (<a href="http://tools.ietf.org/html/rfc4954">RFC 4954</a>, formerly RFC 2554).  With
-formerly <a href="http://tools.ietf.org/html/rfc2554">RFC 2554</a>). With this a remote SMTP client can authenticate
+this a remote SMTP client can authenticate to the Postfix SMTP
-to the Postfix SMTP server, and the Postfix SMTP client can
+server, and the Postfix SMTP client can authenticate to a remote
-authenticate to a remote SMTP server.  Once the client is authenticated
+SMTP server.  Once a client is authenticated, a server can give it
-the server can give it "same network" privileges.  </p>
+"same network" privileges.  </p>
 
 <p> 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</a>
 the Postfix SMTP server</a></li>
 
 <li><a href="#smtpd_sasl_security_options">Postfix SMTP Server
-Authentication Policy</a></li>
+policy - SASL mechanism properties</a></li>
 
-<li><a href="#server_sasl_authz">Enabling SASL authorization in the Postfix
+<li><a href="#server_sasl_authz">Enabling SASL authorization in the
-SMTP server</a></li>
+Postfix SMTP server</a></li>
 
-<li><a href="#server_sasl_other">Additional SMTP Server SASL options</a></li>
+<li><a href="#server_sasl_other">Additional SMTP Server SASL
+options</a></li>
 
 </ul></li>
 
@@ -146,7 +145,8 @@ SMTP server</a></li>
 </ul>
 
 
-<h3><a name="server_which">Which SASL Implementations are supported?</a></h3>
+<h3><a name="server_which">Which SASL Implementations are
+supported?</a></h3>
 
 <p> Currently the Postfix SMTP server supports the Cyrus SASL and
 Dovecot SASL implementations. </p>
@@ -453,7 +453,7 @@ locations are <code>/etc/sysconfig/saslauthd</code> or
 
 </blockquote>
 
-<h4><a name="id395661">Using saslauthd with /etc/shadow</a></h4>
+<h4><a name="saslauthd_shadow">Using saslauthd with /etc/shadow</a></h4>
 
 <p> Access to the <code>/etc/shadow</code> system password file
 requires <code>root</code> privileges.  The Postfix SMTP server
@@ -480,7 +480,7 @@ authentication backend <code>/etc/shadow</code> if started like this: </p>
 <p> See section "<a href="#testing_saslauthd">Testing saslauthd
 authentication</a>" for test instructions. </p>
 
-<h4><a name="id395745">Using saslauthd with PAM</a></h4>
+<h4><a name="saslauthd_pam">Using saslauthd with PAM</a></h4>
 
 <p> Cyrus SASL can use the PAM framework to authenticate credentials.
 <code>saslauthd</code> uses the PAM framework when started like
@@ -505,7 +505,7 @@ document. </p>
 <p> See section "<a href="#testing_saslauthd">Testing saslauthd
 authentication</a>" for test instructions. </p>
 
-<h4><a name="id395792">Using saslauthd with an IMAP server</a></h4>
+<h4><a name="saslauthd_imap">Using saslauthd with an IMAP server</a></h4>
 
 <p> <code>saslauthd</code> 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. </p>
 
 <h4><a name="auxprop_sasldb">The sasldb plugin</a></h4>
 
-<p> The sasldb auxprop plugin authenticates credentials stored in a Berkeley
+<p> The sasldb auxprop plugin authenticates SASL clients against
-DB database. The database schema is specific to Cyrus SASL.  The
+credentials that are stored in a Berkeley DB database. The database
-database is usually located at <code>/etc/sasldb2</code>. </p>
+schema is specific to Cyrus SASL.  The database is usually located
+at <code>/etc/sasldb2</code>. </p>
 
 <blockquote>
 
@@ -709,31 +710,25 @@ mechanisms that are applicable for your environment. </p>
 <h4><a name="auxprop_sql">The sql plugin</a></h4>
 
 <p> The sql auxprop plugin is a generic SQL plugin. It provides
-access to credentials stored in a MySQL, a PostgreSQL or a SQLite
+access to credentials stored in a MySQL, PostgreSQL or SQLite
-database. </p>
+database. This plugin requires that SASL client passwords are
-
+stored as plaintext. </p>
-<blockquote>
-
-<strong>Note</strong>
-
-<p> The shared-secret mechanisms (CRAM-MD5, etc.) require that the
-SASL client passwords are stored as plaintext.  </p>
-
-</blockquote>
 
 <blockquote>
 
 <strong>Tip</strong>
 
-<!-- XXX  -->
+<p> If you must store encrypted passwords, see section "<a
-
+href="#saslauthd_pam">Using saslauthd with PAM</a>", and configure
-<p> Use "saslauthd &gt; pam &gt; (pam database module)" to
+PAM to look up the encrypted passwords with, for example, the
-verify encrypted passwords in an SQL database. </p>
+<code>pam_mysql</code> 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.  </p>
 
 </blockquote>
 
-<p> The following example configures libsasl to use the sql plugin and connects
+<p> The following example configures libsasl to use the sql plugin
-it to a PostgreSQL server: </p>
+and connects it to a PostgreSQL server: </p>
 
 <blockquote>
 <pre>
@@ -742,7 +737,8 @@ it to a PostgreSQL server: </p>
     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. </p>
 <h4><a name="auxprop_ldapdb">The ldapdb plugin</a></h4>
 
 <p> The ldapdb auxprop plugin provides access to credentials stored
-in an OpenLDAP LDAP server. It is the only plugin that implements
+in an LDAP server. This plugin requires that SASL client passwords are
-proxy authorization. </p>
+stored as plaintext. </p>
 
-<p> Proxy authorization in this context means: The ldapdb plugin
+<blockquote>
-must SASL authenticate with the OpenLDAP server. The server then
+
-decides if the ldapdb plugin should be authorized to read the
+<strong>Tip</strong>
-authenticating user's password.  Once the ldapdb plugin has gone
+
-through proxy authorization it may proceed and authenticate the
+<p> If you must store encrypted passwords, you can use "<code>saslauthd
-remote SMTP client's credentials. </p>
+-a ldap</code>" to query the LDAP database directly, with appropriate
+configuration in <code>saslauthd.conf</code>. 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.  </p>
+
+</blockquote>
+
+<p> 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.  </p>
 
 <p> 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 <code>slapd</code> server to authenticate and
+once in the LDAP server to authenticate and authorize the ldapdb
-authorize the ldapdb plugin. </p>
+plugin. </p>
 
 <p> This example configures libsasl to use the ldapdb plugin and
-the plugin to connect to an OpenLDAP server: </p>
+the plugin to connect to an LDAP server: </p>
 
 <blockquote>
 <pre>
@@ -975,14 +984,14 @@ plugin to the LDAP server (proxy authorization). </p> </dd>
 <dt>ldapdb_mech</dt>
 
 <dd> <p> The mechanism to authenticate the ldapdb plugin to the
-OpenLDAP slapd server. </p>
+LDAP server. </p>
 
 <blockquote>
 
 <strong>Note</strong>
 
-<p> Specify a mechanism here that is supported by the OpenLDAP slapd
+<p> Specify a mechanism here that is supported by the LDAP server.
-server. </p>
+</p>
 
 </blockquote>
 
@@ -1186,12 +1195,39 @@ clients: </p>
 </pre>
 </blockquote>
 
-<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server
+<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server policy
-Authentication Policy</a></h4>
+- SASL mechanism properties</a></h4>
 
-<p> The Postfix SMTP server provides a way to specify the properties
+<p> The Postfix SMTP server supports policies that limit the SASL
-of SASL mechanisms that can be made available to the remote SMTP
+mechanisms that it makes available to clients, based on the properties
-client.  </p>
+of those mechanisms.  The next two sections give examples of how
+these policies are used. </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th>Property</th> <th>Description</th> </tr>
+
+<tr> <td>noanonymous</td> <td> Don't use mechanisms that permit
+anonymous authentication.  </td> </tr>
+
+<tr> <td>noplaintext</td> <td> Don't use mechanisms that transmit
+unencrypted username and password information.  </td> </tr>
+
+<tr> <td>nodictionary</td> <td> Don't use mechanisms that are
+vulnerable to dictionary attacks. </td> </tr>
+
+<tr> <td>forward_secrecy</td> <td> Require forward secrecy between
+sessions (breaking one session does not break earlier sessions).
+</td> </tr>
+
+<tr> <td>mutual_auth</td> <td> Use only mechanisms that authenticate
+both the client and the server to each other. </td> </tr>
+
+</table>
+
+</blockquote>
 
 <h4><a name="id396877">Unencrypted SMTP session</a></h4>
 
@@ -1216,46 +1252,6 @@ authorization as a properly-authenticated client. </p>
 
 </blockquote>
 
-<p> Postfix can enforce the following policies on SASL authentication
-mechanisms: </p>
-
-<blockquote>
-
-<dl>
-
-<dt>noanonymous</dt>
-
-<dd> <p> Don't use mechanisms that permit anonymous authentication.
-</p> </dd>
-
-<dt>noplaintext</dt>
-
-<dd> <p> Don't use mechanisms that transmit unencrypted username
-and password information.  </p> </dd>
-
-<dt>nodictionary</dt>
-
-<dd> <p> Don't use mechanisms that are vulnerable to dictionary
-attacks. </p>
-
-</dd>
-
-<dt>forward_secrecy</dt>
-
-<dd> <p> Use only mechanisms that support forward secrecy (Dovecot
-SASL only).</p>
-
-</dd>
-
-<dt>mutual_auth</dt>
-
-<dd> <p> Use only mechanisms that authenticate both the client and
-the server to each other. </p> </dd>
-
-</dl>
-
-</blockquote>
-
 <h4><a name="id396969">Encrypted SMTP session (TLS)</a></h4>
 
 <p> A separate parameter controls Postfix SASL mechanism policy
@@ -1307,7 +1303,7 @@ for. Examples of possible SMTP clients authorizations are: </p>
 
 <p> These permissions are not enabled by default. </p>
 
-<h4><a name="id397041">Mail relay authorization</a></h4>
+<h4><a name="server_sasl_authz_relay">Mail relay authorization</a></h4>
 
 <p> The <code><a href="postconf.5.html#permit_sasl_authenticated">permit_sasl_authenticated</a></code> restriction allows
 SASL-authenticated SMTP clients to send mail to remote destinations.
@@ -1326,11 +1322,12 @@ follows: </p>
 </pre>
 </blockquote>
 
-<h4><a name="id397072">Envelope sender address authorization</a></h4>
+<h4><a name="server_sasl_authz_envelope">Envelope sender address
+authorization</a></h4>
 
 <p> 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.  </p>
 
 <p> This changes the moment an SMTP client uses SASL authentication.
@@ -1355,8 +1352,8 @@ use a particular envelope sender address: </p>
 </blockquote>
 
 <p> The <code>controlled_envelope_senders</code> table specifies
-the binding between the sender envelope addresses and its their
+the binding between a sender envelope address and the SASL login
-SASL login names: </p>
+names that own that address: </p>
 
 <blockquote>
 <pre>
@@ -1535,11 +1532,11 @@ the Postfix SMTP/LMTP client</a></li>
 <li><a href="#client_sasl_sender">Configuring sender-dependent SASL
 authentication</a></li>
 
-<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client
+<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client policy
-authentication policy</a></li>
+- SASL mechanism <em>properties</em></a></li>
 
-<li><a href="#client_sasl_filter">Filtering server mechanism names
+<li><a href="#client_sasl_filter">Postfix SMTP/LMTP client policy
-in the Postfix SMTP/LMTP client</a></li>
+- SASL mechanism <em>names</em></a></li>
 
 </ul>
 
@@ -1548,8 +1545,30 @@ Postfix SMTP/LMTP client</a></h3>
 
 <p> 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
+SASL authentication. </p>
-it in two parts. </p>
+
+<blockquote>
+
+<strong> Trouble solving tips: </strong>
+
+<ul>
+
+<li> <p> If your SASL logins fail with "SASL authentication failure:
+No worthy mechs found" in the mail logfile, then see the section
+"<a href="SASL_README.html#client_sasl_policy">Postfix SMTP/LMTP
+client policy - SASL mechanism <em>properties</em></a>".
+
+<li> <p> For a solution to a more obscure class of SASL authentication
+failures, see "<a href="SASL_README.html#client_sasl_filter">Postfix
+SMTP/LMTP client policy - SASL mechanism <em>names</em></a>".
+
+</ul>
+
+</blockquote>
+
+<p> 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.  </p>
 
 <blockquote>
 <pre>
@@ -1713,12 +1732,35 @@ whenever you change the sender_relay table. </p>
 
 </ul>
 
-<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client authentication
+<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client policy -
-policy</a></h3>
+SASL mechanism <em>properties</em></a></h3>
 
 <p> Just like the Postfix SMTP server, the SMTP client has a policy
-that determines which SASL mechanisms are acceptable and which are
+that determines which SASL mechanisms are acceptable, based on their 
-not. </p>
+properties. The next two sections give examples of how these policies
+are used.  </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th>Property</th> <th>Description</th> </tr>
+
+<tr> <td>noanonymous</td> <td> Don't use mechanisms that permit
+anonymous authentication.  </td> </tr>
+
+<tr> <td>noplaintext</td> <td> Don't use mechanisms that transmit
+unencrypted username and password information.  </td> </tr>
+
+<tr> <td>nodictionary</td> <td> Don't use mechanisms that are
+vulnerable to dictionary attacks. </td> </tr>
+
+<tr> <td>mutual_auth</td> <td> Use only mechanisms that authenticate
+both the client and the server to each other. </td> </tr>
+
+</table>
+
+</blockquote>
 
 <h4>Unencrypted SMTP session</h4>
 
@@ -1733,45 +1775,10 @@ mechanism): </p>
 </pre>
 </blockquote>
 
-<p> Postfix can enforce the following policies on SASL authentication
+<p> This default policy leads to authentication failures if the
-mechanisms: </p>
+remote server only offers plaintext authentication mechanisms.  In
-
+such cases the SMTP client will log the following error message:
-<blockquote>
+</p>
-
-<dl>
-
-<dt>noanonymous</dt>
-
-<dd> <p> Don't use mechanisms that permit anonymous authentication.
-</p> </dd>
-
-<dt>noplaintext</dt>
-
-<dd> <p> Don't use mechanisms that transmit unencrypted username
-and password information.  </p> </dd>
-
-<dt>nodictionary</dt>
-
-<dd> <p> Don't use mechanisms that are vulnerable to dictionary
-attacks. </p>
-
-</dd>
-
-<dt>
-<dt>mutual_auth</dt>
-
-<dd> <p> Use only mechanisms that authenticate both the client and
-the server to each other. </p> </dd>
-
-</dl>
-
-</blockquote>
-
-<p> 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: </p>
 
 <blockquote>
 <pre>
@@ -1779,9 +1786,8 @@ SASL authentication failure: No worthy mechs found
 </pre>
 </blockquote>
 
-<p> The less secure approach to deal with this is to lower the
+<p> The less secure approach is to lower the security standards and
-security standards and permit plaintext authentication mechanisms:
+permit plaintext authentication mechanisms: </p>
-</p>
 
 <blockquote>
 <pre>
@@ -1790,9 +1796,6 @@ security standards and permit plaintext authentication mechanisms:
 </pre>
 </blockquote>
 
-<p> Needless to say, sending a username and password over an insecure
-channel is undesirable. </p>
-
 <p> If the remote server supports TLS, you can protect the plaintext
 username and password by turning on TLS in the Postfix SMTP client
 (see: <a href="TLS_README.html">TLS_README</a>), and configuring the client as discussed next.
@@ -1821,19 +1824,20 @@ only over a TLS-encrypted connection: </p>
 </pre>
 </blockquote>
 
-<h3><a name="client_sasl_filter">Filtering server mechanism names in
+<h3><a name="client_sasl_filter">Postfix SMTP/LMTP client policy -
-the Postfix SMTP/LMTP client</a></h3>
+SASL mechanism <em>names</em></a></h3>
 
-<p> Cyrus SASL always attempts to use the most secure authentication
+<p> Unfortunately, Postfix needs a second client policy for SASL
-mechanism that the remote SMTP server offers - even if the client
+mechanism selection.  Reason: the Cyrus SASL library will choose
-side was not configured to handle it! In such cases authentication
+the most secure authentication mechanism that both the SMTP client
-will definitely fail. </p>
+and server implement - even if one of the parties was not configured
+for that mechanism. </p>
 
-<p> To prevent this, the Postfix SMTP client can filter the list
+<p> To prevent this, the Postfix SMTP client can filter the names
-of authentication mechanism names from the remote SMTP server.  Used
+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.  </p>
+Postfix SMTP client filter passes through.  </p>
 
 <p> The following example filters out everything but the mechanisms
 <code>PLAIN</code> and <code>LOGIN</code>: </p>

postfix/html/SOHO_README.html

@@ -219,8 +219,30 @@ Postfix SMTP/LMTP client</a></h2>
 
 <p> 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
+SASL authentication. </p>
-it in two parts. </p>
+
+<blockquote>
+
+<strong> Trouble solving tips: </strong>
+
+<ul>
+
+<li> <p> If your SASL logins fail with "SASL authentication failure:
+No worthy mechs found" in the mail logfile, then see the section
+"<a href="SASL_README.html#client_sasl_policy">Postfix SMTP/LMTP
+client policy - SASL mechanism <em>properties</em></a>".
+
+<li> <p> For a solution to a more obscure class of SASL authentication
+failures, see "<a href="SASL_README.html#client_sasl_filter">Postfix
+SMTP/LMTP client policy - SASL mechanism <em>names</em></a>".
+
+</ul>
+
+</blockquote>
+
+<p> 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.  </p>
 
 <blockquote>
 <pre>

postfix/html/postmulti.1.html

@@ -10,13 +10,19 @@ POSTMULTI(1)                                                      POSTMULTI(1)
        postmulti - Postfix multi-instance manager
 
 <b>SYNOPSIS</b>
+       <b>ENABLING MULTI-INSTANCE MANAGEMENT:</b>
+
+       <b>postmulti -e init</b> [<b>-v</b>]
+
+       <b>ITERATOR MODE:</b>
+
        <b>postmulti -l</b> [<b>-aRv</b>] [<b>-g</b> <i>group</i>] [<b>-i</b> <i>name</i>]
 
        <b>postmulti -p</b> [<b>-av</b>] [<b>-g</b> <i>group</i>] [<b>-i</b> <i>name</i>] <i>command...</i>
 
        <b>postmulti -x</b> [<b>-aRv</b>] [<b>-g</b> <i>group</i>] [<b>-i</b> <i>name</i>] <i>command...</i>
 
-       <b>postmulti -e init</b> [<b>-v</b>]
+       <b>LIFE-CYCLE MANAGEMENT:</b>
 
        <b>postmulti -e create</b> [<b>-av</b>] [<b>-g</b> <i>group</i>] [<b>-i</b> <i>name</i>] [<b>-G</b> <i>group</i>]
        [<b>-I</b> <i>name</i>] [<i>param=value</i> ...]

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]

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] ";

postfix/proto/SASL_README.html

@@ -26,21 +26,19 @@ considering. </p>
 
 <h2><a name="intro">How Postfix uses SASL authentication</a></h2>
 
-<p> When an SMTP client connects to an SMTP server, the server needs
+<p> SMTP servers need to decide whether an SMTP client is authorized
-to decide whether that client is authorized to send mail to remote
+to send mail to remote destinations, or only to destinations that
-destinations, or whether the client can send mail only to the
+the server itself is responsible for.  Usually, SMTP servers allow
-destinations that the server itself is responsible for.  Usually,
+mail to remote destinations when the client's IP address is in the
-the SMTP server will allow mail to remote destinations only if the
+"same network" as the server's IP address.  </p>
-client's IP address is in the "same network" as the server's IP
-address.  </p>
 
-<p> Sometimes the SMTP client and server are in different networks,
+<p> Sometimes an SMTP client needs "same network" privileges when
-but the client still needs "same network" privileges.  To address
+it connects from elsewhere.  To address this problem, Postfix
-this problem, Postfix supports SASL authentication (RFC 4954,
+supports SASL authentication (RFC 4954, formerly RFC 2554).  With
-formerly RFC 2554). With this a remote SMTP client can authenticate
+this a remote SMTP client can authenticate to the Postfix SMTP
-to the Postfix SMTP server, and the Postfix SMTP client can
+server, and the Postfix SMTP client can authenticate to a remote
-authenticate to a remote SMTP server.  Once the client is authenticated
+SMTP server.  Once a client is authenticated, a server can give it
-the server can give it "same network" privileges.  </p>
+"same network" privileges.  </p>
 
 <p> 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</a>
 the Postfix SMTP server</a></li>
 
 <li><a href="#smtpd_sasl_security_options">Postfix SMTP Server
-Authentication Policy</a></li>
+policy - SASL mechanism properties</a></li>
 
-<li><a href="#server_sasl_authz">Enabling SASL authorization in the Postfix
+<li><a href="#server_sasl_authz">Enabling SASL authorization in the
-SMTP server</a></li>
+Postfix SMTP server</a></li>
 
-<li><a href="#server_sasl_other">Additional SMTP Server SASL options</a></li>
+<li><a href="#server_sasl_other">Additional SMTP Server SASL
+options</a></li>
 
 </ul></li>
 
@@ -146,7 +145,8 @@ SMTP server</a></li>
 </ul>
 
 
-<h3><a name="server_which">Which SASL Implementations are supported?</a></h3>
+<h3><a name="server_which">Which SASL Implementations are
+supported?</a></h3>
 
 <p> Currently the Postfix SMTP server supports the Cyrus SASL and
 Dovecot SASL implementations. </p>
@@ -453,7 +453,7 @@ locations are <code>/etc/sysconfig/saslauthd</code> or
 
 </blockquote>
 
-<h4><a name="id395661">Using saslauthd with /etc/shadow</a></h4>
+<h4><a name="saslauthd_shadow">Using saslauthd with /etc/shadow</a></h4>
 
 <p> Access to the <code>/etc/shadow</code> system password file
 requires <code>root</code> privileges.  The Postfix SMTP server
@@ -480,7 +480,7 @@ authentication backend <code>/etc/shadow</code> if started like this: </p>
 <p> See section "<a href="#testing_saslauthd">Testing saslauthd
 authentication</a>" for test instructions. </p>
 
-<h4><a name="id395745">Using saslauthd with PAM</a></h4>
+<h4><a name="saslauthd_pam">Using saslauthd with PAM</a></h4>
 
 <p> Cyrus SASL can use the PAM framework to authenticate credentials.
 <code>saslauthd</code> uses the PAM framework when started like
@@ -505,7 +505,7 @@ document. </p>
 <p> See section "<a href="#testing_saslauthd">Testing saslauthd
 authentication</a>" for test instructions. </p>
 
-<h4><a name="id395792">Using saslauthd with an IMAP server</a></h4>
+<h4><a name="saslauthd_imap">Using saslauthd with an IMAP server</a></h4>
 
 <p> <code>saslauthd</code> 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. </p>
 
 <h4><a name="auxprop_sasldb">The sasldb plugin</a></h4>
 
-<p> The sasldb auxprop plugin authenticates credentials stored in a Berkeley
+<p> The sasldb auxprop plugin authenticates SASL clients against
-DB database. The database schema is specific to Cyrus SASL.  The
+credentials that are stored in a Berkeley DB database. The database
-database is usually located at <code>/etc/sasldb2</code>. </p>
+schema is specific to Cyrus SASL.  The database is usually located
+at <code>/etc/sasldb2</code>. </p>
 
 <blockquote>
 
@@ -709,31 +710,25 @@ mechanisms that are applicable for your environment. </p>
 <h4><a name="auxprop_sql">The sql plugin</a></h4>
 
 <p> The sql auxprop plugin is a generic SQL plugin. It provides
-access to credentials stored in a MySQL, a PostgreSQL or a SQLite
+access to credentials stored in a MySQL, PostgreSQL or SQLite
-database. </p>
+database. This plugin requires that SASL client passwords are
-
+stored as plaintext. </p>
-<blockquote>
-
-<strong>Note</strong>
-
-<p> The shared-secret mechanisms (CRAM-MD5, etc.) require that the
-SASL client passwords are stored as plaintext.  </p>
-
-</blockquote>
 
 <blockquote>
 
 <strong>Tip</strong>
 
-<!-- XXX  -->
+<p> If you must store encrypted passwords, see section "<a
-
+href="#saslauthd_pam">Using saslauthd with PAM</a>", and configure
-<p> Use "saslauthd &gt; pam &gt; (pam database module)" to
+PAM to look up the encrypted passwords with, for example, the
-verify encrypted passwords in an SQL database. </p>
+<code>pam_mysql</code> 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.  </p>
 
 </blockquote>
 
-<p> The following example configures libsasl to use the sql plugin and connects
+<p> The following example configures libsasl to use the sql plugin
-it to a PostgreSQL server: </p>
+and connects it to a PostgreSQL server: </p>
 
 <blockquote>
 <pre>
@@ -742,7 +737,8 @@ it to a PostgreSQL server: </p>
     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. </p>
 <h4><a name="auxprop_ldapdb">The ldapdb plugin</a></h4>
 
 <p> The ldapdb auxprop plugin provides access to credentials stored
-in an OpenLDAP LDAP server. It is the only plugin that implements
+in an LDAP server. This plugin requires that SASL client passwords are
-proxy authorization. </p>
+stored as plaintext. </p>
 
-<p> Proxy authorization in this context means: The ldapdb plugin
+<blockquote>
-must SASL authenticate with the OpenLDAP server. The server then
+
-decides if the ldapdb plugin should be authorized to read the
+<strong>Tip</strong>
-authenticating user's password.  Once the ldapdb plugin has gone
+
-through proxy authorization it may proceed and authenticate the
+<p> If you must store encrypted passwords, you can use "<code>saslauthd
-remote SMTP client's credentials. </p>
+-a ldap</code>" to query the LDAP database directly, with appropriate
+configuration in <code>saslauthd.conf</code>. 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.  </p>
+
+</blockquote>
+
+<p> 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.  </p>
 
 <p> 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 <code>slapd</code> server to authenticate and
+once in the LDAP server to authenticate and authorize the ldapdb
-authorize the ldapdb plugin. </p>
+plugin. </p>
 
 <p> This example configures libsasl to use the ldapdb plugin and
-the plugin to connect to an OpenLDAP server: </p>
+the plugin to connect to an LDAP server: </p>
 
 <blockquote>
 <pre>
@@ -975,14 +984,14 @@ plugin to the LDAP server (proxy authorization). </p> </dd>
 <dt>ldapdb_mech</dt>
 
 <dd> <p> The mechanism to authenticate the ldapdb plugin to the
-OpenLDAP slapd server. </p>
+LDAP server. </p>
 
 <blockquote>
 
 <strong>Note</strong>
 
-<p> Specify a mechanism here that is supported by the OpenLDAP slapd
+<p> Specify a mechanism here that is supported by the LDAP server.
-server. </p>
+</p>
 
 </blockquote>
 
@@ -1186,12 +1195,39 @@ clients: </p>
 </pre>
 </blockquote>
 
-<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server
+<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server policy
-Authentication Policy</a></h4>
+- SASL mechanism properties</a></h4>
 
-<p> The Postfix SMTP server provides a way to specify the properties
+<p> The Postfix SMTP server supports policies that limit the SASL
-of SASL mechanisms that can be made available to the remote SMTP
+mechanisms that it makes available to clients, based on the properties
-client.  </p>
+of those mechanisms.  The next two sections give examples of how
+these policies are used. </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th>Property</th> <th>Description</th> </tr>
+
+<tr> <td>noanonymous</td> <td> Don't use mechanisms that permit
+anonymous authentication.  </td> </tr>
+
+<tr> <td>noplaintext</td> <td> Don't use mechanisms that transmit
+unencrypted username and password information.  </td> </tr>
+
+<tr> <td>nodictionary</td> <td> Don't use mechanisms that are
+vulnerable to dictionary attacks. </td> </tr>
+
+<tr> <td>forward_secrecy</td> <td> Require forward secrecy between
+sessions (breaking one session does not break earlier sessions).
+</td> </tr>
+
+<tr> <td>mutual_auth</td> <td> Use only mechanisms that authenticate
+both the client and the server to each other. </td> </tr>
+
+</table>
+
+</blockquote>
 
 <h4><a name="id396877">Unencrypted SMTP session</a></h4>
 
@@ -1216,46 +1252,6 @@ authorization as a properly-authenticated client. </p>
 
 </blockquote>
 
-<p> Postfix can enforce the following policies on SASL authentication
-mechanisms: </p>
-
-<blockquote>
-
-<dl>
-
-<dt>noanonymous</dt>
-
-<dd> <p> Don't use mechanisms that permit anonymous authentication.
-</p> </dd>
-
-<dt>noplaintext</dt>
-
-<dd> <p> Don't use mechanisms that transmit unencrypted username
-and password information.  </p> </dd>
-
-<dt>nodictionary</dt>
-
-<dd> <p> Don't use mechanisms that are vulnerable to dictionary
-attacks. </p>
-
-</dd>
-
-<dt>forward_secrecy</dt>
-
-<dd> <p> Use only mechanisms that support forward secrecy (Dovecot
-SASL only).</p>
-
-</dd>
-
-<dt>mutual_auth</dt>
-
-<dd> <p> Use only mechanisms that authenticate both the client and
-the server to each other. </p> </dd>
-
-</dl>
-
-</blockquote>
-
 <h4><a name="id396969">Encrypted SMTP session (TLS)</a></h4>
 
 <p> A separate parameter controls Postfix SASL mechanism policy
@@ -1307,7 +1303,7 @@ for. Examples of possible SMTP clients authorizations are: </p>
 
 <p> These permissions are not enabled by default. </p>
 
-<h4><a name="id397041">Mail relay authorization</a></h4>
+<h4><a name="server_sasl_authz_relay">Mail relay authorization</a></h4>
 
 <p> The <code>permit_sasl_authenticated</code> restriction allows
 SASL-authenticated SMTP clients to send mail to remote destinations.
@@ -1326,11 +1322,12 @@ follows: </p>
 </pre>
 </blockquote>
 
-<h4><a name="id397072">Envelope sender address authorization</a></h4>
+<h4><a name="server_sasl_authz_envelope">Envelope sender address
+authorization</a></h4>
 
 <p> 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.  </p>
 
 <p> This changes the moment an SMTP client uses SASL authentication.
@@ -1355,8 +1352,8 @@ use a particular envelope sender address: </p>
 </blockquote>
 
 <p> The <code>controlled_envelope_senders</code> table specifies
-the binding between the sender envelope addresses and its their
+the binding between a sender envelope address and the SASL login
-SASL login names: </p>
+names that own that address: </p>
 
 <blockquote>
 <pre>
@@ -1535,11 +1532,11 @@ the Postfix SMTP/LMTP client</a></li>
 <li><a href="#client_sasl_sender">Configuring sender-dependent SASL
 authentication</a></li>
 
-<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client
+<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client policy
-authentication policy</a></li>
+- SASL mechanism <em>properties</em></a></li>
 
-<li><a href="#client_sasl_filter">Filtering server mechanism names
+<li><a href="#client_sasl_filter">Postfix SMTP/LMTP client policy
-in the Postfix SMTP/LMTP client</a></li>
+- SASL mechanism <em>names</em></a></li>
 
 </ul>
 
@@ -1548,8 +1545,30 @@ Postfix SMTP/LMTP client</a></h3>
 
 <p> 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
+SASL authentication. </p>
-it in two parts. </p>
+
+<blockquote>
+
+<strong> Trouble solving tips: </strong>
+
+<ul>
+
+<li> <p> If your SASL logins fail with "SASL authentication failure:
+No worthy mechs found" in the mail logfile, then see the section
+"<a href="SASL_README.html#client_sasl_policy">Postfix SMTP/LMTP
+client policy - SASL mechanism <em>properties</em></a>".
+
+<li> <p> For a solution to a more obscure class of SASL authentication
+failures, see "<a href="SASL_README.html#client_sasl_filter">Postfix
+SMTP/LMTP client policy - SASL mechanism <em>names</em></a>".
+
+</ul>
+
+</blockquote>
+
+<p> 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.  </p>
 
 <blockquote>
 <pre>
@@ -1713,12 +1732,35 @@ whenever you change the sender_relay table. </p>
 
 </ul>
 
-<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client authentication
+<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client policy -
-policy</a></h3>
+SASL mechanism <em>properties</em></a></h3>
 
 <p> Just like the Postfix SMTP server, the SMTP client has a policy
-that determines which SASL mechanisms are acceptable and which are
+that determines which SASL mechanisms are acceptable, based on their 
-not. </p>
+properties. The next two sections give examples of how these policies
+are used.  </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th>Property</th> <th>Description</th> </tr>
+
+<tr> <td>noanonymous</td> <td> Don't use mechanisms that permit
+anonymous authentication.  </td> </tr>
+
+<tr> <td>noplaintext</td> <td> Don't use mechanisms that transmit
+unencrypted username and password information.  </td> </tr>
+
+<tr> <td>nodictionary</td> <td> Don't use mechanisms that are
+vulnerable to dictionary attacks. </td> </tr>
+
+<tr> <td>mutual_auth</td> <td> Use only mechanisms that authenticate
+both the client and the server to each other. </td> </tr>
+
+</table>
+
+</blockquote>
 
 <h4>Unencrypted SMTP session</h4>
 
@@ -1733,45 +1775,10 @@ mechanism): </p>
 </pre>
 </blockquote>
 
-<p> Postfix can enforce the following policies on SASL authentication
+<p> This default policy leads to authentication failures if the
-mechanisms: </p>
+remote server only offers plaintext authentication mechanisms.  In
-
+such cases the SMTP client will log the following error message:
-<blockquote>
+</p>
-
-<dl>
-
-<dt>noanonymous</dt>
-
-<dd> <p> Don't use mechanisms that permit anonymous authentication.
-</p> </dd>
-
-<dt>noplaintext</dt>
-
-<dd> <p> Don't use mechanisms that transmit unencrypted username
-and password information.  </p> </dd>
-
-<dt>nodictionary</dt>
-
-<dd> <p> Don't use mechanisms that are vulnerable to dictionary
-attacks. </p>
-
-</dd>
-
-<dt>
-<dt>mutual_auth</dt>
-
-<dd> <p> Use only mechanisms that authenticate both the client and
-the server to each other. </p> </dd>
-
-</dl>
-
-</blockquote>
-
-<p> 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: </p>
 
 <blockquote>
 <pre>
@@ -1779,9 +1786,8 @@ SASL authentication failure: No worthy mechs found
 </pre>
 </blockquote>
 
-<p> The less secure approach to deal with this is to lower the
+<p> The less secure approach is to lower the security standards and
-security standards and permit plaintext authentication mechanisms:
+permit plaintext authentication mechanisms: </p>
-</p>
 
 <blockquote>
 <pre>
@@ -1790,9 +1796,6 @@ security standards and permit plaintext authentication mechanisms:
 </pre>
 </blockquote>
 
-<p> Needless to say, sending a username and password over an insecure
-channel is undesirable. </p>
-
 <p> 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: </p>
 </pre>
 </blockquote>
 
-<h3><a name="client_sasl_filter">Filtering server mechanism names in
+<h3><a name="client_sasl_filter">Postfix SMTP/LMTP client policy -
-the Postfix SMTP/LMTP client</a></h3>
+SASL mechanism <em>names</em></a></h3>
 
-<p> Cyrus SASL always attempts to use the most secure authentication
+<p> Unfortunately, Postfix needs a second client policy for SASL
-mechanism that the remote SMTP server offers - even if the client
+mechanism selection.  Reason: the Cyrus SASL library will choose
-side was not configured to handle it! In such cases authentication
+the most secure authentication mechanism that both the SMTP client
-will definitely fail. </p>
+and server implement - even if one of the parties was not configured
+for that mechanism. </p>
 
-<p> To prevent this, the Postfix SMTP client can filter the list
+<p> To prevent this, the Postfix SMTP client can filter the names
-of authentication mechanism names from the remote SMTP server.  Used
+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.  </p>
+Postfix SMTP client filter passes through.  </p>
 
 <p> The following example filters out everything but the mechanisms
 <code>PLAIN</code> and <code>LOGIN</code>: </p>

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

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

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 <sys_defs.h>
+#include <strings.h>
+
+/* Utility library. */
+
+#include <msg.h>
+#include <mymalloc.h>
+#include <vstring.h>
+#include <split_at.h>
+
+/* Global library. */
+
+#include <mail_params.h>
+#include <strip_addr.h>
+#include <stringops.h>
+#include <bounce.h>
+#include <split_addr.h>
+#include <canon_addr.h>
+
+/* 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);
+}

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 =
+	if (STR(why->status)[0] == '4')
-	    (STR(why->status)[0] == '4' ?
+	    deliver_status =
-	     defer_append : bounce_append)
+		defer_append(BOUNCE_FLAGS(state.request),
-	    (BOUNCE_FLAGS(state.request),
+			     BOUNCE_ATTR(state.msg_attr));
-	     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;

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),
+	/* Account for possible owner- sender address override. */
-			      BOUNCE_ATTR(state.msg_attr)));
+	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 =
+	if (STR(why->status)[0] == '4')
-	    (STR(why->status)[0] == '4' ?
+	    deliver_status =
-	     defer_append : bounce_append)
+		defer_append(BOUNCE_FLAGS(state.request),
-	    (BOUNCE_FLAGS(state.request),
+			     BOUNCE_ATTR(state.msg_attr));
-	     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),

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

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;
+	dsb_simple(state.msg_attr.why, "5.4.6", "mail forwarding loop for %s",
-
-	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",
 		   state.msg_attr.rcpt.address);
-	if (canon_owner) {
+	/* Account for possible owner- sender address override. */
-	    rcpt_stat = bounce_one(BOUNCE_FLAGS(state.request),
+	return (bounce_workaround(state));
-				   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);
     }
 
     /*

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]

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,