"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.
Exim version 4.77
git://git.exim.org / users / jgh / exim.git / blobdiff