mir/postfix
2
0
Fork 0
mirror of https://github.com/vdukhovni/postfix synced 2025-08-31 22:25:24 +00:00
Code Issues Releases Wiki Activity

postfix-2.8-20100208

Browse Source
This commit is contained in:
Wietse Venema
2010-02-08 00:00:00 -05:00
committed by Viktor Dukhovni
parent 49524057e9
commit bde0246003
20 changed files with 763 additions and 519 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
postfix/HISTORY
View File

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

227
postfix/README_FILES/SASL_README
View File

@@ -12,19 +12,17 @@ may be worth considering.
HHooww PPoossttffiixx uusseess SSAASSLL aauutthheennttiiccaattiioonn
When an SMTP client connects to an SMTP server, the server needs to decide
whether that client is authorized to send mail to remote destinations, or
whether the client can send mail only to the destinations that the server
itself is responsible for. Usually, the SMTP server will allow mail to remote
destinations only if the client's IP address is in the "same network" as the
server's IP address.
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 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.
Sometimes an SMTP client needs "same network" privileges when it connects from
elsewhere. To address this problem, Postfix supports SASL authentication (RFC
4954, formerly RFC 2554). With this a remote SMTP client can authenticate to
the Postfix SMTP server, and the Postfix SMTP client can authenticate to a
remote SMTP server. Once a client is authenticated, a server can give it "same
network" privileges.
Postfix does not implement SASL itself, but instead uses existing
implementations as building blocks. This means that some SASL-related
@@ -76,7 +74,7 @@ You can read more about the following topics:
* Enabling SASL authentication and authorization in the Postfix SMTP server
o Enabling SASL authentication in the Postfix SMTP server
o Postfix SMTP Server Authentication Policy
o Postfix SMTP Server policy - SASL mechanism properties
o Enabling SASL authorization in the Postfix SMTP server
o Additional SMTP Server SASL options
@@ -367,9 +365,9 @@ plugins.
TThhee ssaassllddbb pplluuggiinn
The sasldb auxprop plugin authenticates credentials stored in a Berkeley DB
database. The database schema is specific to Cyrus SASL. The database is
usually located at /etc/sasldb2.
The sasldb auxprop plugin authenticates SASL clients against credentials that
are stored in a Berkeley DB database. The database schema is specific to Cyrus
SASL. The database is usually located at /etc/sasldb2.
NNoottee
@@ -422,17 +420,16 @@ Configure libsasl to use sasldb with the following instructions:
TThhee ssqqll pplluuggiinn
The sql auxprop plugin is a generic SQL plugin. It provides access to
credentials stored in a MySQL, a PostgreSQL or a SQLite database.
NNoottee
The shared-secret mechanisms (CRAM-MD5, etc.) require that the SASL client
passwords are stored as plaintext.
credentials stored in a MySQL, PostgreSQL or SQLite database. This plugin
requires that SASL client passwords are stored as plaintext.
TTiipp
Use "saslauthd > pam > (pam database module)" to verify encrypted passwords
in an SQL database.
If you must store encrypted passwords, see section "Using saslauthd with
PAM", and configure PAM to look up the encrypted passwords with, for
example, the pam_mysql module. You will not be able to use any of the
methods that require access to plaintext passwords, such as the shared-
secret methods CRAM-MD5 and DIGEST-MD5.
The following example configures libsasl to use the sql plugin and connects it
to a PostgreSQL server:
@@ -442,7 +439,8 @@ to a PostgreSQL server:
auxprop_plugin: sql
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
sql_engine: pgsql
sql_hostnames: 127.0.0.1, 192.0.2.1 sql_user: username
sql_hostnames: 127.0.0.1, 192.0.2.1
sql_user: username
sql_passwd: secret
sql_database: dbname
sql_select: SELECT password FROM users WHERE user = '%u'@'%r'
@@ -510,22 +508,32 @@ available:
TThhee llddaappddbb pplluuggiinn
The ldapdb auxprop plugin provides access to credentials stored in an OpenLDAP
LDAP server. It is the only plugin that implements proxy authorization.
The ldapdb auxprop plugin provides access to credentials stored in an LDAP
server. This plugin requires that SASL client passwords are stored as
plaintext.
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.
TTiipp
If you must store encrypted passwords, you can use "saslauthd -a ldap" to
query the LDAP database directly, with appropriate configuration in
saslauthd.conf. This may be documented in a later version of this document.
You will not be able to use any of the methods that require access to
plaintext passwords, such as the shared-secret methods CRAM-MD5 and DIGEST-
MD5.
The ldapdb plugin implements proxy authorization. This means that the ldapdb
plugin uses its own username and password to authenticate with the LDAP server,
before it asks the LDAP server for the remote SMTP client's password. The LDAP
server then decides if the ldapdb plugin is authorized to read the remote SMTP
client's password.
In a nutshell: Configuring ldapdb means authentication and authorization must
be configured twice - once in the Postfix SMTP server to authenticate and
authorize the remote SMTP client, and once in the OpenLDAP slapd server to
authenticate and authorize the ldapdb plugin.
authorize the remote SMTP client, and once in the LDAP server to authenticate
and authorize the ldapdb plugin.
This example configures libsasl to use the ldapdb plugin and the plugin to
connect to an OpenLDAP server:
connect to an LDAP server:
/etc/sasl2/smtpd.conf:
pwcheck_method: auxprop
@@ -565,13 +573,11 @@ The following is a summary of applicable smtpd.conf file entries:
LDAP server (proxy authorization).
ldapdb_mech
The mechanism to authenticate the ldapdb plugin to the OpenLDAP slapd
server.
The mechanism to authenticate the ldapdb plugin to the LDAP server.
NNoottee
Specify a mechanism here that is supported by the OpenLDAP slapd
server.
Specify a mechanism here that is supported by the LDAP server.
ldapdb_rc (optional)
The path to a file containing individual configuration options for the
@@ -701,10 +707,30 @@ capability twice - once for compliant and once for broken clients:
250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5
...
PPoossttffiixx SSMMTTPP SSeerrvveerr AAuutthheennttiiccaattiioonn PPoolliiccyy
PPoossttffiixx SSMMTTPP SSeerrvveerr ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess
The Postfix SMTP server provides a way to specify the properties of SASL
mechanisms that can be made available to the remote SMTP client.
The Postfix SMTP server supports policies that limit the SASL mechanisms that
it makes available to clients, based on the properties of those mechanisms. The
next two sections give examples of how these policies are used.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|PPrrooppeerrttyy |DDeessccrriippttiioonn |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|noanonymous |Don't use mechanisms that permit anonymous |
| |authentication. |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|noplaintext |Don't use mechanisms that transmit unencrypted username |
| |and password information. |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|nodictionary |Don't use mechanisms that are vulnerable to dictionary |
| |attacks. |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|forward_secrecy|Require forward secrecy between sessions (breaking one |
| |session does not break earlier sessions). |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|mutual_auth |Use only mechanisms that authenticate both the client and|
| |the server to each other. |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
UUnneennccrryypptteedd SSMMTTPP sseessssiioonn
@@ -721,25 +747,6 @@ for those based on anonymous authentication:
server can give strangers the same authorization as a properly-
authenticated client.
Postfix can enforce the following policies on SASL authentication mechanisms:
noanonymous
Don't use mechanisms that permit anonymous authentication.
noplaintext
Don't use mechanisms that transmit unencrypted username and password
information.
nodictionary
Don't use mechanisms that are vulnerable to dictionary attacks.
forward_secrecy
Use only mechanisms that support forward secrecy (Dovecot SASL only).
mutual_auth
Use only mechanisms that authenticate both the client and the server to
each other.
EEnnccrryypptteedd SSMMTTPP sseessssiioonn ((TTLLSS))
A separate parameter controls Postfix SASL mechanism policy during a TLS-
@@ -791,9 +798,9 @@ smtpd_recipient_restrictions as follows:
EEnnvveellooppee sseennddeerr aaddddrreessss aauutthhoorriizzaattiioonn
By default an SMTP client may specify any envelope sender address in the MAIL
FROM command. That is because the Postfix SMTP server only knows the remte SMTP
client hostname and IP address, but not the user who controls the remote SMTP
client.
FROM command. That is because the Postfix SMTP server only knows the remote
SMTP client hostname and IP address, but not the user who controls the remote
SMTP client.
This changes the moment an SMTP client uses SASL authentication. Now, the
Postfix SMTP server knows who the sender is. Given a table of envelope sender
@@ -811,8 +818,8 @@ authenticated client is allowed to use a particular envelope sender address:
reject_unauth_destination
...
The controlled_envelope_senders table specifies the binding between the sender
envelope addresses and its their SASL login names:
The controlled_envelope_senders table specifies the binding between a sender
envelope address and the SASL login names that own that address:
/etc/postfix/controlled_envelope_senders
# envelope sender owners (SASL login names)
@@ -935,14 +942,26 @@ You can read more about the following topics:
* Enabling SASL authentication in the Postfix SMTP/LMTP client
* Configuring sender-dependent SASL authentication
* Postfix SMTP/LMTP client authentication policy
* Filtering server mechanism names in the Postfix SMTP/LMTP client
* Postfix SMTP/LMTP client policy - SASL mechanism pprrooppeerrttiieess
* Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess
EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
This section shows a typical scenario where the Postfix SMTP client sends all
messages via a mail gateway server that requires SASL authentication. To make
the example more readable we introduce it in two parts.
messages via a mail gateway server that requires SASL authentication.
TTrroouubbllee ssoollvviinngg ttiippss::
* If your SASL logins fail with "SASL authentication failure: No worthy
mechs found" in the mail logfile, then see the section "Postfix SMTP/
LMTP client policy - SASL mechanism pprrooppeerrttiieess".
* For a solution to a more obscure class of SASL authentication failures,
see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess".
To make the example more readable we introduce it in two parts. The first part
takes care of the basic configuration, while the second part sets up the
username/password information.
/etc/postfix/main.cf:
smtp_sasl_auth_enable = yes
@@ -1057,10 +1076,26 @@ final resort.
* Execute the command "postmap /etc/postfix/sender_relay" whenever you change
the sender_relay table.
PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt aauutthheennttiiccaattiioonn ppoolliiccyy
PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess
Just like the Postfix SMTP server, the SMTP client has a policy that determines
which SASL mechanisms are acceptable and which are not.
which SASL mechanisms are acceptable, based on their properties. The next two
sections give examples of how these policies are used.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|PPrrooppeerrttyy |DDeessccrriippttiioonn |
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|noanonymous |Don't use mechanisms that permit anonymous authentication. |
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|noplaintext |Don't use mechanisms that transmit unencrypted username and|
| |password information. |
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|nodictionary|Don't use mechanisms that are vulnerable to dictionary |
| |attacks. |
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|mutual_auth |Use only mechanisms that authenticate both the client and |
| |the server to each other. |
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
UUnneennccrryypptteedd SSMMTTPP sseessssiioonn
@@ -1070,38 +1105,18 @@ mechanisms are not allowed (nor is any anonymous mechanism):
/etc/postfix/main.cf:
smtp_sasl_security_options = noplaintext, noanonymous
Postfix can enforce the following policies on SASL authentication mechanisms:
noanonymous
Don't use mechanisms that permit anonymous authentication.
noplaintext
Don't use mechanisms that transmit unencrypted username and password
information.
nodictionary
Don't use mechanisms that are vulnerable to dictionary attacks.
mutual_auth
Use only mechanisms that authenticate both the client and the server to
each other.
With the default policy shown above, the Postfix SMTP client will not send its
password over an unencrypted connection. This sometimes leads to authentication
failures if the remote server only offers plaintext authentication mechanisms.
In such cases the SMTP client will log the following error message:
This default policy leads to authentication failures if the remote server only
offers plaintext authentication mechanisms. In such cases the SMTP client will
log the following error message:
SASL authentication failure: No worthy mechs found
The less secure approach to deal with this is to lower the security standards
and permit plaintext authentication mechanisms:
The less secure approach is to lower the security standards and permit
plaintext authentication mechanisms:
/etc/postfix/main.cf:
smtp_sasl_security_options = noanonymous
Needless to say, sending a username and password over an insecure channel is
undesirable.
If the remote server supports TLS, you can protect the plaintext username and
password by turning on TLS in the Postfix SMTP client (see: TLS_README), and
configuring the client as discussed next.
@@ -1122,16 +1137,18 @@ encrypted connection:
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
FFiilltteerriinngg sseerrvveerr mmeecchhaanniissmm nnaammeess iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm nnaammeess
Cyrus SASL always attempts to use the most secure authentication mechanism that
the remote SMTP server offers - even if the client side was not configured to
handle it! In such cases authentication will definitely fail.
Unfortunately, Postfix needs a second client policy for SASL mechanism
selection. Reason: the Cyrus SASL library will choose the most secure
authentication mechanism that both the SMTP client and server implement - even
if one of the parties was not configured for that mechanism.
To prevent this, the Postfix SMTP client can filter the list of authentication
mechanism names from the remote SMTP server. Used correctly, the filter hides
unwanted mechanisms from the Cyrus SASL library, forcing the library to choose
from the mechanisms the Postfix filter passes through.
To prevent this, the Postfix SMTP client can filter the names of the
authentication mechanisms from the remote SMTP server. Used correctly, the
filter hides unwanted mechanisms from the Cyrus SASL library, forcing the
library to choose from the mechanisms the Postfix SMTP client filter passes
through.
The following example filters out everything but the mechanisms PLAIN and
LOGIN:

16
postfix/README_FILES/SOHO_README
View File

@@ -152,8 +152,20 @@ virtual table.
EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
This section shows a typical scenario where the Postfix SMTP client sends all
messages via a mail gateway server that requires SASL authentication. To make
the example more readable we introduce it in two parts.
messages via a mail gateway server that requires SASL authentication.
TTrroouubbllee ssoollvviinngg ttiippss::
* If your SASL logins fail with "SASL authentication failure: No worthy
mechs found" in the mail logfile, then see the section "Postfix SMTP/
LMTP client policy - SASL mechanism pprrooppeerrttiieess".
* For a solution to a more obscure class of SASL authentication failures,
see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess".
To make the example more readable we introduce it in two parts. The first part
takes care of the basic configuration, while the second part sets up the
username/password information.
/etc/postfix/main.cf:
smtp_sasl_auth_enable = yes

14
postfix/WISHLIST
View File

@@ -2,6 +2,12 @@ Wish list:
Remove this file from the stable release.
instead of ipc_idle, reduce ipc_ttl.
Add smtpd_sender_login_maps to proxy_read_maps. What other
parameters are worthy of being whitelisted for proxy access?
Is there a way to automate this decision?
The cleanup virtual alias expansion limit does not really
deliver on its promises. 1) It promises to truncate the
result without aborting delivery, which would be undesirable
@@ -47,21 +53,17 @@ Wish list:
Find a place to document all the mail routing mechanisms
in one place so people can figure out how Postfix works.
owner-listname does not work for shell commands.
Investigate viability of Sendmail socket maps (the moral
equivalent of tcp_table(5)), and dns maps.
The BCC action is marked "not stable", perhaps because
people would also expect BCC actions in header/body_checks.
The access map BCC action is marked "not stable", perhaps
because people would also expect BCC actions in header/body_checks.
How much would it take to make the queue file editing code
generally usable?
Move smtpd_command_filter into smtpd_chat_query() and update
the session transcript (see smtp_chat_reply() for an example).
Add smtpd_sender_login_maps to proxy_read_maps.
SMTP connection caching without storing connections, to
improve TLS mail delivery performance.

6
postfix/conf/post-install
View File

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

346
postfix/html/SASL_README.html
View File

@@ -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
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> 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 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> 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
@@ -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
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>
@@ -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
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>
@@ -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
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 &gt; pam &gt; (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>
@@ -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
proxy authorization. </p>
in an LDAP server. This plugin requires that SASL client passwords are
stored as plaintext. </p>
<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>
<blockquote>
<strong>Tip</strong>
<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>
@@ -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
server. </p>
<p> Specify a mechanism here that is supported by the LDAP server.
</p>
</blockquote>
@@ -1186,12 +1195,39 @@ clients: </p>
</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 provides a way to specify the properties
of SASL mechanisms that can be made available to the remote SMTP
client. </p>
<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>
<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
SASL login names: </p>
the binding between a sender envelope address and the SASL login
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
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>
@@ -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
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>
@@ -1713,12 +1732,35 @@ whenever you change the sender_relay table. </p>
</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>
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>
<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
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>
<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>
<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>
@@ -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
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>
@@ -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
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>

26
postfix/html/SOHO_README.html
View File

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

8
postfix/html/postmulti.1.html
View File

@@ -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> ...]

8
postfix/man/man1/postmulti.1
View File

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

2
postfix/mantools/make-relnotes
View File

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

346
postfix/proto/SASL_README.html
View File

@@ -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
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> 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 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> 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
@@ -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
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>
@@ -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
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>
@@ -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
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 &gt; pam &gt; (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>
@@ -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
proxy authorization. </p>
in an LDAP server. This plugin requires that SASL client passwords are
stored as plaintext. </p>
<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>
<blockquote>
<strong>Tip</strong>
<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>
@@ -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
server. </p>
<p> Specify a mechanism here that is supported by the LDAP server.
</p>
</blockquote>
@@ -1186,12 +1195,39 @@ clients: </p>
</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 provides a way to specify the properties
of SASL mechanisms that can be made available to the remote SMTP
client. </p>
<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>
<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
SASL login names: </p>
the binding between a sender envelope address and the SASL login
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
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>
@@ -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
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>
@@ -1713,12 +1732,35 @@ whenever you change the sender_relay table. </p>
</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>
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>
<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
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>
<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>
<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>
@@ -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
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>
@@ -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
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>

2
postfix/src/global/mail_version.h
View File

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

35
postfix/src/local/Makefile.in
View File

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

143
postfix/src/local/bounce_workaround.c Normal file
View File

@@ -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);
}

12
postfix/src/local/command.c
View File

@@ -235,11 +235,13 @@ int deliver_command(LOCAL_STATE state, USER_ATTR usr_attr, const char *comma
break;
case PIPE_STAT_BOUNCE:
case PIPE_STAT_DEFER:
deliver_status =
(STR(why->status)[0] == '4' ?
defer_append : bounce_append)
(BOUNCE_FLAGS(state.request),
BOUNCE_ATTR(state.msg_attr));
if (STR(why->status)[0] == '4')
deliver_status =
defer_append(BOUNCE_FLAGS(state.request),
BOUNCE_ATTR(state.msg_attr));
else
/* Account for possible owner- sender address override. */
deliver_status = bounce_workaround(state);
break;
case PIPE_STAT_CORRUPT:
deliver_status = DEL_STAT_DEFER;

16
postfix/src/local/file.c
View File

@@ -111,8 +111,8 @@ int deliver_file(LOCAL_STATE state, USER_ATTR usr_attr, char *path)
*/
if ((local_file_deliver_mask & state.msg_attr.exp_type) == 0) {
dsb_simple(why, "5.7.1", "mail to file is restricted");
return (bounce_append(BOUNCE_FLAGS(state.request),
BOUNCE_ATTR(state.msg_attr)));
/* Account for possible owner- sender address override. */
return (bounce_workaround(state));
}
/*
@@ -184,11 +184,13 @@ int deliver_file(LOCAL_STATE state, USER_ATTR usr_attr, char *path)
} else if (mail_copy_status != 0) {
vstring_sprintf_prepend(why->reason,
"cannot append message to file %s: ", path);
deliver_status =
(STR(why->status)[0] == '4' ?
defer_append : bounce_append)
(BOUNCE_FLAGS(state.request),
BOUNCE_ATTR(state.msg_attr));
if (STR(why->status)[0] == '4')
deliver_status =
defer_append(BOUNCE_FLAGS(state.request),
BOUNCE_ATTR(state.msg_attr));
else
/* Account for possible owner- sender address override. */
deliver_status = bounce_workaround(state);
} else {
dsb_simple(why, "2.0.0", "delivered to file: %s", path);
deliver_status = sent(BOUNCE_FLAGS(state.request),

5
postfix/src/local/local.h
View File

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

43
postfix/src/local/recipient.c
View File

@@ -230,47 +230,10 @@ int deliver_recipient(LOCAL_STATE state, USER_ATTR usr_attr)
* normal bounce sending procedure, but would simplify the code below.
*/
if (delivered_hdr_find(state.loop_info, state.msg_attr.rcpt.address)) {
VSTRING *canon_owner = 0;
if (var_ownreq_special) {
char *stripped_recipient;
char *owner_alias;
const char *owner_expansion;
#define FIND_OWNER(lhs, rhs, addr) { \
lhs = concatenate("owner-", addr, (char *) 0); \
(void) split_at_right(lhs, '@'); \
rhs = maps_find(alias_maps, lhs, DICT_FLAG_NONE); \
}
FIND_OWNER(owner_alias, owner_expansion, state.msg_attr.rcpt.address);
if (owner_expansion == 0
&& (stripped_recipient = strip_addr(state.msg_attr.rcpt.address,
(char **) 0,
*var_rcpt_delim)) != 0) {
myfree(owner_alias);
FIND_OWNER(owner_alias, owner_expansion, stripped_recipient);
myfree(stripped_recipient);
}
if (owner_expansion != 0) {
canon_owner = canon_addr_internal(vstring_alloc(10),
var_exp_own_alias ?
owner_expansion : owner_alias);
SET_OWNER_ATTR(state.msg_attr, STR(canon_owner), state.level);
}
myfree(owner_alias);
}
dsb_simple(state.msg_attr.why, "5.4.6", "mail forwarding loop for %s",
dsb_simple(state.msg_attr.why, "5.4.6", "mail forwarding loop for %s",
state.msg_attr.rcpt.address);
if (canon_owner) {
rcpt_stat = bounce_one(BOUNCE_FLAGS(state.request),
BOUNCE_ONE_ATTR(state.msg_attr));
vstring_free(canon_owner);
} else {
rcpt_stat = bounce_append(BOUNCE_FLAGS(state.request),
BOUNCE_ATTR(state.msg_attr));
}
return (rcpt_stat);
/* Account for possible owner- sender address override. */
return (bounce_workaround(state));
}
/*

8
postfix/src/postmulti/postmulti.c
View File

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

5
postfix/src/xsasl/xsasl_cyrus_security.c
View File

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