X-Git-Url: https://git.exim.org/exim.git/blobdiff_plain/0215ec074083aaa051d45e7fe3a177783ef93df1..9d0311ffda3349b05b57802e2031c6dc94bc20ae:/src/README.UPDATING?ds=sidebyside

diff --git a/src/README.UPDATING b/src/README.UPDATING
index 62d1d2745..a15bd418e 100644
--- a/src/README.UPDATING
+++ b/src/README.UPDATING
@@ -31,6 +31,7 @@ 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
@@ -66,12 +67,23 @@ Exim version 4.80
    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
@@ -80,16 +92,18 @@ Exim version 4.80
    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 2.12.x APIs.  As part
-   of this, these three options are no longer supported:
+ * 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, which is
-   no longer parsed apart by Exim but is instead given to
-   gnutls_priority_init(3), which is no longer an Exim list.  See:
+   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
 
@@ -109,6 +123,25 @@ Exim version 4.80
    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).
+
 
 Exim version 4.77
 -----------------