-$Cambridge: exim/src/README.UPDATING,v 1.17 2009/10/16 07:35:42 tom 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.80
+-----------------
+
+ * BEWARE backwards-incompatible changes in SSL libraries, thus the version
+ bump. See points below for details.
+
+ * 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.
+
+ * 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 unset. 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.
+
+ * 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.
+
+ * 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.
+
+
+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
-----------------
* 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 writable by other accounts.
+ 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.
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 develoment
+installed. Most OS distributions have ready-made library and development
packages.
git://git.exim.org / exim.git / blobdiff