-$Cambridge: exim/src/README.UPDATING,v 1.9 2005/10/03 13:25:32 ph10 Exp $
-
This document contains detailed information about incompatibilities that might
be encountered when upgrading from one release of Exim to another. The
information is in reverse order of release numbers. Mostly these are relatively
that might affect a running system.
+Exim version 4.82
+-----------------
+
+ * New option gnutls_enable_pkcs11 defaults false; if you have GnuTLS 2.12.0
+ or later and do want PKCS11 modules to be autoloaded, then set this option.
+
+ * A per-transport wait-<name> database is no longer updated if the transport
+ sets "connection_max_messages" to 1, as it can not be used and causes
+ unnecessary serialisation and load. External tools tracking the state of
+ Exim by the hints databases may need modification to take this into account.
+
+
+Exim version 4.80
+-----------------
+
+ * BEWARE backwards-incompatible changes in SSL libraries, thus the version
+ bump. See points below for details.
+ Also an LDAP data returned format change.
+
+ * The value of $tls_peerdn is now print-escaped when written to the spool file
+ in a -tls_peerdn line, and unescaped when read back in. We received reports
+ of values with embedded newlines, which caused spool file corruption.
+
+ If you have a corrupt spool file and you wish to recover the contents after
+ upgrading, then lock the message, replace the new-lines that should be part
+ of the -tls_peerdn line with the two-character sequence \n and then unlock
+ the message. No tool has been provided as we believe this is a rare
+ occurence.
+
+ * For OpenSSL, SSLv2 is now disabled by default. (GnuTLS does not support
+ SSLv2). RFC 6176 prohibits SSLv2 and some informal surveys suggest no
+ actual usage. You can re-enable with the "openssl_options" Exim option,
+ in the main configuration section. Note that supporting SSLv2 exposes
+ you to ciphersuite downgrade attacks.
+
+ * With OpenSSL 1.0.1+, Exim now supports TLS 1.1 and TLS 1.2. If built
+ against 1.0.1a then you will get a warning message and the
+ "openssl_options" value will not parse "no_tlsv1_1": the value changes
+ incompatibly between 1.0.1a and 1.0.1b, because the value chosen for 1.0.1a
+ is infelicitous. We advise avoiding 1.0.1a.
+
+ "openssl_options" gains "no_tlsv1_1", "no_tlsv1_2" and "no_compression".
+
+ COMPATIBILITY WARNING: The default value of "openssl_options" is no longer
+ "+dont_insert_empty_fragments". We default to "+no_sslv2".
+ That old default was grandfathered in from before openssl_options became a
+ configuration option.
+ Empty fragments are inserted by default through TLS1.0, to partially defend
+ against certain attacks; TLS1.1+ change the protocol so that this is not
+ needed. The DIEF SSL option was required for some old releases of mail
+ clients which did not gracefully handle the empty fragments, and was
+ initially set in Exim release 4.31 (see ChangeLog, item 37).
+
+ If you still have affected mail-clients, and you see SSL protocol failures
+ with this release of Exim, set:
+ openssl_options = +dont_insert_empty_fragments
+ in the main section of your Exim configuration file. You're trading off
+ security for compatibility. Exim is now defaulting to higher security and
+ rewarding more modern clients.
+
+ If the option tls_dhparams is set and the parameters loaded from the file
+ have a bit-count greater than the new option tls_dh_max_bits, then the file
+ will now be ignored. If this affects you, raise the tls_dh_max_bits limit.
+ We suspect that most folks are using dated defaults and will not be affected.
+
+ * Ldap lookups returning multi-valued attributes now separate the attributes
+ with only a comma, not a comma-space sequence. Also, an actual comma within
+ a returned attribute is doubled. This makes it possible to parse the
+ attribute as a comma-separated list. Note the distinction from multiple
+ attributes being returned, where each one is a name=value pair.
+
+ If you are currently splitting the results from LDAP upon a comma, then you
+ should check carefully to see if adjustments are needed.
+
+ This change lets cautious folks distinguish "comma used as separator for
+ joining values" from "comma inside the data".
+
+ * accept_8bitmime now defaults on, which is not RFC compliant but is better
+ suited to today's Internet. See http://cr.yp.to/smtp/8bitmime.html for a
+ sane rationale. Those who wish to be strictly RFC compliant, or know that
+ they need to talk to servers that are not 8-bit-clean, now need to take
+ explicit configuration action to default this option off. This is not a
+ new option, you can safely force it off before upgrading, to decouple
+ configuration changes from the binary upgrade while remaining RFC compliant.
+
+ * The GnuTLS support has been mostly rewritten, to use APIs which don't cause
+ deprecation warnings in GnuTLS 2.12.x. As part of this, these three options
+ are no longer supported:
+
+ gnutls_require_kx
+ gnutls_require_mac
+ gnutls_require_protocols
+
+ Their functionality is entirely subsumed into tls_require_ciphers. In turn,
+ tls_require_ciphers is no longer an Exim list and is not parsed by Exim, but
+ is instead given to gnutls_priority_init(3), which expects a priority string;
+ this behaviour is much closer to the OpenSSL behaviour. See:
+
+ http://www.gnu.org/software/gnutls/manual/html_node/Priority-Strings.html
+
+ for fuller documentation of the strings parsed. The three gnutls_require_*
+ options are still parsed by Exim and, for this release, silently ignored.
+ A future release will add warnings, before a later still release removes
+ parsing entirely and the presence of the options will be a configuration
+ error.
+
+ Note that by default, GnuTLS will not accept RSA-MD5 signatures in chains.
+ A tls_require_ciphers value of NORMAL:%VERIFY_ALLOW_SIGN_RSA_MD5 may
+ re-enable support, but this is not supported by the Exim maintainers.
+ Our test suite no longer includes MD5-based certificates.
+
+ This rewrite means that Exim will continue to build against GnuTLS in the
+ future, brings Exim closer to other GnuTLS applications and lets us add
+ support for SNI and other features more readily. We regret that it wasn't
+ feasible to retain the three dropped options.
+
+ * If built with TLS support, then Exim will now validate the value of
+ the main section tls_require_ciphers option at start-up. Before, this
+ would cause a STARTTLS 4xx failure, now it causes a failure to start.
+ Running with a broken configuration which causes failures that may only
+ be left in the logs has been traded off for something more visible. This
+ change makes an existing problem more prominent, but we do not believe
+ anyone would deliberately be running with an invalid tls_require_ciphers
+ option.
+
+ This also means that library linkage issues caused by conflicts of some
+ kind might take out the main daemon, not just the delivery or receiving
+ process. Conceivably some folks might prefer to continue delivering
+ mail plaintext when their binary is broken in this way, if there is a
+ server that is a candidate to receive such mails that does not advertise
+ STARTTLS. Note that Exim is typically a setuid root binary and given
+ broken linkage problems that cause segfaults, we feel it is safer to
+ fail completely. (The check is not done as root, to ensure that problems
+ here are not made worse by the check).
+
+ * The "tls_dhparam" option has been updated, so that it can now specify a
+ path or an identifier for a standard DH prime from one of a few RFCs.
+ The default for OpenSSL is no longer to not use DH but instead to use
+ one of these standard primes. The default for GnuTLS is no longer to use
+ a file in the spool directory, but to use that same standard prime.
+ The option is now used by GnuTLS too. If it points to a path, then
+ GnuTLS will use that path, instead of a file in the spool directory;
+ GnuTLS will attempt to create it if it does not exist.
+
+ To preserve the previous behaviour of generating files in the spool
+ directory, set "tls_dhparam = historic". Since prior releases of Exim
+ ignored tls_dhparam when using GnuTLS, this can safely be done before
+ the upgrade.
+
+
+
+Exim version 4.77
+-----------------
+
+ * GnuTLS will now attempt to use TLS 1.2 and TLS 1.1 before TLS 1.0 and SSL3,
+ if supported by your GnuTLS library. Use the existing
+ "gnutls_require_protocols" option to downgrade this if that will be a
+ problem. Prior to this release, supported values were "TLS1" and "SSL3",
+ so you should be able to update configuration prior to update.
+
+ [nb: gnutls_require_protocols removed in Exim 4.80, instead use
+ tls_require_ciphers to provide a priority string; see notes above]
+
+ * The match_<type>{string1}{string2} expansion conditions no longer subject
+ string2 to string expansion, unless Exim was built with the new
+ "EXPAND_LISTMATCH_RHS" option. Too many people have inadvertently created
+ insecure configurations that way. If you need the functionality and turn on
+ that build option, please let the developers know, and know why, so we can
+ try to provide a safer mechanism for you.
+
+ The match{}{} expansion condition (for regular expressions) is NOT affected.
+ For match_<type>{s1}{s2}, all list functionality is unchanged. The only
+ change is that a '$' appearing in s2 will not trigger expansion, but instead
+ will be treated as a literal $ sign; the effect is very similar to having
+ wrapped s2 with \N...\N. If s2 contains a named list and the list definition
+ uses $expansions then those _will_ be processed as normal. It is only the
+ point at which s2 is read where expansion is inhibited.
+
+ If you are trying to test if two email addresses are equal, use eqi{s1}{s2}.
+ If you are testing if the address in s1 occurs in the list of items given
+ in s2, either use the new inlisti{s1}{s2} condition (added in 4.77) or use
+ the pre-existing forany{s2}{eqi{$item}{s1}} condition.
+
+
+Exim version 4.74
+-----------------
+
+ * The integrated support for dynamically loadable lookup modules has an ABI
+ change from the modules supported by some OS vendors through an unofficial
+ patch. Don't try to mix & match.
+
+ * Some parts of the build system are now beginning to assume that the host
+ environment is POSIX. If you're building on a system where POSIX tools are
+ not the default, you might have an easier time if you switch to the POSIX
+ tools. Feel free to report non-POSIX issues as a request for a feature
+ enhancement, but if the POSIX variants are available then the fix will
+ probably just involve some coercion. See the README instructions for
+ building on such hosts.
+
+
+Exim version 4.73
+-----------------
+
+ * The Exim run-time user can no longer be root; this was always
+ strongly discouraged, but is now prohibited both at build and
+ run-time. If you need Exim to run routinely as root, you'll need to
+ patch the source and accept the risk. Here be dragons.
+
+ * Exim will no longer accept a configuration file owned by the Exim
+ run-time user, unless that account is explicitly the value in
+ CONFIGURE_OWNER, which we discourage. Exim now checks to ensure that
+ files are not writeable by other accounts.
+
+ * The ALT_CONFIG_ROOT_ONLY build option is no longer optional and is forced
+ on; the Exim user can, by default, no longer use -C/-D and retain privilege.
+ Two new build options mitigate this.
+
+ * TRUSTED_CONFIG_LIST defines a file containing a whitelist of config
+ files that are trusted to be selected by the Exim user; one per line.
+ This is the recommended approach going forward.
+
+ * WHITELIST_D_MACROS defines a colon-separated list of macro names which
+ the Exim run-time user may safely pass without dropping privileges.
+ Because changes to this involve a recompile, this is not the recommended
+ approach but may ease transition. The values of the macros, when
+ overridden, are constrained to match this regex: ^[A-Za-z0-9_/.-]*$
+
+ * The system_filter_user option now defaults to the Exim run-time user,
+ rather than root. You can still set it explicitly to root and this
+ can be done with prior versions too, letting you roll versions
+ without needing to change this configuration option.
+
+ * ClamAV must be at least version 0.95 unless WITH_OLD_CLAMAV_STREAM is
+ defined at build time.
+
+
+Exim version 4.70
+-----------------
+
+1. Experimental Yahoo! Domainkeys support has been dropped in this release.
+It has been superceded by a native implementation of its successor DKIM.
+
+2. Up to version 4.69, Exim came with an embedded version of the PCRE library.
+As of 4.70, this is no longer the case. To compile Exim, you will need PCRE
+installed. Most OS distributions have ready-made library and development
+packages.
+
+
+Exim version 4.68
+-----------------
+
+1. The internal implementation of the database keys that are used for ACL
+ratelimiting has been tidied up. This means that an update to 4.68 might cause
+Exim to "forget" previous rates that it had calculated, and reset them to zero.
+
+
+Exim version 4.64
+-----------------
+
+1. Callouts were setting the name used for EHLO/HELO from $smtp_active_
+hostname. This is wrong, because it relates to the incoming message (and
+probably the interface on which it is arriving) and not to the outgoing
+callout (which could be using a different interface). This has been
+changed to use the value of the helo_data option from the smtp transport
+instead - this is what is used when a message is actually being sent. If
+there is no remote transport (possible with a router that sets up host
+addresses), $smtp_active_hostname is used. This change is mentioned here in
+case somebody is relying on the use of $smtp_active_hostname.
+
+2. A bug has been fixed that might just possibly be something that is relied on
+in some configurations. In expansion items such as ${if >{xxx}{yyy}...} an
+empty string (that is {}) was being interpreted as if it was {0} and therefore
+treated as the number zero. From release 4.64, such strings cause an error
+because a decimal number, possibly followed by K or M, is required (as has
+always been documented).
+
+3. There has been a change to the GnuTLS support (ChangeLog/PH/20) to improve
+Exim's performance. Unfortunately, this has the side effect of being slightly
+non-upwards compatible for versions 4.50 and earlier. If you are upgrading from
+one of these earlier versions and you use GnuTLS, you must remove the file
+called gnutls-params in Exim's spool directory. If you don't do this, you will
+see this error:
+
+ TLS error on connection from ... (DH params import): Base64 decoding error.
+
+Removing the file causes Exim to recompute the relevant encryption parameters
+and cache them in the new format that was introduced for release 4.51 (May
+2005). If you are upgrading from release 4.51 or later, there should be no
+problem.
+
+
+Exim version 4.63
+-----------------
+
+When an SMTP error message is specified in a "message" modifier in an ACL, or
+in a :fail: or :defer: message in a redirect router, Exim now checks the start
+of the message for an SMTP error code. This consists of three digits followed
+by a space, optionally followed by an extended code of the form n.n.n, also
+followed by a space. If this is the case and the very first digit is the same
+as the default error code, the code from the message is used instead. If the
+very first digit is incorrect, a panic error is logged, and the default code is
+used. This is an incompatible change, but it is not expected to affect many (if
+any) configurations. It is possible to suppress the use of the supplied code in
+a redirect router by setting the smtp_error_code option false. In this case,
+any SMTP code is quietly ignored.
+
+
+Exim version 4.61
+-----------------
+
+1. The default number of ACL variables of each type has been increased to 20,
+and it's possible to compile Exim with more. You can safely upgrade to this
+release if you already have messages on the queue with saved ACL variable
+values. However, if you downgrade from this release with messages on the queue,
+any saved ACL values they may have will be lost.
+
+2. The default value for rfc1413_query_timeout has been changed from 30s to 5s.
+
+
Exim version 4.54
-----------------
git://git.exim.org / exim.git / blobdiff