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.
H\bHo\bow\bw P\bPo\bos\bst\btf\bfi\bix\bx u\bus\bse\bes\bs S\bSA\bAS\bSL\bL a\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bti\bio\bon\bn
-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
* 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
T\bTh\bhe\be s\bsa\bas\bsl\bld\bdb\bb p\bpl\blu\bug\bgi\bin\bn
-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.
N\bNo\bot\bte\be
T\bTh\bhe\be s\bsq\bql\bl p\bpl\blu\bug\bgi\bin\bn
The sql auxprop plugin is a generic SQL plugin. It provides access to
-credentials stored in a MySQL, a PostgreSQL or a SQLite database.
-
- N\bNo\bot\bte\be
-
- 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.
T\bTi\bip\bp
- 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:
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'
T\bTh\bhe\be l\bld\bda\bap\bpd\bdb\bb p\bpl\blu\bug\bgi\bin\bn
-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.
+
+ T\bTi\bip\bp
-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
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.
N\bNo\bot\bte\be
- 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
250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5
...
-P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP S\bSe\ber\brv\bve\ber\br A\bAu\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bti\bio\bon\bn P\bPo\bol\bli\bic\bcy\by
-
-The Postfix SMTP server provides a way to specify the properties of SASL
-mechanisms that can be made available to the remote SMTP client.
+P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP S\bSe\ber\brv\bve\ber\br p\bpo\bol\bli\bic\bcy\by -\b- S\bSA\bAS\bSL\bL m\bme\bec\bch\bha\ban\bni\bis\bsm\bm p\bpr\bro\bop\bpe\ber\brt\bti\bie\bes\bs
+
+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.
+
+ _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b
+ |P\bPr\bro\bop\bpe\ber\brt\bty\by |D\bDe\bes\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |noanonymous |Don't use mechanisms that permit anonymous |
+ | |authentication. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |noplaintext |Don't use mechanisms that transmit unencrypted username |
+ | |and password information. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |nodictionary |Don't use mechanisms that are vulnerable to dictionary |
+ | |attacks. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |forward_secrecy|Require forward secrecy between sessions (breaking one |
+ | |session does not break earlier sessions). |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |mutual_auth |Use only mechanisms that authenticate both the client and|
+ | |the server to each other. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
U\bUn\bne\ben\bnc\bcr\bry\byp\bpt\bte\bed\bd S\bSM\bMT\bTP\bP s\bse\bes\bss\bsi\bio\bon\bn
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.
-
E\bEn\bnc\bcr\bry\byp\bpt\bte\bed\bd S\bSM\bMT\bTP\bP s\bse\bes\bss\bsi\bio\bon\bn (\b(T\bTL\bLS\bS)\b)
A separate parameter controls Postfix SASL mechanism policy during a TLS-
E\bEn\bnv\bve\bel\blo\bop\bpe\be s\bse\ben\bnd\bde\ber\br a\bad\bdd\bdr\bre\bes\bss\bs a\bau\but\bth\bho\bor\bri\biz\bza\bat\bti\bio\bon\bn
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
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)
* 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 p\bpr\bro\bop\bpe\ber\brt\bti\bie\bes\bs
+ * Postfix SMTP/LMTP client policy - SASL mechanism n\bna\bam\bme\bes\bs
E\bEn\bna\bab\bbl\bli\bin\bng\bg S\bSA\bAS\bSL\bL a\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bti\bio\bon\bn i\bin\bn t\bth\bhe\be P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP/\b/L\bLM\bMT\bTP\bP c\bcl\bli\bie\ben\bnt\bt
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.
+
+ T\bTr\bro\bou\bub\bbl\ble\be s\bso\bol\blv\bvi\bin\bng\bg t\bti\bip\bps\bs:\b:
+
+ * 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 p\bpr\bro\bop\bpe\ber\brt\bti\bie\bes\bs".
+
+ * For a solution to a more obscure class of SASL authentication failures,
+ see "Postfix SMTP/LMTP client policy - SASL mechanism n\bna\bam\bme\bes\bs".
+
+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
* Execute the command "postmap /etc/postfix/sender_relay" whenever you change
the sender_relay table.
-P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP/\b/L\bLM\bMT\bTP\bP c\bcl\bli\bie\ben\bnt\bt a\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bti\bio\bon\bn p\bpo\bol\bli\bic\bcy\by
+P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP/\b/L\bLM\bMT\bTP\bP c\bcl\bli\bie\ben\bnt\bt p\bpo\bol\bli\bic\bcy\by -\b- S\bSA\bAS\bSL\bL m\bme\bec\bch\bha\ban\bni\bis\bsm\bm p\bpr\bro\bop\bpe\ber\brt\bti\bie\bes\bs
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.
+
+ _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b
+ |P\bPr\bro\bop\bpe\ber\brt\bty\by |D\bDe\bes\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |noanonymous |Don't use mechanisms that permit anonymous authentication. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |noplaintext |Don't use mechanisms that transmit unencrypted username and|
+ | |password information. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |nodictionary|Don't use mechanisms that are vulnerable to dictionary |
+ | |attacks. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |mutual_auth |Use only mechanisms that authenticate both the client and |
+ | |the server to each other. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
U\bUn\bne\ben\bnc\bcr\bry\byp\bpt\bte\bed\bd S\bSM\bMT\bTP\bP s\bse\bes\bss\bsi\bio\bon\bn
/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.
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
-F\bFi\bil\blt\bte\ber\bri\bin\bng\bg s\bse\ber\brv\bve\ber\br m\bme\bec\bch\bha\ban\bni\bis\bsm\bm n\bna\bam\bme\bes\bs i\bin\bn t\bth\bhe\be P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP/\b/L\bLM\bMT\bTP\bP c\bcl\bli\bie\ben\bnt\bt
+P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP/\b/L\bLM\bMT\bTP\bP c\bcl\bli\bie\ben\bnt\bt p\bpo\bol\bli\bic\bcy\by -\b- S\bSA\bAS\bSL\bL m\bme\bec\bch\bha\ban\bni\bis\bsm\bm n\bna\bam\bme\bes\bs
-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:
E\bEn\bna\bab\bbl\bli\bin\bng\bg S\bSA\bAS\bSL\bL a\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bti\bio\bon\bn i\bin\bn t\bth\bhe\be P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP/\b/L\bLM\bMT\bTP\bP c\bcl\bli\bie\ben\bnt\bt
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.
+
+ T\bTr\bro\bou\bub\bbl\ble\be s\bso\bol\blv\bvi\bin\bng\bg t\bti\bip\bps\bs:\b:
+
+ * 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 p\bpr\bro\bop\bpe\ber\brt\bti\bie\bes\bs".
+
+ * For a solution to a more obscure class of SASL authentication failures,
+ see "Postfix SMTP/LMTP client policy - SASL mechanism n\bna\bam\bme\bes\bs".
+
+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
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
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.
EOF
}
- # Postfix 2.7.
+ # Postfix 2.8.
# Add missing postscreen service to master.cf.
grep '^#*smtp.*postscreen' $config_directory/master.cf >/dev/null || {
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 || {
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 || {
<h2><a name="intro">How Postfix uses SASL authentication</a></h2>
-<p> 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. </p>
-
-<p> 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 (<a href="http://tools.ietf.org/html/rfc4954">RFC 4954</a>,
-formerly <a href="http://tools.ietf.org/html/rfc2554">RFC 2554</a>). 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. </p>
+<p> 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. </p>
+
+<p> Sometimes an SMTP client needs "same network" privileges when
+it connects from elsewhere. To address this problem, Postfix
+supports SASL authentication (<a href="http://tools.ietf.org/html/rfc4954">RFC 4954</a>, 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. </p>
<p> Postfix does not implement SASL itself, but instead uses existing
implementations as building blocks. This means that some SASL-related
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
-SMTP server</a></li>
+<li><a href="#server_sasl_authz">Enabling SASL authorization in the
+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>
</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>
</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
<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
<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,
<h4><a name="auxprop_sasldb">The sasldb plugin</a></h4>
-<p> 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 <code>/etc/sasldb2</code>. </p>
+<p> 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 <code>/etc/sasldb2</code>. </p>
<blockquote>
<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
-database. </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>
+access to credentials stored in a MySQL, PostgreSQL or SQLite
+database. This plugin requires that SASL client passwords are
+stored as plaintext. </p>
<blockquote>
<strong>Tip</strong>
-<!-- XXX -->
-
-<p> Use "saslauthd > pam > (pam database module)" to
-verify encrypted passwords in an SQL database. </p>
+<p> If you must store encrypted passwords, see section "<a
+href="#saslauthd_pam">Using saslauthd with PAM</a>", and configure
+PAM to look up the encrypted passwords with, for example, the
+<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
-it to a PostgreSQL server: </p>
+<p> The following example configures libsasl to use the sql plugin
+and connects it to a PostgreSQL server: </p>
<blockquote>
<pre>
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'
<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
-proxy authorization. </p>
+in an LDAP server. This plugin requires that SASL client passwords are
+stored as plaintext. </p>
+
+<blockquote>
+
+<strong>Tip</strong>
-<p> 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. </p>
+<p> If you must store encrypted passwords, you can use "<code>saslauthd
+-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
-authorize the ldapdb plugin. </p>
+once in the LDAP server to authenticate and authorize the ldapdb
+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>
<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
-server. </p>
+<p> Specify a mechanism here that is supported by the LDAP server.
+</p>
</blockquote>
</pre>
</blockquote>
-<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server
-Authentication Policy</a></h4>
+<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server policy
+- SASL mechanism properties</a></h4>
+
+<p> 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. </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th>Property</th> <th>Description</th> </tr>
-<p> The Postfix SMTP server provides a way to specify the properties
-of SASL mechanisms that can be made available to the remote SMTP
-client. </p>
+<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>
</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
<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.
</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.
</blockquote>
<p> The <code>controlled_envelope_senders</code> table specifies
-the binding between the sender envelope addresses and its their
-SASL login names: </p>
+the binding between a sender envelope address and the SASL login
+names that own that address: </p>
<blockquote>
<pre>
<li><a href="#client_sasl_sender">Configuring sender-dependent SASL
authentication</a></li>
-<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client
-authentication policy</a></li>
+<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client policy
+- SASL mechanism <em>properties</em></a></li>
-<li><a href="#client_sasl_filter">Filtering server mechanism names
-in the Postfix SMTP/LMTP client</a></li>
+<li><a href="#client_sasl_filter">Postfix SMTP/LMTP client policy
+- SASL mechanism <em>names</em></a></li>
</ul>
<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
-it in two parts. </p>
+SASL authentication. </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>
</ul>
-<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client authentication
-policy</a></h3>
+<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client policy -
+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
-not. </p>
-
-<h4>Unencrypted SMTP session</h4>
-
-<p> The default policy is stricter than that of the Postfix SMTP
-server - plaintext mechanisms are not allowed (nor is any anonymous
-mechanism): </p>
-
-<blockquote>
-<pre>
-/etc/postfix/<a href="postconf.5.html">main.cf</a>:
- <a href="postconf.5.html#smtp_sasl_security_options">smtp_sasl_security_options</a> = noplaintext, noanonymous
-</pre>
-</blockquote>
-
-<p> Postfix can enforce the following policies on SASL authentication
-mechanisms: </p>
+that determines which SASL mechanisms are acceptable, based on their
+properties. The next two sections give examples of how these policies
+are used. </p>
<blockquote>
-<dl>
-
-<dt>noanonymous</dt>
+<table border="1">
-<dd> <p> Don't use mechanisms that permit anonymous authentication.
-</p> </dd>
+<tr> <th>Property</th> <th>Description</th> </tr>
-<dt>noplaintext</dt>
+<tr> <td>noanonymous</td> <td> Don't use mechanisms that permit
+anonymous authentication. </td> </tr>
-<dd> <p> Don't use mechanisms that transmit unencrypted username
-and password information. </p> </dd>
+<tr> <td>noplaintext</td> <td> Don't use mechanisms that transmit
+unencrypted username and password information. </td> </tr>
-<dt>nodictionary</dt>
+<tr> <td>nodictionary</td> <td> Don't use mechanisms that are
+vulnerable to dictionary attacks. </td> </tr>
-<dd> <p> Don't use mechanisms that are vulnerable to dictionary
-attacks. </p>
+<tr> <td>mutual_auth</td> <td> Use only mechanisms that authenticate
+both the client and the server to each other. </td> </tr>
-</dd>
+</table>
-<dt>
-<dt>mutual_auth</dt>
+</blockquote>
-<dd> <p> Use only mechanisms that authenticate both the client and
-the server to each other. </p> </dd>
+<h4>Unencrypted SMTP session</h4>
-</dl>
+<p> The default policy is stricter than that of the Postfix SMTP
+server - plaintext mechanisms are not allowed (nor is any anonymous
+mechanism): </p>
+<blockquote>
+<pre>
+/etc/postfix/<a href="postconf.5.html">main.cf</a>:
+ <a href="postconf.5.html#smtp_sasl_security_options">smtp_sasl_security_options</a> = noplaintext, noanonymous
+</pre>
</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>
+<p> 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:
+</p>
<blockquote>
<pre>
</pre>
</blockquote>
-<p> The less secure approach to deal with this is to lower the
-security standards and permit plaintext authentication mechanisms:
-</p>
+<p> The less secure approach is to lower the security standards and
+permit plaintext authentication mechanisms: </p>
<blockquote>
<pre>
</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.
</pre>
</blockquote>
-<h3><a name="client_sasl_filter">Filtering server mechanism names in
-the Postfix SMTP/LMTP client</a></h3>
+<h3><a name="client_sasl_filter">Postfix SMTP/LMTP client policy -
+SASL mechanism <em>names</em></a></h3>
-<p> 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. </p>
+<p> 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. </p>
-<p> To prevent this, the Postfix SMTP client can filter the list
-of authentication mechanism names from the remote SMTP server. Used
+<p> 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. </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>
<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
-it in two parts. </p>
+SASL authentication. </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>
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> ...]
.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]
\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]
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] ";
<h2><a name="intro">How Postfix uses SASL authentication</a></h2>
-<p> 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. </p>
-
-<p> 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. </p>
+<p> 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. </p>
+
+<p> 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. </p>
<p> Postfix does not implement SASL itself, but instead uses existing
implementations as building blocks. This means that some SASL-related
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
-SMTP server</a></li>
+<li><a href="#server_sasl_authz">Enabling SASL authorization in the
+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>
</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>
</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
<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
<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,
<h4><a name="auxprop_sasldb">The sasldb plugin</a></h4>
-<p> 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 <code>/etc/sasldb2</code>. </p>
+<p> 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 <code>/etc/sasldb2</code>. </p>
<blockquote>
<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
-database. </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>
+access to credentials stored in a MySQL, PostgreSQL or SQLite
+database. This plugin requires that SASL client passwords are
+stored as plaintext. </p>
<blockquote>
<strong>Tip</strong>
-<!-- XXX -->
-
-<p> Use "saslauthd > pam > (pam database module)" to
-verify encrypted passwords in an SQL database. </p>
+<p> If you must store encrypted passwords, see section "<a
+href="#saslauthd_pam">Using saslauthd with PAM</a>", and configure
+PAM to look up the encrypted passwords with, for example, the
+<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
-it to a PostgreSQL server: </p>
+<p> The following example configures libsasl to use the sql plugin
+and connects it to a PostgreSQL server: </p>
<blockquote>
<pre>
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'
<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
-proxy authorization. </p>
+in an LDAP server. This plugin requires that SASL client passwords are
+stored as plaintext. </p>
+
+<blockquote>
+
+<strong>Tip</strong>
-<p> 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. </p>
+<p> If you must store encrypted passwords, you can use "<code>saslauthd
+-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
-authorize the ldapdb plugin. </p>
+once in the LDAP server to authenticate and authorize the ldapdb
+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>
<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
-server. </p>
+<p> Specify a mechanism here that is supported by the LDAP server.
+</p>
</blockquote>
</pre>
</blockquote>
-<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server
-Authentication Policy</a></h4>
+<h4><a name="smtpd_sasl_security_options">Postfix SMTP Server policy
+- SASL mechanism properties</a></h4>
+
+<p> 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. </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th>Property</th> <th>Description</th> </tr>
-<p> The Postfix SMTP server provides a way to specify the properties
-of SASL mechanisms that can be made available to the remote SMTP
-client. </p>
+<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>
</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
<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.
</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.
</blockquote>
<p> The <code>controlled_envelope_senders</code> table specifies
-the binding between the sender envelope addresses and its their
-SASL login names: </p>
+the binding between a sender envelope address and the SASL login
+names that own that address: </p>
<blockquote>
<pre>
<li><a href="#client_sasl_sender">Configuring sender-dependent SASL
authentication</a></li>
-<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client
-authentication policy</a></li>
+<li><a href="#client_sasl_policy">Postfix SMTP/LMTP client policy
+- SASL mechanism <em>properties</em></a></li>
-<li><a href="#client_sasl_filter">Filtering server mechanism names
-in the Postfix SMTP/LMTP client</a></li>
+<li><a href="#client_sasl_filter">Postfix SMTP/LMTP client policy
+- SASL mechanism <em>names</em></a></li>
</ul>
<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
-it in two parts. </p>
+SASL authentication. </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>
</ul>
-<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client authentication
-policy</a></h3>
+<h3><a name="client_sasl_policy">Postfix SMTP/LMTP client policy -
+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
-not. </p>
-
-<h4>Unencrypted SMTP session</h4>
-
-<p> The default policy is stricter than that of the Postfix SMTP
-server - plaintext mechanisms are not allowed (nor is any anonymous
-mechanism): </p>
-
-<blockquote>
-<pre>
-/etc/postfix/main.cf:
- smtp_sasl_security_options = noplaintext, noanonymous
-</pre>
-</blockquote>
-
-<p> Postfix can enforce the following policies on SASL authentication
-mechanisms: </p>
+that determines which SASL mechanisms are acceptable, based on their
+properties. The next two sections give examples of how these policies
+are used. </p>
<blockquote>
-<dl>
-
-<dt>noanonymous</dt>
+<table border="1">
-<dd> <p> Don't use mechanisms that permit anonymous authentication.
-</p> </dd>
+<tr> <th>Property</th> <th>Description</th> </tr>
-<dt>noplaintext</dt>
+<tr> <td>noanonymous</td> <td> Don't use mechanisms that permit
+anonymous authentication. </td> </tr>
-<dd> <p> Don't use mechanisms that transmit unencrypted username
-and password information. </p> </dd>
+<tr> <td>noplaintext</td> <td> Don't use mechanisms that transmit
+unencrypted username and password information. </td> </tr>
-<dt>nodictionary</dt>
+<tr> <td>nodictionary</td> <td> Don't use mechanisms that are
+vulnerable to dictionary attacks. </td> </tr>
-<dd> <p> Don't use mechanisms that are vulnerable to dictionary
-attacks. </p>
+<tr> <td>mutual_auth</td> <td> Use only mechanisms that authenticate
+both the client and the server to each other. </td> </tr>
-</dd>
+</table>
-<dt>
-<dt>mutual_auth</dt>
+</blockquote>
-<dd> <p> Use only mechanisms that authenticate both the client and
-the server to each other. </p> </dd>
+<h4>Unencrypted SMTP session</h4>
-</dl>
+<p> The default policy is stricter than that of the Postfix SMTP
+server - plaintext mechanisms are not allowed (nor is any anonymous
+mechanism): </p>
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ smtp_sasl_security_options = noplaintext, noanonymous
+</pre>
</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>
+<p> 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:
+</p>
<blockquote>
<pre>
</pre>
</blockquote>
-<p> The less secure approach to deal with this is to lower the
-security standards and permit plaintext authentication mechanisms:
-</p>
+<p> The less secure approach is to lower the security standards and
+permit plaintext authentication mechanisms: </p>
<blockquote>
<pre>
</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.
</pre>
</blockquote>
-<h3><a name="client_sasl_filter">Filtering server mechanism names in
-the Postfix SMTP/LMTP client</a></h3>
+<h3><a name="client_sasl_filter">Postfix SMTP/LMTP client policy -
+SASL mechanism <em>names</em></a></h3>
-<p> 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. </p>
+<p> 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. </p>
-<p> To prevent this, the Postfix SMTP client can filter the list
-of authentication mechanism names from the remote SMTP server. Used
+<p> 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. </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>
* 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
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)
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
--- /dev/null
+/*++
+/* 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);
+}
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;
*/
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));
}
/*
} 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),
*/
#define STR(s) vstring_str(s)
+ /*
+ * bounce_workaround.c
+ */
+int bounce_workaround(LOCAL_STATE);
+
/* LICENSE
/* .ad
/* .fi
* 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));
}
/*
/* 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]
/*
/* \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]
/* .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
"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,
projects / thirdparty / postfix.git / commitdiff
