+ * 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.
+
+ 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).
+
git://git.exim.org / exim.git / blobdiff