From e31ae1582b7cf33bae78a96a9a201b9f4f3fd658 Mon Sep 17 00:00:00 2001 From: Wietse Venema Date: Sat, 4 Dec 2010 00:00:00 -0500 Subject: [PATCH] postfix-2.8-20101204 --- postfix/HISTORY | 27 +++ postfix/README_FILES/LDAP_README | 11 +- postfix/README_FILES/POSTSCREEN_README | 32 ++-- postfix/RELEASE_NOTES | 8 + postfix/WISHLIST | 13 +- postfix/html/LDAP_README.html | 19 ++- postfix/html/POSTSCREEN_README.html | 35 ++-- postfix/html/ldap_table.5.html | 184 ++++++++++++++------- postfix/html/postscreen.8.html | 171 ++++++++++--------- postfix/man/man5/ldap_table.5 | 62 ++++++- postfix/man/man8/postscreen.8 | 17 +- postfix/proto/LDAP_README.html | 19 ++- postfix/proto/POSTSCREEN_README.html | 35 ++-- postfix/proto/ldap_table | 60 ++++++- postfix/src/cleanup/cleanup_map1n.c | 43 +++-- postfix/src/global/dict_ldap.c | 192 ++++++++++++++++++++-- postfix/src/global/mail_version.h | 2 +- postfix/src/global/mime_state.c | 2 +- postfix/src/global/pipe_command.c | 5 +- postfix/src/global/scache_clnt.c | 2 +- postfix/src/local/local.c | 2 +- postfix/src/pickup/pickup.c | 5 +- postfix/src/pipe/pipe.c | 2 +- postfix/src/postscreen/postscreen.c | 19 +-- postfix/src/postscreen/postscreen_early.c | 4 +- postfix/src/postscreen/postscreen_misc.c | 4 +- postfix/src/postscreen/postscreen_send.c | 13 +- postfix/src/smtp/smtp.c | 2 +- 28 files changed, 720 insertions(+), 270 deletions(-) diff --git a/postfix/HISTORY b/postfix/HISTORY index 0268d42c1..759feb0cc 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -16205,3 +16205,30 @@ Apologies for any names omitted. Workaround: BSD-ish mkdir() ignores the effective GID and copies group ownership from the parent directory. File: util/make_dirs.c. + +20101202 + + Feature: the LDAP client can now authenticate to LDAP servers + via SASL. This is tested with SASL GSSAPI and Kerberos 5. + Code by Victor Duchovni. Files: global/dict_ldap.c, + proto/LDAP_README.html, proto/ldap_table. + + Cleanup: the cleanup server now reports a temporary delivery + error when it reaches the virtual_alias_expansion_limit or + virtual_alias_recursion_limit. Previously, it would silently + ignore the excess recipients and deliver the message. File: + cleanup/cleanup_map1n.c. + +20101204 + + Cleanup: sache_clnt_create() had an unnecessary data + dependency on the non-library var_scache_service variable, + causing problems with shared library builds. Instead, it + should use its service argument (which has the same value). + File: global/scache.c. + + Cleanup: pipe_command.c had an unnecessary data dependency + on the non-library var_command_maxtime variable, causing + problems with shared library builds. The dependency was not + necessary because the callers already specify an explicit + time limit. File: global/pipe_command.c. diff --git a/postfix/README_FILES/LDAP_README b/postfix/README_FILES/LDAP_README index 12ae27530..bfcb7963a 100644 --- a/postfix/README_FILES/LDAP_README +++ b/postfix/README_FILES/LDAP_README @@ -81,6 +81,11 @@ AUXLIBS line to point to libldap10.so or libldapssl30.so or whatever you have, and you may need to use the appropriate linker option (e.g. '-R') so the executables can find it at runtime. +If you are using OpenLDAP, and the libraries were built with SASL support, you +can add -DUSE_LDAP_SASL to the CCARGS to enable SASL support. For example: + + CCARGS="-I/usr/local/include -DHAS_LDAP -DUSE_LDAP_SASL" + CCoonnffiigguurriinngg LLDDAAPP llooookkuuppss In order to use LDAP lookups, define an LDAP source as a table lookup in @@ -89,8 +94,8 @@ main.cf, for example: alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf The file /etc/postfix/ldap-aliases.cf can specify a great number of parameters, -including parameters that enable LDAP SSL and STARTTLS. For a complete -description, see the ldap_table(5) manual page. +including parameters that enable LDAP SSL or STARTTLS, and LDAP SASL. For a +complete description, see the ldap_table(5) manual page. EExxaammppllee:: llooccaall((88)) aalliiaasseess @@ -440,6 +445,8 @@ CCrreeddiittss * Gunnar Wrobel provided a first implementation of a feature to limit LDAP search results to leaf nodes only. Victor generalized this into the Postfix 2.4 "leaf_result_attribute" feature. + * Quanah Gibson-Mount contributed support for advanced LDAP SASL mechanisms, + beyond the password-based LDAP "simple" bind. And of course Wietse. diff --git a/postfix/README_FILES/POSTSCREEN_README b/postfix/README_FILES/POSTSCREEN_README index a03ebe34a..5e3e02271 100644 --- a/postfix/README_FILES/POSTSCREEN_README +++ b/postfix/README_FILES/POSTSCREEN_README @@ -39,7 +39,9 @@ The main challenge for postscreen(8) is to make an is-it-a-zombie decision based on a single measurement. This is necessary because many zombies avoid spamming the same site repeatedly, in an attempt to fly under the radar. Once postscreen(8) decides that a client is not-a-zombie, it whitelists the client -temporarily to avoid further delays for legitimate mail. +temporarily to avoid further delays for legitimate mail. Clients that pass +postscreen(8) are still subject to the checks that are built into Postfix smtpd +(8), Postfix built-in content filters, and external content filters. Zombies have challenges too: they have only a limited amount of time to deliver spam before their IP address becomes blacklisted. To speed up spam deliveries, @@ -50,23 +52,22 @@ continue sending mail even when the server tells them to go away. postscreen(8) uses a variety of measurements to recognize zombies. First, postscreen(8) determines if the remote SMTP client IP address is blacklisted. Second, postscreen(8) looks for protocol compromises that are made to speed up -delivery. The results of such measurements don't change with each delivery -attempt, and are therefore good for making an is-it-a-zombie decision based on -a single measurement. +delivery. These are good indicators for making is-it-a-zombie decisions based +on single measurements. -postscreen(8) does not inspect message content. Message content can vary widely -with each delivery attempt, especially with clients that (also) send legitimate -email. Content is therefore not good for making an is-it-a-zombie decision -based on a single measurement, and that is the problem that postscreen(8) is +postscreen(8) does not inspect message content. Message content can vary from +one delivery to the next, especially with clients that (also) send legitimate +email. Content is not a good indicator for making is-it-a-zombie decisions +based on single measurements, and that is the problem that postscreen(8) is focused on. GGeenneerraall ooppeerraattiioonn The postscreen(8) triage process involves a number of tests, in the order as described below. Some tests introduce a delay of a few seconds. Once a client -passes all tests, its IP address is temporarily excluded from any tests, -typically 24 hours for simple tests or 1 week for complex tests. This minimizes -the impact of the tests on legitimate mail clients. +passes a test, its IP address is whitelisted from 24 hours for simple tests, to +1 week for complex tests. Whitelisting minimizes the impact of postscreen(8)'s +tests on legitimate mail clients. After logging its findings, postscreen(8) by default hands off all connections to a Postfix SMTP server process. This mode is useful for non-destructive @@ -252,11 +253,12 @@ discussed next. * postscreen(8)'s built-in SMTP engine does not implement the AUTH, STARTTLS, XCLIENT, and XFORWARD features. STARTTLS and AUTH support may be added in a - future version. + future version. In the mean time, if you need to make these services + available on port 25, then do not enable the tests after the 220 server + greeting. -End-user clients should connect directly to the submission service. Other -systems that require the above features should directly connect to a Postfix -SMTP server, or they should be placed on the postscreen(8) whitelist. +End-user clients should connect directly to the submission service, so that +they never have to deal with postscreen(8)'s tests. * Command pipelining test * Non-SMTP command test diff --git a/postfix/RELEASE_NOTES b/postfix/RELEASE_NOTES index 501e4baac..defa8bcd9 100644 --- a/postfix/RELEASE_NOTES +++ b/postfix/RELEASE_NOTES @@ -33,6 +33,14 @@ This is supported only when the default value is stress-dependent postscreen parameters always evaluate as if the stress value is equal to the empty string. +Incompatibility with snapshot 20101202 +====================================== + +Postfix now reports a temporary delivery error when the result of +virtual alias expansion would exceed the virtual_alias_recursion_limit +or virtual_alias_expansion_limit. Previously, Postfix would silently +drop the excess recipients and deliver the message. + Incompatibility with snapshot 20101130 ====================================== diff --git a/postfix/WISHLIST b/postfix/WISHLIST index e9dd7ac95..0e31672da 100644 --- a/postfix/WISHLIST +++ b/postfix/WISHLIST @@ -6,9 +6,10 @@ Wish list: smtpd xclient option for sasl_username. - Use different ipc_timeout settings for email message - transactions (smtpd, pickup)->cleanup and for quick query/reply - transactions such as address rewriting/resolution. + Use different ipc time limits for email message transactions + (smtpd, pickup)->cleanup and for quick query/reply transactions + such as address rewriting/resolution. Beware of large time + limits for local or virtual alias expansion. permit_tempfail_action (default: defer_if_reject) to be used as the default value for dnswl_tempfail_action and @@ -22,9 +23,11 @@ Wish list: Replace sscanf() numerical conversions by strto[dl]() for better error reporting. - Consistency: in postconf.proto make
..
tags bold. + As postscreen implements more ESMTP keywords, need to copy + inter-operability features from smtpd to filter keywords + and command syntax. - Milter addrcpt - use Sendmail-compatible default DSN settings. + Consistency: in postconf.proto make
..
tags bold. postscreen(8): listen on multiple IP addresses and enforce that the client contacts the primary MX address first (i.e. diff --git a/postfix/html/LDAP_README.html b/postfix/html/LDAP_README.html index ac1239b8b..6a3539280 100644 --- a/postfix/html/LDAP_README.html +++ b/postfix/html/LDAP_README.html @@ -128,6 +128,16 @@ change the AUXLIBS line to point to libldap10.so or libldapssl30.so or whatever you have, and you may need to use the appropriate linker option (e.g. '-R') so the executables can find it at runtime.

+

If you are using OpenLDAP, and the libraries were built with SASL +support, you can add -DUSE_LDAP_SASL to the CCARGS to enable SASL support. +For example:

+ +
+
+     CCARGS="-I/usr/local/include -DHAS_LDAP -DUSE_LDAP_SASL"
+
+
+

Configuring LDAP lookups

In order to use LDAP lookups, define an LDAP source @@ -140,9 +150,9 @@ as a table lookup in main.cf, for example:

The file /etc/postfix/ldap-aliases.cf can specify a great number -of parameters, including parameters that enable LDAP SSL and -STARTTLS. For a complete description, see the ldap_table(5) manual -page.

+of parameters, including parameters that enable LDAP SSL or STARTTLS, +and LDAP SASL. For a complete description, see the ldap_table(5) +manual page.

Example: local(8) aliases

@@ -591,6 +601,9 @@ expansion_limit interface for LDAP, MySQL and PosgreSQL. limit LDAP search results to leaf nodes only. Victor generalized this into the Postfix 2.4 "leaf_result_attribute" feature. +
  • Quanah Gibson-Mount contributed support for advanced LDAP SASL +mechanisms, beyond the password-based LDAP "simple" bind.
    • + And of course Wietse. diff --git a/postfix/html/POSTSCREEN_README.html b/postfix/html/POSTSCREEN_README.html index b59eecd13..e5ef607a6 100644 --- a/postfix/html/POSTSCREEN_README.html +++ b/postfix/html/POSTSCREEN_README.html @@ -67,7 +67,10 @@ decision based on a single measurement. This is necessary because many zombies avoid spamming the same site repeatedly, in an attempt to fly under the radar. Once postscreen(8) decides that a client is not-a-zombie, it whitelists the client temporarily to avoid -further delays for legitimate mail.

    +further delays for legitimate mail. Clients that pass postscreen(8) +are still subject to the checks that are built into Postfix smtpd(8), +Postfix built-in content filters, and external content filters. +

    Zombies have challenges too: they have only a limited amount of time to deliver spam before their IP address becomes blacklisted. @@ -79,25 +82,24 @@ mail even when the server tells them to go away.

    postscreen(8) uses a variety of measurements to recognize zombies. First, postscreen(8) determines if the remote SMTP client IP address is blacklisted. Second, postscreen(8) looks for protocol -compromises that are made to speed up delivery. The results of -such measurements don't change with each delivery attempt, and are -therefore good for making an is-it-a-zombie decision based on a -single measurement.

    +compromises that are made to speed up delivery. These are good +indicators for making is-it-a-zombie decisions based on single +measurements.

    postscreen(8) does not inspect message content. Message content -can vary widely with each delivery attempt, especially with clients -that (also) send legitimate email. Content is therefore not good -for making an is-it-a-zombie decision based on a single measurement, +can vary from one delivery to the next, especially with clients +that (also) send legitimate email. Content is not a good indicator +for making is-it-a-zombie decisions based on single measurements, and that is the problem that postscreen(8) is focused on.

    General operation

    The postscreen(8) triage process involves a number of tests, in the order as described below. Some tests introduce a delay of -a few seconds. Once a client passes all tests, its IP address is -temporarily excluded from any tests, typically 24 hours for simple -tests or 1 week for complex tests. This minimizes the impact of -the tests on legitimate mail clients.

    +a few seconds. Once a client passes a test, its IP address is +whitelisted from 24 hours for simple tests, to 1 week for complex +tests. Whitelisting minimizes the impact of postscreen(8)'s tests +on legitimate mail clients.

    After logging its findings, postscreen(8) by default hands off all connections to a Postfix SMTP server process. This mode is @@ -340,14 +342,15 @@ a relatively long expiration time.

  • postscreen(8)'s built-in SMTP engine does not implement the AUTH, STARTTLS, XCLIENT, and XFORWARD features. STARTTLS and -AUTH support may be added in a future version.

    +AUTH support may be added in a future version. In the mean time, +if you need to make these services available on port 25, then do +not enable the tests after the 220 server greeting.

    End-user clients should connect directly to the submission -service. Other systems that require the above features -should directly connect to a Postfix SMTP server, or they -should be placed on the postscreen(8) whitelist.

    +service, so that they never have to deal with postscreen(8)'s tests. +

    And of course Wietse. diff --git a/postfix/proto/POSTSCREEN_README.html b/postfix/proto/POSTSCREEN_README.html index 6d0c7e166..f590a5fe9 100644 --- a/postfix/proto/POSTSCREEN_README.html +++ b/postfix/proto/POSTSCREEN_README.html @@ -67,7 +67,10 @@ decision based on a single measurement. This is necessary because many zombies avoid spamming the same site repeatedly, in an attempt to fly under the radar. Once postscreen(8) decides that a client is not-a-zombie, it whitelists the client temporarily to avoid -further delays for legitimate mail.

    +further delays for legitimate mail. Clients that pass postscreen(8) +are still subject to the checks that are built into Postfix smtpd(8), +Postfix built-in content filters, and external content filters. +

    Zombies have challenges too: they have only a limited amount of time to deliver spam before their IP address becomes blacklisted. @@ -79,25 +82,24 @@ mail even when the server tells them to go away.

    postscreen(8) uses a variety of measurements to recognize zombies. First, postscreen(8) determines if the remote SMTP client IP address is blacklisted. Second, postscreen(8) looks for protocol -compromises that are made to speed up delivery. The results of -such measurements don't change with each delivery attempt, and are -therefore good for making an is-it-a-zombie decision based on a -single measurement.

    +compromises that are made to speed up delivery. These are good +indicators for making is-it-a-zombie decisions based on single +measurements.

    postscreen(8) does not inspect message content. Message content -can vary widely with each delivery attempt, especially with clients -that (also) send legitimate email. Content is therefore not good -for making an is-it-a-zombie decision based on a single measurement, +can vary from one delivery to the next, especially with clients +that (also) send legitimate email. Content is not a good indicator +for making is-it-a-zombie decisions based on single measurements, and that is the problem that postscreen(8) is focused on.

    General operation

    The postscreen(8) triage process involves a number of tests, in the order as described below. Some tests introduce a delay of -a few seconds. Once a client passes all tests, its IP address is -temporarily excluded from any tests, typically 24 hours for simple -tests or 1 week for complex tests. This minimizes the impact of -the tests on legitimate mail clients.

    +a few seconds. Once a client passes a test, its IP address is +whitelisted from 24 hours for simple tests, to 1 week for complex +tests. Whitelisting minimizes the impact of postscreen(8)'s tests +on legitimate mail clients.

    After logging its findings, postscreen(8) by default hands off all connections to a Postfix SMTP server process. This mode is @@ -340,14 +342,15 @@ a relatively long expiration time.

  • postscreen(8)'s built-in SMTP engine does not implement the AUTH, STARTTLS, XCLIENT, and XFORWARD features. STARTTLS and -AUTH support may be added in a future version.

    +AUTH support may be added in a future version. In the mean time, +if you need to make these services available on port 25, then do +not enable the tests after the 220 server greeting.

    End-user clients should connect directly to the submission -service. Other systems that require the above features -should directly connect to a Postfix SMTP server, or they -should be placed on the postscreen(8) whitelist.

    +service, so that they never have to deal with postscreen(8)'s tests. +