Adding upstream version 3.5.24.upstream/3.5.24

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 383 insertions, 0 deletions

diff --git a/RELEASE_NOTES-2.8 b/RELEASE_NOTES-2.8
new file mode 100644
index 0000000..622577f
--- /dev/null
+++ b/RELEASE_NOTES-2.8
@@ -0,0 +1,383 @@
+The stable Postfix release is called postfix-2.8.x where 2=major
+release number, 8=minor release number, x=patchlevel.  The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.9-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day).  Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.6 or earlier, read RELEASE_NOTES-2.7
+before proceeding.
+
+Major changes - restart Postfix
+-------------------------------
+
+If you upgrade from Postfix 2.6 or earlier, you must execute "postfix
+stop" and "postfix start" before you can use the postscreen(8)
+daemon.  This is needed because the Postfix 2.6 "pass" master service
+type did not work reliably on some systems.
+
+If you upgrade from Postfix 2.7, or from Postfix 2.8 before July
+25, 2010, you must execute "postfix reload" (or "postfix stop"
+followed by "postfix start"). This is needed because the queue
+manager to delivery agent protocol has changed. Failure to do this
+results in repeated logging of warnings with:
+
+    warning: unexpected attribute rewrite_context ...
+
+If the warning does not go away after restarting Postfix, examine
+the output from this command:
+
+    strings -af /usr/libexec/postfix/* | grep mail_version=
+
+(where /usr/libexec/postfix is the value of main.cf:daemon_directory)
+and update the executables that have a version string that differs
+from the other programs.
+
+Major changes - DNSBL/DNSWL support
+-----------------------------------
+
+[Feature 20101126] Support for address patterns in DNS blacklist
+and whitelist lookup results.
+
+For example, "reject_rbl_client example.com=127.0.0.[2;4;6..8]"
+will reject clients when the lookup result is 127.0.0.2, 127.0.0.4,
+127.0.0.6, 127.0.0.7, or 127.0.0.8.
+
+The setting "postscreen_dnsbl_sites = example.com=127.0.0.[2;4;6..8]"
+rejects the same clients.
+
+An IPv4 address pattern has four fields separated by ".".  Each
+field is either a decimal number, or a sequence inside "[]" that
+contains one or more ";"-separated decimal numbers or number..number
+ranges.
+
+Thus, any pattern field can be a sequence inside "[]", but a "[]"
+sequence cannot span multiple address fields, and a pattern field
+cannot contain both a number and a "[]" sequence at the same time.
+
+This means that the pattern 1.2.[3.4] is not valid (the sequence
+[3.4] cannot span two address fields) and the pattern 1.2.3.3[6..9]
+is also not valid (the last field cannot be both number 3 and
+sequence [6..9] at the same time).
+
+The syntax for IPv4 patterns is as follows:
+
+v4pattern = v4field "." v4field "." v4field "." v4field
+v4field = v4octet | "[" v4sequence "]"
+v4octet = any decimal number in the range 0 through 255
+v4sequence = v4seq_member | v4sequence ";" v4seq_member
+v4seq_member = v4octet | v4octet ".." v4octet
+
+[Feature 20101105] The Postfix SMTP server now supports DNS-based
+whitelisting with several safety features: permit_dnswl_client
+whitelists a client by IP address, and permit_rhswl_client whitelists
+a client by its hostname.  These features use the same syntax as
+reject_rbl_client and reject_rhsbl_client, respectively. The main
+difference is that they return PERMIT instead of REJECT.
+
+Whitelisting is primarily a tool to reduce the false positive rate
+of DNS blocklist lookups.  Client name whitelisting should not be
+used to make exceptions to access rules. The reason is that client
+name lookup can fail unpredictably due to some temporary outage.
+
+For safety reasons, permit_dnswl_client and permit_rhswl_client are
+silently ignored when they would override reject_unauth_destination.
+Also for safety reasons, the result is DEFER_IF_REJECT when DNS
+whitelist lookup fails (this result will be made configurable).
+
+Major changes - sqlite support
+------------------------------
+
+[Feature 20100617] Support for read-only sqlite database access,
+with code by Axel Steiner and documentation by Jesus Garcia Crespo.
+See SQLITE_README and sqlite_table(5) for details.
+
+Major changes - Milter support
+-------------------------------
+
+[Incompat 20101103] Postfix now requests default delivery status
+notifications when adding a recipient with the Milter smfi_addrcpt
+action, instead of "never notify" as with Postfix automatically-added
+recipients (always_bcc and sender/recipient_bcc_maps).
+
+Major changes - alias expansion
+-------------------------------
+
+[Incompat 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.
+
+[Incompat 20101006] To avoid repeated delivery to mailing lists
+with pathological nested alias configurations, the local(8) delivery
+agent now keeps the owner-alias attribute of a parent alias, when
+delivering mail to a child alias that does not have its own owner
+alias.
+
+With this change, local addresses from that child alias will be
+written to a new queue file, and a temporary error with one local
+address will no longer result in repeated delivery to other mailing
+list members.  Specify "reset_owner_alias = yes" for the older,
+more fragile, behavior.
+
+The postconf(5) manpage entry for "reset_owner_alias" has more
+background information on this issue.
+
+Major changes - dns lookup
+--------------------------
+
+[Incompat 20100827] The Postfix SMTP client no longer appends the
+local domain when looking up a DNS name without ".".  Specify
+"smtp_dns_resolver_options = res_defnames" to get the old behavior,
+which may produce unexpected results.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20100728] The format of the "postfix/smtpd[pid]: queueid:
+client=host[addr]" logfile record has changed. When available, the
+before-filter client information and the before-filter queue ID are
+now appended to the end of the record.
+
+[Feature 20100728] Improved message tracking across SMTP-based
+content filters.  The logging example below is from an after-filter
+SMTP server. Here, 951F692462F is a before-filter queue ID,
+hades.porcupine.org is a before-filter SMTP client, while 6B4A9924782
+is the after-filter queue ID, and localhost[127.0.0.1] is the
+SMTP-based content filter that sends mail into the after-filter
+SMTP server.
+
+    postfix/smtpd[4074]: 6B4A9924782: 
+	client=localhost[127.0.0.1],
+	orig_queue_id=951F692462F
+	orig_client=hades.porcupine.org[168.100.189.10]
+
+Major changes - reply footer
+----------------------------
+
+[Feature 20110105] The SMTP server now supports contact information
+that is appended to "reject" responses. This includes SMTP server
+responses that aren't logged to the maillog file, such as responses
+to syntax errors, or unsupported commands.
+
+Example:
+   smtpd_reject_footer = For assistance, call 800-555-0101.
+
+Server response:
+   550-5.5.1 <user@example> Recipient address rejected: User unknown
+   550 5.5.1 For assistance, call 800-555-0101.
+
+This feature supports macro expansion ($client_address, $localtime,
+etc.), as documented in the postconf(5) manpage.
+
+This feature is also supported as postscreen_reject_footer using
+the same setting as smtpd_reject_footer by default.
+
+Major changes - rfc compliance
+------------------------------
+
+[Incompat 20101206] Postfix by default no longer adds a "To:
+undisclosed-recipients:;" header when no recipient specified in the
+message header.  The Internet mail RFCs have supported messages
+without recipient header for almost 10 years now.
+
+For backwards compatibility, specify:
+
+/etc/postfix/main.cf
+   undisclosed_recipients_header = To: undisclosed-recipients:;
+
+Note: both the ":" and ";" are required.
+
+Major changes - tls support
+---------------------------
+
+[Incompat 20110102] The Postfix SMTP server now always re-computes
+the SASL mechanism list after successful completion of the STARTTLS
+command. Earlier versions only re-computed the mechanism list when
+the values of smtp_sasl_tls_security_options and smtp_sasl_security_options
+differ.  This could produce incorrect results, because the Dovecot
+authentication server may change responses when the SMTP session
+is encrypted.
+
+[Incompat 20110102] The smtpd_starttls_timeout default value is now
+stress-dependent.  By default, TLS negotiations must now complete
+under overload in 10s instead of 300s.
+
+[Feature 20101223] The new tls_disable_workarounds parameter specifies
+a list or bit-mask of OpenSSL bug work-arounds to disable. This may
+be necessary if one of the work-arounds enabled by default in OpenSSL
+proves to pose a security risk, or introduces an unexpected
+interoperability issue. Some bug work-arounds known to be problematic
+are disabled in the default value of the parameter when linked with
+an OpenSSL library that could be vulnerable. See postconf(5) and
+TLS_README for details.
+
+With "tls_preempt_cipherlist = yes" the Postfix SMTP server will
+choose its most preferred cipher that is supported (offered) by the
+client. This can lead to a more secure or performant cipher choice,
+but may also introduce interoperability problems when a client
+announces support for a cipher that does not work.  See postconf(5)
+and TLS_README for details.
+
+[Feature 20101217] The lower-level code in the TLS engine was
+simplified by removing an unnecessary layer of data copying. OpenSSL
+now writes directly to the network. The difference in performance
+should be hardly noticeable.
+
+[Incompat 20100610] Postfix no longer appends the system-supplied
+default CA certificates to the lists specified with *_tls_CAfile
+or with *_tls_CApath. This prevents third-party certificates from
+getting mail relay permission with the permit_tls_all_clientcerts
+feature.
+
+Unfortunately this change may cause compatibility problems when
+configurations rely on certificate verification for other purposes.
+Specify "tls_append_default_CA = yes" for backwards compatibility.
+
+Major changes - postscreen
+--------------------------
+
+See html/POSTSCREEN_README.html for an introduction to postscreen
+(or the text version, README_FILES/POSTSCREEN_README). The text
+below summarizes milestones in reverse chronological order.
+
+[Incompat 20110111] The postscreen_access_list feature replaces the
+postscreen_whitelist_networks and postscreen_blacklist_networks
+features. Reason: CIDR-style access maps are some 100x faster than
+the code that implemented the postscreen_white/blacklist_networks
+support.  CIDR maps can match about 100 million CIDR patterns/second
+on a modern CPU, which is not blindingly fast but adequate for the
+near future.
+
+[Feature 20110102] STARTTLS support for the postscreen(8) daemon.
+This is implemented by a new tlsproxy(8) daemon that you will need
+to enable in master.cf (see POSTSCREEN_README for instructions).
+tlsproxy(8) implements its own tlsproxy_mumble versions of TLS-related
+smtpd_mumble parameters. This leaves no confusion about which
+parameters will affect tlsproxy(8) behavior, but it adds another
+25 parameters to the documentation.
+
+[Incompat 20100912] If your DNSBL queries have a "secret" in the
+domain name, you must now censor this information from the postscreen(8)
+SMTP replies.  For example:
+
+  /etc/postfix/main.cf:
+      postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
+
+  /etc/postfix/dnsbl_reply:
+      # Secret DNSBL name        Name in postscreen(8) replies
+      secret.zen.spamhaus.org    zen.spamhaus.org
+
+The texthash: format is similar to hash: except that there is no need to
+run postmap(1) before the file can be used, and that it does not detect
+changes after the file is read. It is new with Postfix version 2.8.
+
+[Incompat 20100912] The postscreen "continue" action is now called
+"ignore".  The old name is still supported but no longer documented.
+
+[Incompat 20100912] The postscreen_hangup_action parameter was
+removed. Postscreen now always behaves as if "postscreen_hangup_action
+= drop".
+
+[Incompat 20100912] The postscreen_cache_retention_time default was
+increased from 1d to 7d, to avoid deleting results from expensive
+deep SMTP protocol tests too quickly.
+
+[Feature 20100912] SMTP protocol engine for deep protocol tests,
+and for logging the helo/sender/recipient information when postscreen
+rejects an attempt to deliver mail.
+
+The postscreen SMTP protocol engine implements a number of deep
+protocol tests and defers or rejects all attempts to deliver mail.
+The first test detects unauthorized SMTP command pipelining (an
+SMTP client sends multiple commands, instead of sending one command
+and waiting for the server response); a second deep protocol test
+implements the Postfix SMTP server's smtpd_forbidden_commands feature
+(a client sends commands such as CONNECT, GET, POST); and a third
+deep protocol test detects spambots that send SMTP commands that
+end in newline instead of carriage-return/newline.  Real spambots
+rarely make this mistake, but poorly-written software often does.
+
+Deep protocol tests are disabled by default, because the built-in
+SMTP engine cannot not hand off the "live" connection from a good
+SMTP client to a Postfix SMTP server process. To work around this,
+postscreen(8) defers attempts to deliver mail with a 4XX status,
+and waits for the client to disconnect. The next time a good client
+connects, it will be allowed to talk to a Postfix SMTP server process
+to deliver mail.
+
+[Feature 20100830] Postscreen DNSBL support is extended with optional
+fixed-string filters, with optional integral weight factors, and
+with an adjustable threshold to block SMTP clients with DNSBL score
+>= that threshold. Reply filters will be implemented later.
+
+The updated postscreen configuration syntax is:
+
+    postscreen_dnsbl_sites = domain[=ipaddr][*weight] ...
+    postscreen_dnsbl_threshold = score
+
+Elements inside [] are optional, ipaddr is an IPv4 address, and
+weight and score are integral numbers. The [] are not part of the
+postscreen_dnsbl_sites input.  By default, weight and score are
+equal to 1, and entries without filter will match any non-error
+DNSBL reply.  Use a negative weight value for whitelisting.
+
+Examples:
+
+To use example.com as a high-confidence blocklist, and to block
+mail with example.net and example.org only when both agree, use:
+
+    postscreen_dnsbl_threshold = 2
+    postscreen_dnsbl_sites = example.com*2, example.net, example.org
+
+To filter only DNSBL replies containing 127.0.0.4, use:
+
+    postscreen_dnsbl_sites = example.com=127.0.0.4
+
+See also postconf(5) for the fine details.
+
+[Incompat 20100101] When periodic cache cleanup is enabled (the
+default), the postscreen(8) server now requires that the cache
+database supports the "delete" and "sequence" operations.  To disable
+periodic cache cleanup specify a zero postscreen_cache_cleanup_interval
+value.
+
+[Feature 20100101] Periodic cache cleanup for the postscreen(8)
+cache database. The time between cache cleanup runs is controlled
+with the postscreen_cache_cleanup_interval (default: 12h) parameter.
+Cache cleanup increases the database access latency, so this should
+not be run more often than necessary.
+
+In addition, the postscreen_cache_retention_time (default: 1d)
+parameter specifies how long to keep an expired entry in the cache.
+This prevents a client from being logged as "NEW" after its record
+expired only a little while ago.
+
+[Feature 20091008] Prototype postscreen(8) server that runs a number
+of time-consuming checks in parallel for all incoming SMTP connections,
+before clients are allowed to talk to a real Postfix SMTP server.
+It detects clients that start talking too soon, or clients that
+appear on DNS blocklists, or clients that hang up without sending
+any command.
+
+By doing these checks in a single postscreen(8) process, Postfix
+can avoid wasting one SMTP server process per connection. A side
+benefit of postscreen(8)'s DNSBL lookups is that DNS records are
+already cached before the Postfix SMTP server looks them up later.
+
+postscreen(8) maintains a temporary whitelist of positive decisions.
+Once an SMTP client is whitelisted, it is immediately forwarded to
+a real Postfix SMTP server process without further checking.
+
+By default, the program logs only statistics, and it does not run
+any checks on clients in mynetworks (primarily, to avoid problems
+with buggy SMTP implementations in network appliances).  The logging
+function alone is already useful for research.
+