Document DCC in experimental-spec.txt

[users/heiko/exim.git] / src / README.UPDATING

diff --git a/src/README.UPDATING b/src/README.UPDATING
index 5b6bea869ae5ab3a26b634ef742d6d2144873451..62d1d2745010e9dc5f385480e1ce7643b1752bbc 100644 (file)
--- a/src/README.UPDATING
+++ b/src/README.UPDATING
@@ -26,9 +26,12 @@ The rest of this document contains information about changes in 4.xx releases
 that might affect a running system.
 
 
 that might affect a running system.
 
 

-Exim version 4.78
+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.
  * 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.


@@ -69,6 +72,43 @@ Exim version 4.78
    attribute as a comma-separated list.  Note the distinction from multiple
    attributes being returned, where each one is a name=value pair.
 
    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 2.12.x APIs.  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:
+
+     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
 -----------------
 
 Exim version 4.77
 -----------------


@@ -79,6 +119,9 @@ Exim version 4.77
    problem.  Prior to this release, supported values were "TLS1" and "SSL3",
    so you should be able to update configuration prior to update.
 
    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
  * 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