Doc: Provide context for bare numbers from CHAP/SECT.

[exim.git] / doc / doc-docbook / spec.xfpt

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index da97d40823c5b51b91de3c95e87091713da8c921..9eaf9e8046f7775ee8b12b11e171399fba2ee8c7 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -2991,6 +2991,26 @@ The specified sender is treated as if it were given as the argument to the
 preference to the address taken from the message. The caller of Exim must be a
 trusted user for the sender of a message to be set in this way.
 
 preference to the address taken from the message. The caller of Exim must be a
 trusted user for the sender of a message to be set in this way.
 

+.vitem &%-bmalware%&&~<&'filename'&>
+.oindex "&%-bmalware%&"
+.cindex "testing", "malware"
+.cindex "malware scan test"
+This debugging option causes Exim to scan the given file,
+using the malware scanning framework.  The option of &%av_scanner%& influences
+this option, so if &%av_scanner%&'s value is dependent upon an expansion then
+the expansion should have defaults which apply to this invocation.  ACLs are
+not invoked, so if &%av_scanner%& references an ACL variable then that variable
+will never be populated and &%-bmalware%& will fail.
+
+Exim will have changed working directory before resolving the filename, so
+using fully qualified pathnames is advisable.  Exim will be running as the Exim
+user when it tries to open the file, rather than as the invoking user.
+This option requires admin privileges.
+
+The &%-bmalware%& option will not be extended to be more generally useful,
+there are better tools for file-scanning.  This option exists to help
+administrators verify their Exim and AV scanner configuration.
+

 .vitem &%-bnq%&
 .oindex "&%-bnq%&"
 .cindex "address qualification, suppressing"
 .vitem &%-bnq%&
 .oindex "&%-bnq%&"
 .cindex "address qualification, suppressing"


@@ -3251,26 +3271,6 @@ above concerning senders and qualification do not apply. In this situation,
 Exim behaves in exactly the same way as it does when receiving a message via
 the listening daemon.
 
 Exim behaves in exactly the same way as it does when receiving a message via
 the listening daemon.
 

-.vitem &%-bmalware%&&~<&'filename'&>
-.oindex "&%-bmalware%&"
-.cindex "testing", "malware"
-.cindex "malware scan test"
-This debugging option causes Exim to scan the given file,
-using the malware scanning framework.  The option of &%av_scanner%& influences
-this option, so if &%av_scanner%&'s value is dependent upon an expansion then
-the expansion should have defaults which apply to this invocation.  ACLs are
-not invoked, so if &%av_scanner%& references an ACL variable then that variable
-will never be populated and &%-bmalware%& will fail.
-
-Exim will have changed working directory before resolving the filename, so
-using fully qualified pathnames is advisable.  Exim will be running as the Exim
-user when it tries to open the file, rather than as the invoking user.
-This option requires admin privileges.
-
-The &%-bmalware%& option will not be extended to be more generally useful,
-there are better tools for file-scanning.  This option exists to help
-administrators verify their Exim and AV scanner configuration.
-

 .vitem &%-bt%&
 .oindex "&%-bt%&"
 .cindex "testing" "addresses"
 .vitem &%-bt%&
 .oindex "&%-bt%&"
 .cindex "testing" "addresses"


@@ -6026,16 +6026,16 @@ that it implements the details of the specific authentication mechanism,
 i.e. PLAIN or LOGIN. The &%server_advertise_condition%& setting controls
 when Exim offers authentication to clients; in the examples, this is only
 when TLS or SSL has been started, so to enable the authenticators you also
 i.e. PLAIN or LOGIN. The &%server_advertise_condition%& setting controls
 when Exim offers authentication to clients; in the examples, this is only
 when TLS or SSL has been started, so to enable the authenticators you also

-need to add support for TLS as described in &<<SECTdefconfmain>>&.
+need to add support for TLS as described in section &<<SECTdefconfmain>>&.

 
 The &%server_condition%& setting defines how to verify that the username and
 password are correct. In the examples it just produces an error message.
 To make the authenticators work, you can use a string expansion
 
 The &%server_condition%& setting defines how to verify that the username and
 password are correct. In the examples it just produces an error message.
 To make the authenticators work, you can use a string expansion

-expression like one of the examples in &<<CHAPplaintext>>&.
+expression like one of the examples in chapter &<<CHAPplaintext>>&.

 
 Beware that the sequence of the parameters to PLAIN and LOGIN differ; the
 
 Beware that the sequence of the parameters to PLAIN and LOGIN differ; the

-usercode and password are in different positions.  &<<CHAPplaintext>>&
-covers both.
+usercode and password are in different positions.
+Chapter &<<CHAPplaintext>>& covers both.

 
 .ecindex IIDconfiwal
 
 
 .ecindex IIDconfiwal
 


@@ -15710,7 +15710,7 @@ ignored. See section &<<SECTopenvsgnu>>& for further details.
 .new
 If the DH bit-count from loading the file is greater than tls_dh_max_bits then
 it will be ignored.
 .new
 If the DH bit-count from loading the file is greater than tls_dh_max_bits then
 it will be ignored.

-.end
+.wen

 
 
 .option tls_on_connect_ports main "string list" unset
 
 
 .option tls_on_connect_ports main "string list" unset


@@ -17103,6 +17103,40 @@ look for A or AAAA records, unless the domain matches &%mx_domains%&, in which
 case routing fails.
 
 
 case routing fails.
 
 

+.new
+.section "Declining addresses by dnslookup" "SECTdnslookupdecline"
+.cindex "&(dnslookup)& router" "declines"
+There are a few cases where a &(dnslookup)& router will decline to accept
+an address; if such a router is expected to handle "all remaining non-local
+domains", then it is important to set &%no_more%&.
+
+Reasons for a &(dnslookup)& router to decline currently include:
+.ilist
+The domain does not exist in DNS
+.next
+The domain exists but the MX record's host part is just "."; this is a common
+convention (borrowed from SRV) used to indicate that there is no such service
+for this domain and to not fall back to trying A/AAAA records.
+.next
+Ditto, but for SRV records, when &%check_srv%& is set on this router.
+.next
+MX record points to a non-existent host.
+.next
+MX record points to an IP address and the main section option
+&%allow_mx_to_ip%& is not set.
+.next
+MX records exist and point to valid hosts, but all hosts resolve only to
+addresses blocked by the &%ignore_target_hosts%& generic option on this router.
+.next
+The domain is not syntactically valid (see also &%allow_utf8_domains%& and
+&%dns_check_names_pattern%& for handling one variant of this)
+.next
+&%check_secondary_mx%& is set on this router but the local host can
+not be found in the MX records (see below)
+.endlist
+.wen
+
+

 
 
 .section "Private options for dnslookup" "SECID118"
 
 
 .section "Private options for dnslookup" "SECID118"


@@ -24963,10 +24997,11 @@ The &%tls_verify_certificates%& option must contain the name of a file, not the
 name of a directory (for OpenSSL it can be either).
 .next
 The &%tls_dhparam%& option is ignored, because early versions of GnuTLS had no
 name of a directory (for OpenSSL it can be either).
 .next
 The &%tls_dhparam%& option is ignored, because early versions of GnuTLS had no

-facility for varying its Diffie-Hellman parameters. I understand that this has
-changed, but Exim has not been updated to provide this facility.
+facility for varying its Diffie-Hellman parameters.

 .new
 .new

-Instead, the GnuTLS support will use a file from the spool directory.
+Since then, the GnuTLS support has been updated to generate parameters upon
+demand, keeping them in the spool directory.  See &<<SECTgnutlsparam>>& for
+details.

 .wen
 .next
 .vindex "&$tls_peerdn$&"
 .wen
 .next
 .vindex "&$tls_peerdn$&"


@@ -24975,10 +25010,11 @@ separating fields; GnuTLS uses commas, in accordance with RFC 2253. This
 affects the value of the &$tls_peerdn$& variable.
 .next
 OpenSSL identifies cipher suites using hyphens as separators, for example:
 affects the value of the &$tls_peerdn$& variable.
 .next
 OpenSSL identifies cipher suites using hyphens as separators, for example:

-DES-CBC3-SHA. GnuTLS uses underscores, for example: RSA_ARCFOUR_SHA. What is
-more, OpenSSL complains if underscores are present in a cipher list. To make
-life simpler, Exim changes underscores to hyphens for OpenSSL and hyphens to
-underscores for GnuTLS when processing lists of cipher suites in the
+DES-CBC3-SHA. GnuTLS historically used underscores, for example:
+RSA_ARCFOUR_SHA. What is more, OpenSSL complains if underscores are present
+in a cipher list. To make life simpler, Exim changes underscores to hyphens
+for OpenSSL and passes the string unchanged to GnuTLS (expecting the library
+to handle its own older variants) when processing lists of cipher suites in the

 &%tls_require_ciphers%& options (the global option and the &(smtp)& transport
 option).
 .next
 &%tls_require_ciphers%& options (the global option and the &(smtp)& transport
 option).
 .next


@@ -24994,7 +25030,7 @@ implementation, then patches are welcome.
 .endlist
 
 
 .endlist
 
 

-.section "GnuTLS parameter computation" "SECID181"
+.section "GnuTLS parameter computation" "SECTgnutlsparam"

 .new
 GnuTLS uses D-H parameters that may take a substantial amount of time
 to compute. It is unreasonable to re-compute them for every TLS session.
 .new
 GnuTLS uses D-H parameters that may take a substantial amount of time
 to compute. It is unreasonable to re-compute them for every TLS session.


@@ -25028,14 +25064,14 @@ and letting Exim re-create it, you can generate new parameters using
 renaming. The relevant commands are something like this:
 .code
 # ls
 renaming. The relevant commands are something like this:
 .code
 # ls

-[ look for file; assume gnutls-params-1024 is the most recent ]
+[ look for file; assume gnutls-params-2236 is the most recent ]

 # rm -f new-params
 # touch new-params
 # chown exim:exim new-params
 # chmod 0600 new-params
 # rm -f new-params
 # touch new-params
 # chown exim:exim new-params
 # chmod 0600 new-params

-# certtool --generate-dh-params --bits 1024 >>new-params
+# certtool --generate-dh-params --bits 2236 >>new-params

 # chmod 0400 new-params
 # chmod 0400 new-params

-# mv new-params gnutls-params-1024
+# mv new-params gnutls-params-2236

 .endd
 If Exim never has to generate the parameters itself, the possibility of
 stalling is removed.
 .endd
 If Exim never has to generate the parameters itself, the possibility of
 stalling is removed.


@@ -25044,10 +25080,18 @@ The filename changed in Exim 4.80, to gain the -bits suffix.  The value which
 Exim will choose depends upon the version of GnuTLS in use.  For older GnuTLS,
 the value remains hard-coded in Exim as 1024.  As of GnuTLS 2.12.x, there is
 a way for Exim to ask for the "normal" number of bits for D-H public-key usage,
 Exim will choose depends upon the version of GnuTLS in use.  For older GnuTLS,
 the value remains hard-coded in Exim as 1024.  As of GnuTLS 2.12.x, there is
 a way for Exim to ask for the "normal" number of bits for D-H public-key usage,

-and Exim does so.  Exim thus removes itself from the policy decision, and the
-filename and bits used change as the GnuTLS maintainers change the value for
-their parameter &`GNUTLS_SEC_PARAM_NORMAL`&.  At the time of writing, this
-gives 2432 bits.
+and Exim does so.  This attempt to remove Exim from TLS policy decisions
+failed, as GnuTLS 2.12 returns a value higher than the current hard-coded limit
+of the NSS library.  Thus Exim gains the &%tls_dh_max_bits%& global option,
+which applies to all D-H usage, client or server.  If the value returned by
+GnuTLS is greater than &%tls_dh_max_bits%& then the value will be clamped down
+to &%tls_dh_max_bits%&.  The default value has been set at the current NSS
+limit, which is still much higher than Exim historically used.
+
+The filename and bits used will change as the GnuTLS maintainers change the
+value for their parameter &`GNUTLS_SEC_PARAM_NORMAL`&, as clamped by
+&%tls_dh_max_bits%&.  At the time of writing (mid 2012), GnuTLS 2.12 recommends
+2432 bits, while NSS is limited to 2236 bits.

 .wen
 
 
 .wen
 
 


@@ -25058,7 +25102,10 @@ There is a function in the OpenSSL library that can be passed a list of cipher
 suites before the cipher negotiation takes place. This specifies which ciphers
 are acceptable. The list is colon separated and may contain names like
 DES-CBC3-SHA. Exim passes the expanded value of &%tls_require_ciphers%&
 suites before the cipher negotiation takes place. This specifies which ciphers
 are acceptable. The list is colon separated and may contain names like
 DES-CBC3-SHA. Exim passes the expanded value of &%tls_require_ciphers%&

-directly to this function call. The following quotation from the OpenSSL
+directly to this function call.
+Many systems will install the OpenSSL manual-pages, so you may have
+&'ciphers(1)'& available to you.
+The following quotation from the OpenSSL

 documentation specifies what forms of item are allowed in the cipher string:
 
 .ilist
 documentation specifies what forms of item are allowed in the cipher string:
 
 .ilist


@@ -25095,6 +25142,26 @@ includes any ciphers already present they will be ignored: that is, they will
 not be moved to the end of the list.
 .endlist
 
 not be moved to the end of the list.
 .endlist
 

+.new
+The OpenSSL &'ciphers(1)'& command may be used to test the results of a given
+string:
+.code
+# note single-quotes to get ! past any shell history expansion
+$ openssl ciphers 'HIGH:!MD5:!SHA1'
+.endd
+
+This example will let the library defaults be permitted on the MX port, where
+there's probably no identity verification anyway, but ups the ante on the
+submission ports where the administrator might have some influence on the
+choice of clients used:
+.code
+# OpenSSL variant; see man ciphers(1)
+tls_require_ciphers = ${if =={$received_port}{25}\
+                           {DEFAULT}\
+                           {HIGH:!MD5:!SHA1}}
+.endd
+.wen
+

 
 
 .new
 
 
 .new


@@ -25122,11 +25189,27 @@ 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.gnu.org/software/gnutls/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,
+&url(http://www.gnu.org/software/gnutls/manual/html_node/Listing-the-ciphersuites-in-a-priority-string.html, 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
 additional options, "&%gnutls_require_kx%&", "&%gnutls_require_mac%&" and
 "&%gnutls_require_protocols%&".  &%tls_require_ciphers%& was an Exim list.
 
 Prior to Exim 4.80, an older API of GnuTLS was used, and Exim supported three
 additional options, "&%gnutls_require_kx%&", "&%gnutls_require_mac%&" and
 "&%gnutls_require_protocols%&".  &%tls_require_ciphers%& was an Exim list.

+
+This example will let the library defaults be permitted on the MX port, where
+there's probably no identity verification anyway, and lowers security further
+by increasing compatibility; but this ups the ante on the submission ports
+where the administrator might have some influence on the choice of clients
+used:
+.code
+# GnuTLS variant
+tls_require_ciphers = ${if =={$received_port}{25}\
+                           {NORMAL:%COMPAT}\
+                           {SECURE128}}
+.endd

 .wen
 
 
 .wen