Adding upstream version 3.5.24.upstream/3.5.24upstream

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

1 files changed, 761 insertions, 0 deletions

diff --git a/RELEASE_NOTES-2.3 b/RELEASE_NOTES-2.3
new file mode 100644
index 0000000..a1ac8c0
--- /dev/null
+++ b/RELEASE_NOTES-2.3
@@ -0,0 +1,761 @@
+The stable Postfix release is called postfix-2.3.x where 2=major
+release number, 3=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.4-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.
+
+Critical notes
+--------------
+
+See RELEASE_NOTES_2.2 if you upgrade from Postfix 2.1 or earlier.
+
+Some Postfix internal protocols have changed.  You need to "postfix
+reload" or restart Postfix, otherwise many servers will log warning
+messages like "unexpected attribute xxx" or "problem talking to
+service yyy", and mail will not be delivered.
+
+The Sendmail-compatible Milter support introduces three new queue
+file record types. As long as you leave this feature turned off,
+you can still go back to Postfix version 2.2 without losing mail
+that was received by Postfix 2.3.
+
+Major changes - DNS lookups
+---------------------------
+
+[Incompat 20050726] Name server replies that contain a malformed
+hostname are now flagged as permanent errors instead of transient
+errors. This change works around a questionable proposal to use
+syntactically invalid hostnames in MX records.
+
+Major changes - DSN
+-------------------
+
+[Feature 20050615] DSN support as described in RFC 3461 .. RFC 3464.
+This gives senders control over successful and failed delivery
+notifications.  DSN involves extra parameters to the SMTP "MAIL
+FROM" and "RCPT TO" commands, as well as extra Postfix sendmail
+command line options for mail submission.
+
+See DSN_README for details. Some implementation notes can be found
+in implementation-notes/DSN.
+
+[Incompat 20050615] The new DSN support conflicts with VERP support.
+For Sendmail compatibility, Postfix now uses the sendmail -V command
+line option for DSN.  To request VERP style delivery, you must now
+specify -XV instead of -V.  The Postfix sendmail command will
+recognize if you try to use -V for VERP-style delivery.  It will
+usually do the right thing, and remind you of the new syntax.
+
+[Incompat 20050828] Postfix no longer sends DSN SUCCESS notification
+after virtual alias expansions when the cleanup server rejects the
+content or size of mail that was submitted with the Postfix sendmail
+command, mail that was forwarded with the local(8) delivery agent,
+or mail that was re-queued with "postsuper -r". Since all the
+recipients are reported as failed, the SUCCESS notification seems
+redundant.
+
+Major changes - LMTP client
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051208] The SMTP client now implements the LMTP protocol.
+Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
+This means there are lot of new LMTP features, including support
+for TLS and for the shared connection cache. See the "SMTP client"
+section for details.
+
+[Incompat 20051208] The LMTP client now reports the server as
+"myhostname[/path/name]".  With the real server hostname in delivery
+status reports, the information will be more useful.
+
+Major changes - Milter support
+------------------------------
+
+[Feature 20060515] Milter (mail filter) application support,
+compatible with Sendmail version 8.13.6 and earlier. This allows
+you to run a large number of plug-ins to reject unwanted mail, and
+to sign mail with for example domain keys. All Milter functions are
+implemented except replacing the message body, which will be added
+later. Milters are before-queue filters, so they don't change the
+queue ID.
+
+See the MILTER_README document for a discussion of how to use Milter
+support with Postfix, and limitations of the current implementation.
+
+The Sendmail-compatible Milter support introduces three new queue
+file record types. As long as you leave this feature turned off,
+you can still go back to Postfix version 2.2 without losing mail
+that was received by Postfix 2.3.
+
+[Incompat 20060515] Milter support introduces new logfile event
+types: milter-reject, milter-discard and milter-hold, that identify
+actions from Milter applications. This may affect logfile processing
+software.
+
+Major changes - SASL authentication
+-----------------------------------
+
+[Feature 20051220] Plug-in support for SASL authentication in the
+SMTP server and in the SMTP/LMTP client. With this, Postfix can
+support multiple SASL implementations without source code patches.
+Some distributors may even make SASL support a run-time linking
+option, just like they already do with Postfix lookup tables.
+
+Hints and tips for plug-in developers are in the xsasl/README file.
+
+For backwards compatibility the default plug-in type is Cyrus SASL,
+so everything should behave like it did before. Some error messages
+are slightly different, but these are generally improvements.
+
+The "postconf -a" command shows what plug-in implementations are
+available for the SMTP server, and "postconf -A" does the same for
+the SMTP/LMTP client.  Plug-in implementations are selected with
+the smtpd_sasl_type, smtp_sasl_type and lmtp_sasl_type configuration
+parameters.
+
+Other new configuration parameters are smtpd_sasl_path, smtp_sasl_path
+and lmtp_sasl_path. These are better left alone; they are introduced
+for the convenience of other SASL implementations.
+
+[Feature 20051222] Dovecot SASL support (SMTP server only). Details
+can be found in the SASL_README document.
+
+[Incompat 20051220] The Postfix-with-Cyrus-SASL build procedure has
+changed. You now need to specify -DUSE_CYRUS_SASL in addition to
+-DUSE_SASL_AUTH or else you end up without any Cyrus SASL support.
+The error messages are:
+
+    unsupported SASL server implementation: cyrus
+    unsupported SASL client implementation: cyrus
+
+[Feature 20051125] This snapshot adds support for sender-dependent
+ISP accounts.
+
+- Sender-dependent smarthost lookup tables.  The maps are searched
+  with the sender address and with the sender @domain.  The result
+  overrides the global relayhost setting, but otherwise has identical
+  behavior. See the postconf(5) manual page for more details.
+
+  Example:
+    /etc/postfix/main.cf:
+	sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
+
+- Sender-dependent SASL authentication support. This disables SMTP
+  connection caching to ensure that mail from different senders
+  will use the correct authentication credentials. The SMTP SASL
+  password file is first searched by sender address, and then by
+  the remote domain and hostname as usual.
+
+  Example:
+    /etc/postfix/main.cf:
+	smtp_sasl_auth_enable = yes
+	smtp_sender_dependent_authentication = yes
+	smtp_sasl_password_maps = hash:/etc/postfix/sasl_pass
+
+[Incompat 20060707] The SMTP/LMTP client now defers delivery when
+a SASL password exists but the server does not announce support for
+SASL authentication.  This can happen with servers that announce
+SASL support only when TLS is turned on.  When an opportunistic TLS
+handshake fails, Postfix >= 2.3 retries delivery in plaintext, and
+the remote server rejects mail from the unauthenticated client.
+Specify "smtp_sasl_auth_enforce = no" to deliver mail anyway.
+
+Major changes - SMTP client
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051208] The SMTP client now implements the LMTP protocol.
+Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
+This means there are lot of new LMTP features, including support
+for TLS and for the shared connection cache.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
+
+[Incompat 20060103] The Postfix SMTP/LMTP client no longer defers
+mail delivery when it receives a malformed SMTP server reply in a
+session with command pipelining.  When helpful warnings are enabled,
+it will suggest that command pipelining be disabled for the affected
+destination.
+
+[Incompat 20051208] The fallback_relay feature is renamed to
+smtp_fallback_relay, to make clear that the combined SMTP/LMTP
+client uses this setting only for SMTP deliveries. The old name
+still works.
+
+[Incompat 20051106] The relay=... logging has changed and now
+includes the remote SMTP server port number as hostname[hostaddr]:port.
+
+[Incompat 20051026] The smtp_connection_cache_reuse_limit parameter
+(which limits the number of deliveries per SMTP connection) is
+replaced by the new smtp_connection_reuse_time_limit parameter (the
+time after which a connection is no longer stored into the connection
+cache).
+
+[Feature 20051026] This snapshot addresses a performance stability
+problem with remote SMTP servers. The problem is not specific to
+Postfix: it can happen when any MTA sends large amounts of SMTP
+email to a site that has multiple MX hosts. The insight that led
+to the solution, as well as an initial implementation, are due to
+Victor Duchovni.
+
+The problem starts when one of a set of MX hosts becomes slower
+than the rest.  Even though SMTP clients connect to fast and slow
+MX hosts with equal probability, the slow MX host ends up with more
+simultaneous inbound connections than the faster MX hosts, because
+the slow MX host needs more time to serve each client request.
+
+The slow MX host becomes a connection attractor.  If one MX host
+becomes N times slower than the rest, it dominates mail delivery
+latency unless there are more than N fast MX hosts to counter the
+effect. And if the number of MX hosts is smaller than N, the mail
+delivery latency becomes effectively that of the slowest MX host
+divided by the total number of MX hosts.
+
+The solution uses connection caching in a way that differs from
+Postfix 2.2.  By limiting the amount of time during which a connection
+can be used repeatedly (instead of limiting the number of deliveries
+over that connection), Postfix not only restores fairness in the
+distribution of simultaneous connections across a set of MX hosts,
+it also favors deliveries over connections that perform well, which
+is exactly what we want.
+
+The smtp_connection_reuse_time_limit feature implements the connection
+reuse time limit as discussed above.  It limits the amount of time
+after which an SMTP connection is no longer stored into the connection
+cache. The default limit, 300s, can result in a huge number of
+deliveries over a single connection.
+
+This solution will be complete when Postfix logging is updated to
+include information about the number of times that a connection was
+used. This information is needed to diagnose inter-operability
+problems with servers that exhibit bugs when they receive multiple
+messages over the same connection.
+
+[Incompat 20050627] The Postfix SMTP client no longer applies the
+smtp_mx_session_limit to non-permanent errors during the TCP, SMTP,
+HELO or TLS handshake.  Previous versions did that only with TCP
+and SMTP handshake errors.
+
+[Incompat 20050622] The Postfix SMTP client by default limits the
+number of MX server addresses to smtp_mx_address_limit=5. Previously
+this limit was disabled by default. The new limit prevents Postfix
+from spending lots of time trying to connect to lots of bogus MX
+servers.
+
+Major changes - SMTP server
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051222] To accept the non-compliant user@ipaddress form,
+specify "resolve_numeric_domain = yes".  Postfix will deliver the
+mail to user@[ipaddress] instead.
+
+[Incompat 20051202] The Postfix SMTP server now refuses to receive
+mail from the network if it isn't running with postfix mail_owner
+privileges.  This prevents surprises when, for example, "sendmail
+-bs" is configured to run as root from xinetd.
+
+[Incompat 20051121] Although the permit_mx_backup feature still
+accepts mail for authorized destinations (see permit_mx_backup for
+definition), with all other destinations it now requires that the
+local MTA is listed as non-primary MX server. This prevents mail
+loop problems when someone points their primary MX record at a
+Postfix system.
+
+[Feature 20051011] Optional suppression of remote SMTP client
+hostname lookup and hostname verification. Specify "smtpd_peername_lookup
+= no" to eliminate DNS lookup latencies, but do so only under extreme
+conditions, as it makes Postfix logging less informative.
+
+[Feature 20050724] SMTPD Access control based on the existence of
+an address->name mapping, with reject_unknown_reverse_client_hostname.
+There is no corresponding access table lookup feature, because the
+name is not validated in any way (except that it has proper syntax).
+
+Several confusing SMTPD access restrictions were renamed:
+
+    reject_unknown_client -> reject_unknown_client_hostname,
+    reject_unknown_hostname -> reject_unknown_helo_hostname,
+    reject_invalid_hostname -> reject_invalid_helo_hostname,
+    reject_non_fqdn_hostname -> reject_non_fqdn_helo_hostname.
+
+The old names are still recognized and documented.
+
+Major changes - TLS
+-------------------
+
+Major revisions were made to Postfix TLS support; see TLS_README
+for the details. For backwards compatibility, the old TLS policy
+user interface will be kept intact for a few releases so that sites
+can upgrade Postfix without being forced to use a different TLS
+policy mechanism.
+
+[Feature 20060614] New concept: TLS security levels ("none", "may",
+"encrypt", "verify" or "secure") in the Postfix SMTP client.  You
+can specify the TLS security level via the smtp_tls_security_level
+parameter.  This is more convenient than controlling TLS with the
+multiple smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername,
+parameters.
+
+[Feature 20060709] TLS security levels ("none", "may", "encrypt")
+in the Postfix SMTP server. You specify the security level with the
+smtpd_tls_security_level parameter. This overrides the multiple
+smtpd_use_tls and smtpd_enforce_tls parameters.  When one of the
+unimplemented "verify" or "secure" levels is specified, the Postfix
+SMTP server logs a warning and uses "encrypt" instead.
+
+[Feature 20060123] A new per-site TLS policy mechanism for the
+Postfix SMTP client that supports the new TLS security levels,
+and that eliminates DNS spoofing attacks more effectively.
+
+[Feature 20060626] Both the Postfix SMTP client and server can be
+configured without a client or server certificate. An SMTP server
+without certificate can use only anonymous ciphers, and will not
+inter-operate with most clients.
+
+The Postfix SMTP server supports anonymous ciphers when 1) no client
+certificates are requested or required, and 2) the administrator
+has not excluded the "aNULL" OpenSSL cipher type with the
+smtpd_tls_exclude_ciphers parameter.
+
+The Postfix SMTP client supports anonymous ciphers when 1) no server
+certificate is required and 2) the administrator has not excluded
+the "aNULL" OpenSSL cipher type with the smtp_tls_exclude_ciphers
+parameter.
+
+[Incompat 20060707] The SMTPD policy client now encodes the
+ccert_subject and ccert_issuer attributes as xtext. Some characters
+are represented by +XX, where XX is the two-digit hexadecimal
+representation of the character value.
+
+[Feature 20060614] The smtpd_tls_protocols parameter restricts the
+list of TLS protocols supported by the SMTP server.  This is
+recommended for use with MSA configurations only.  It should not
+be used with MX hosts that receive mail from the Internet, as it
+reduces inter-operability.
+
+[Incompat 20060614] The smtp_tls_cipherlist parameter only applies
+when TLS is mandatory.  It is ignored with opportunistic TLS sessions.
+
+[Incompat 20060614] At (lmtp|smtp|smtpd)_tls_loglevel >= 2, Postfix
+now also logs TLS session cache activity. Use level 2 and higher
+for debugging only; use levels 0 or 1 as production settings.
+
+[Incompat 20060207] The Postfix SMTP server no longer complains
+when TLS support is not compiled in while permit_tls_clientcerts,
+permit_tls_all_clientcerts, or check_ccert_access are specified in
+main.cf. These features now are effectively ignored.  However, the
+reject_plaintext_session feature is not ignored and will reject
+plain-text mail.
+
+[Feature 20060123] Some obscure behavior was eliminated from the
+smtp_tls_per_site feature, without changes to the user interface.
+Some Postfix internals had to be re-structured for the new TLS
+policy mechanism; for this, smtp_tls_per_site had to be re-implemented.
+The obscure behavior was found during compatibility testing.
+
+[Feature 20051011] Optional protection against SMTP clients that
+hammer the server with too many new (i.e. uncached) SMTP-over-TLS
+sessions. Cached sessions are much less expensive in terms of CPU
+cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
+to specify a limit that is at least the inbound client concurrency
+limit, or else you may deny legitimate service requests.
+
+Major changes - VERP
+--------------------
+
+[Incompat 20050615] The new DSN support conflicts with VERP support.
+For Sendmail compatibility, Postfix now uses the sendmail -V command
+line option for DSN.  In order to request VERP style delivery, you
+must now specify -XV instead of -V.  The Postfix sendmail command
+will recognize if you try to use -V for VERP-style delivery.  It
+will do the right thing and will remind you of the new syntax.
+
+Major changes - XCLIENT and XFORWARD
+------------------------------------
+
+[Incompat 20060611] The SMTP server XCLIENT implementation has
+changed. The SMTP server now resets state to the initial server
+greeting stage, immediately before the EHLO/HELO greeting.  This
+was needed to correctly simulate the effect of connection-level
+access restrictions.  Without this change, XCLIENT would not work
+at all with Milter applications.
+
+[Incompat 20060611] The SMTP server XCLIENT and XFORWARD commands
+now expect that attributes are xtext encoded (RFC 1891). For backwards
+compatibility they will also accept unencoded attribute values. The
+XFORWARD client code in the SMTP client and in the SMTPD_PROXY
+client now always encode attribute values. This change will have a
+visible effect only for malformed hostname and helo parameter values.
+
+For more details, see the XCLIENT_README and XFORWARD_README
+documents.
+
+Major changes - address manipulation
+------------------------------------
+
+[Incompat 20060123] Postfix now preserves uppercase information
+while mapping addresses with canonical, virtual, relocated or generic
+maps; this happens even with $number substitutions in regular
+expression maps. However, the local(8) and virtual(8) delivery
+agents still fold addresses to lower case.
+
+As a side effect, Postfix now also does a better job at being case
+insensitive where it should be, for example while searching per-host
+TLS policies or SASL passwords.
+
+By default, Postfix now folds the search string to lowercase only
+with tables that have fixed-case lookup fields such as btree:,
+hash:, dbm:, ldap:, or *sql:. The search string is no longer case
+folded with tables whose lookup fields can match both upper or lower
+case, such as regexp:, pcre:, or cidr:.
+
+For safety reasons, Postfix no longer allows $number substitution
+in regexp: or pcre: transport tables or per-sender relayhost tables.
+
+Major changes - bounce message templates
+----------------------------------------
+
+[Feature 20051113] Configurable bounce messages, based on a format
+that was developed by Nicolas Riendeau. The file with templates is
+specified with the bounce_template_file parameter. Details are in
+the bounce(5) manual page, and examples of the built-in templates
+can be found in $config_directory/bounce.cf.default. The template
+for the default bounce message looks like this:
+
+    failure_template = <<EOF
+    Charset: us-ascii
+    From: MAILER-DAEMON (Mail Delivery System)
+    Subject: Undelivered Mail Returned to Sender
+    Postmaster-Subject: Postmaster Copy: Undelivered Mail
+
+    This is the $mail_name program at host $myhostname.
+
+    I'm sorry to have to inform you that your message could not
+    be delivered to one or more recipients. It's attached below.
+
+    For further assistance, please send mail to <postmaster>
+
+    If you do so, please include this problem report. You can
+    delete your own text from the attached returned message.
+
+                            The $mail_name program
+    EOF
+
+Major changes - built-in filters
+--------------------------------
+
+[Feature 20050828] Configurable filters to reject or remove unwanted
+characters in email content. The message_reject_characters and
+message_strip_characters parameters understand the usual C-like
+escape sequences: \a \b \f \n \r \t \v \ddd (up to three octal
+digits) and \\.
+
+[Incompat 20050828] When a header/body_checks rule or when
+message_reject_characters rejects mail that was submitted with the
+Postfix sendmail command (or re-queued with "postsuper -r"), the
+returned message is now limited to just the message headers, to
+avoid the risk of exposure to harmful content in the message body
+or attachments.
+
+Major changes - database support
+--------------------------------
+
+[Incompat 20060611] The PostgreSQL client was updated after the
+PostgreSQL developers made major database API changes in response
+to SQL injection problems.  This breaks support for PGSQL versions
+prior to 8.1.4, 8.0.8, 7.4.13, and 7.3.15. Support for these requires
+major code changes which are not possible in the time that is left
+for completing the Postfix 2.3 stable release.
+
+Major changes - enhanced status codes
+-------------------------------------
+
+[Feature 20050328] This release introduces support for RFC 3463
+enhanced status codes.  For example, status code 5.1.1 means
+"recipient unknown". Postfix recognizes enhanced status codes in
+remote server replies, generates enhanced status codes while handling
+email, and reports enhanced status codes in non-delivery notifications.
+This improves the user experience with mail clients that translate
+enhanced status codes into text in the user's own language.
+
+You can, but don't have to, specify RFC 3463 enhanced status codes
+in the output from commands that receive mail from a pipe. If a
+command terminates with non-zero exit status, and an enhanced status
+code is present at the beginning of the command output, then that
+status code takes precedence over the non-zero exit status.
+
+You can, but don't have to, specify RFC 3463 enhanced status codes
+in Postfix access maps, header/body_checks REJECT actions, or in
+RBL replies.  For example:
+
+    REJECT 5.7.1 You can't go here from there
+
+The status 5.7.1 means "no authorization, message refused", and is
+the default for access maps, header/body_checks REJECT actions, and
+for RBL replies.
+
+[Feature 20050328] If you specify your own enhanced status code,
+the Postfix SMTP server will automatically change a leading '5'
+digit (hard error) into '4' where appropriate.  This is needed, for
+example, with soft_bounce=yes.
+
+[Feature 20050510] This release improves usability of enhanced
+status codes in Postfix access tables, RBL reply templates and in
+transport maps that use the error(8) delivery agent.
+
+- When the SMTP server rejects a sender address, it transforms a
+  recipient DSN status (e.g., 4.1.1-4.1.6) into the corresponding
+  sender DSN status, and vice versa.
+
+- When the SMTP server rejects non-address information (such as the
+  HELO command parameter or the client hostname/address), it
+  transforms a sender or recipient DSN status into a generic
+  non-address DSN status (e.g., 4.0.0).
+
+These transformations are needed when the same access table or RBL
+reply template are used for client, helo, sender, or recipient
+restrictions; or when the same error(8) mailer information is used
+for both senders and recipients.
+
+Major changes - local alias expansion
+-------------------------------------
+
+[Incompat 20051011] The Postfix local(8) delivery agent no longer
+updates its idea of the Delivered-To: address while it expands
+aliases or .forward files. With deeply nested aliases or .forward
+files, this can greatly reduce the number of queue files and cleanup
+process instances. To get the earlier behavior, specify
+"frozen_delivered_to = no".
+
+The frozen_delivered_to feature can help to alleviate a long-standing
+problem with multiple deliveries to recipients that are listed
+multiple times in a hierarchy of nested aliases. For this to work,
+only the top-level alias should have an owner- alias, and none of
+the subordinate aliases.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20060515] Milter support introduces new logfile event
+types: milter-reject, milter-discard and milter-hold, that identify
+actions from Milter applications. This may affect logfile processing
+software.
+
+[Incompat 20051106] The relay=... logging has changed and now
+includes the remote SMTP server port number as hostname[hostaddr]:port.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
+
+[Incompat 20051105] All delay logging now has sub-second resolution,
+including the over-all "delay=nnn" logging.  A patch is available
+for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
+has been updated (auxiliary/qshape/qshape.pl).
+
+[Feature 20051103] This release makes a beginning with a series of
+new attributes in Postfix logfile records.
+
+- Better insight into the nature of performance bottle necks, with
+  detailed logging of delays in various stages of message delivery.
+  Postfix logs additional delay information as "delays=a/b/c/d"
+  where a=time before queue manager, including message transmission;
+  b=time in queue manager; c=connection setup time including DNS,
+  HELO and TLS; d=message transmission time.
+
+- Logging of the connection reuse count when SMTP connections are
+  used for more than one message delivery.  This information is
+  needed because Postfix can now reuse connections hundreds of times
+  or more. Logging of the connection reuse count can help to diagnose
+  inter-operability problems with servers that suffer from memory
+  leaks or other resource leaks.
+
+At this point the Postfix logging for a recipient looks like this:
+
+    Nov  3 16:04:31 myname postfix/smtp[30840]: 19B6B2900FE:
+    to=<wietse@test.example.com>, orig_to=<wietse@test>,
+    relay=mail.example.com[1.2.3.4], conn_use=2, delay=0,
+    delays=0/0.01/0.05/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok)
+
+The following two logfile fields may or may not be present:
+
+    orig_to     This is omitted when the address did not change.
+    conn_use    This is omitted when a connection is used once.
+
+[Incompat 20050503] The format of some "warning:" messages in the
+maillog has changed so that they are easier to sort:
+
+- The logging now talks about "access table", instead of using three
+  different expressions "access table", "access map" and "SMTPD
+  access map" for the same thing.
+
+- "non-SMTP command" is now logged BEFORE the client name/address
+  and the offending client input, instead of at the end.
+
+[Incompat 20050328] The logging format has changed. Postfix delivery
+agents now log the RFC 3463 enhanced status code as "dsn=x.y.z"
+where y and z can be up to three digits each.
+
+[Incompat 20051208] The LMTP client now reports the server as
+"myhostname[/path/name]".  With the real server hostname in delivery
+status reports, the information will be more useful.
+
+Major changes - performance
+---------------------------
+
+[Incompat 20051105] All delay logging now has sub-second resolution,
+including the over-all "delay=nnn" logging.  A patch is available
+for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
+has been updated (auxiliary/qshape/qshape.pl).
+
+[Incompat 20050622] The Postfix SMTP client by default limits the
+number of MX server addresses to smtp_mx_address_limit=5. Previously
+this limit was disabled by default. The new limit prevents Postfix
+from spending lots of time trying to connect to lots of bogus MX
+servers.
+
+[Feature 20051026] This snapshot addresses a performance stability
+problem with remote SMTP servers. The problem is not specific to
+Postfix: it can happen when any MTA sends large amounts of SMTP
+email to a site that has multiple MX hosts. The insight that led
+to the solution, as well as an initial implementation, are due to
+Victor Duchovni.
+
+The problem starts when one of a set of MX hosts becomes slower
+than the rest.  Even though SMTP clients connect to fast and slow
+MX hosts with equal probability, the slow MX host ends up with more
+simultaneous inbound connections than the faster MX hosts, because
+the slow MX host needs more time to serve each client request.
+
+The slow MX host becomes a connection attractor.  If one MX host
+becomes N times slower than the rest, it dominates mail delivery
+latency unless there are more than N fast MX hosts to counter the
+effect. And if the number of MX hosts is smaller than N, the mail
+delivery latency becomes effectively that of the slowest MX host
+divided by the total number of MX hosts.
+
+The solution uses connection caching in a way that differs from
+Postfix 2.2.  By limiting the amount of time during which a connection
+can be used repeatedly (instead of limiting the number of deliveries
+over that connection), Postfix not only restores fairness in the
+distribution of simultaneous connections across a set of MX hosts,
+it also favors deliveries over connections that perform well, which
+is exactly what we want.
+
+The smtp_connection_reuse_time_limit feature implements the connection
+reuse time limit as discussed above.  It limits the amount of time
+after which an SMTP connection is no longer stored into the connection
+cache. The default limit, 300s, can result in a huge number of
+deliveries over a single connection.
+
+This solution will be complete when Postfix logging is updated to
+include information about the number of times that a connection was
+used. This information is needed to diagnose inter-operability
+problems with servers that exhibit bugs when they receive multiple
+messages over the same connection.
+
+[Feature 20051011] Optional protection against SMTP clients that
+hammer the server with too many new (i.e. uncached) SMTP-over-TLS
+sessions. Cached sessions are much less expensive in terms of CPU
+cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
+to specify a limit that is at least the inbound client concurrency
+limit, or else you may deny legitimate service requests.
+
+[Feature 20051011] Optional suppression of remote SMTP client
+hostname lookup and hostname verification. Specify "smtpd_peername_lookup
+= no" to eliminate DNS lookup latencies, but do so only under extreme
+conditions, as it makes Postfix logging less informative.
+
+Major changes - portability
+---------------------------
+
+[Incompat 20050716] Internal interfaces have changed; this may break
+third-party patches because the types of function arguments and of
+result values have changed.  The types of buffer lengths and offsets
+were changed from "int" or "unsigned int" (32 bit on 32-bit and
+LP64 systems) to "ssize_t" or "size_t" (64 bit on LP64 systems, 32
+bit on 32-bit systems).
+
+This change makes no difference in Postfix behavior on 32-bit
+systems. On LP64 systems, however, this change not only eliminates
+some obscure portability bugs, it also eliminates unnecessary
+conversions between 32/64 bit integer types, because many system
+library routines take "(s)size_t" arguments or return "(s)size_t"
+values.
+
+This change may break software on LP64 systems 1) when Postfix is
+linked with pre-compiled code that was compiled with old Postfix
+interface definitions and 2) when compiling Postfix source that was
+modified by a third-party patch: incorrect code will be generated
+when the patch passes the wrong integer argument type in contexts
+that disable automatic argument type conversions.  Examples of such
+contexts are formatting with printf-like arguments, and invoking
+functions that write Postfix request or reply attributes across
+inter-process communication channels.  Unfortunately, gcc reports
+"(unsigned) int" versus "(s)size_t" format string argument mis-matches
+only on LP64 systems.
+
+Major changes - safety
+----------------------
+
+[Incompat 20051121] Although the permit_mx_backup feature still
+accepts mail for authorized destinations (see permit_mx_backup for
+definition), with all other destinations it now requires that the
+local MTA is listed as non-primary MX. This prevents mail loop
+problems when someone points the primary MX record at a Postfix
+system.
+
+[Incompat 20051011] The Postfix local(8) delivery agent no longer
+updates its idea of the Delivered-To: address while it expands
+aliases or .forward files. With deeply nested aliases or .forward
+files, this can greatly reduce the number of queue files and cleanup
+process instances. To get the earlier behavior, specify
+"frozen_delivered_to = no".
+
+The frozen_delivered_to feature can help to alleviate a long-standing
+problem with multiple deliveries to recipients that are listed
+multiple times in a hierarchy of nested aliases. For this to work,
+only the top-level alias should have an owner- alias, and none of
+the subordinate aliases.
+
+[Incompat 20050828] When a header/body_checks rule or when
+message_reject_characters rejects mail that was submitted with the
+Postfix sendmail command (or re-queued with "postsuper -r"), the
+returned message is now limited to just the message headers, to
+avoid the risk of exposure to harmful content in the message body
+or attachments.
+
+[Incompat 20051202] The Postfix SMTP server now refuses to receive
+mail from the network if it isn't running with postfix mail_owner
+privileges.  This prevents surprises when, for example, "sendmail
+-bs" is configured to run as root from xinetd.
+
+[Incompat 20060123] For safety reasons, Postfix no longer allows
+$number substitution in regexp: or pcre: transport tables or
+per-sender relayhost tables.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.