Fix numeric comparisons for 64b. Bug 1385
[users/jgh/exim.git] / doc / doc-docbook / spec.xfpt
index 56ce0693b2a9dd8ed52926214112958adc8a853c..ac95f26808b3e336d6b8e7e7efc3d02ba585d31d 100644 (file)
@@ -13986,7 +13986,7 @@ This option will let GnuTLS (2.12.0 or later) autoload PKCS11 modules with
 the p11-kit configuration files in &_/etc/pkcs11/modules/_&.
 
 See
 the p11-kit configuration files in &_/etc/pkcs11/modules/_&.
 
 See
-&url(http://www.gnu.org/software/gnutls/manual/gnutls.html#Smart-cards-and-HSMs)
+&url(http://www.gnutls.org/manual/gnutls.html#Smart-cards-and-HSMs)
 for documentation.
 .wen
 
 for documentation.
 .wen
 
@@ -14742,6 +14742,8 @@ Possible options may include:
 .next
 &`no_tlsv1_2`&
 .next
 .next
 &`no_tlsv1_2`&
 .next
+&`safari_ecdhe_ecdsa_bug`&
+.next
 &`single_dh_use`&
 .next
 &`single_ecdh_use`&
 &`single_dh_use`&
 .next
 &`single_ecdh_use`&
@@ -14757,6 +14759,15 @@ Possible options may include:
 &`tls_rollback_bug`&
 .endlist
 
 &`tls_rollback_bug`&
 .endlist
 
+.new
+As an aside, the &`safari_ecdhe_ecdsa_bug`& item is a misnomer and affects
+all clients connecting using the MacOS SecureTransport TLS facility prior
+to MacOS 10.8.4, including email clients.  If you see old MacOS clients failing
+to negotiate TLS then this option value might help, provided that your OpenSSL
+release is new enough to contain this work-around.  This may be a situation
+where you have to upgrade OpenSSL to get buggy clients working.
+.wen
+
 
 .option oracle_servers main "string list" unset
 .cindex "Oracle" "server list"
 
 .option oracle_servers main "string list" unset
 .cindex "Oracle" "server list"
@@ -16020,6 +16031,21 @@ The available primes are:
 Some of these will be too small to be accepted by clients.
 Some may be too large to be accepted by clients.
 
 Some of these will be too small to be accepted by clients.
 Some may be too large to be accepted by clients.
 
+The TLS protocol does not negotiate an acceptable size for this; clients tend
+to hard-drop connections if what is offered by the server is unacceptable,
+whether too large or too small, and there's no provision for the client to
+tell the server what these constraints are.  Thus, as a server operator, you
+need to make an educated guess as to what is most likely to work for your
+userbase.
+
+Some known size constraints suggest that a bit-size in the range 2048 to 2236
+is most likely to maximise interoperability.  The upper bound comes from
+applications using the Mozilla Network Security Services (NSS) library, which
+used to set its &`DH_MAX_P_BITS`& upper-bound to 2236.  This affects many
+mail user agents (MUAs). The lower bound comes from Debian installs of Exim4
+prior to the 4.80 release, as Debian used to patch Exim to raise the minimum
+acceptable bound from 1024 to 2048.
+
 
 .option tls_on_connect_ports main "string list" unset
 This option specifies a list of incoming SSMTP (aka SMTPS) ports that should
 
 .option tls_on_connect_ports main "string list" unset
 This option specifies a list of incoming SSMTP (aka SMTPS) ports that should
@@ -25586,10 +25612,10 @@ aware of future feature enhancements of GnuTLS.
 
 Documentation of the strings accepted may be found in the GnuTLS manual, under
 "Priority strings".  This is online as
 
 Documentation of the strings accepted may be found in the GnuTLS manual, under
 "Priority strings".  This is online as
-&url(http://www.gnu.org/software/gnutls/manual/html_node/Priority-Strings.html),
+&url(http://www.gnutls.org/manual/html_node/Priority-Strings.html),
 but beware that this relates to GnuTLS 3, which may be newer than the version
 installed on your system.  If you are using GnuTLS 3,
 but beware that this relates to GnuTLS 3, which may be newer than the version
 installed on your system.  If you are using GnuTLS 3,
-&url(http://www.gnu.org/software/gnutls/manual/html_node/Listing-the-ciphersuites-in-a-priority-string.html, then the example code)
+&url(http://www.gnutls.org/manual/gnutls.html#Listing-the-ciphersuites-in-a-priority-string, then the example code)
 on that site can be used to test a given string.
 
 Prior to Exim 4.80, an older API of GnuTLS was used, and Exim supported three
 on that site can be used to test a given string.
 
 Prior to Exim 4.80, an older API of GnuTLS was used, and Exim supported three
@@ -25675,7 +25701,7 @@ tls_dhparam = none
 This may also be set to a string identifying a standard prime to be used for
 DH; if it is set to &`default`& or, for OpenSSL, is unset, then the prime
 used is &`ike23`&.  There are a few standard primes available, see the
 This may also be set to a string identifying a standard prime to be used for
 DH; if it is set to &`default`& or, for OpenSSL, is unset, then the prime
 used is &`ike23`&.  There are a few standard primes available, see the
-documetnation for &%tls_dhparam%& for the complete list.
+documentation for &%tls_dhparam%& for the complete list.
 
 See the command
 .code
 
 See the command
 .code
@@ -34424,14 +34450,14 @@ options are available:
 
 .vlist
 .vitem &*-f*&&~<&'regex'&>
 
 .vlist
 .vitem &*-f*&&~<&'regex'&>
-Match the sender address. The field that is tested is enclosed in angle
-brackets, so you can test for bounce messages with
+Match the sender address using a case-insensitive search. The field that is
+tested is enclosed in angle brackets, so you can test for bounce messages with
 .code
 exiqgrep -f '^<>$'
 .endd
 .vitem &*-r*&&~<&'regex'&>
 .code
 exiqgrep -f '^<>$'
 .endd
 .vitem &*-r*&&~<&'regex'&>
-Match a recipient address. The field that is tested is not enclosed in angle
-brackets.
+Match a recipient address using a case-insensitve search. The field that is
+tested is not enclosed in angle brackets.
 
 .vitem &*-s*&&~<&'regex'&>
 Match against the size field.
 
 .vitem &*-s*&&~<&'regex'&>
 Match against the size field.