X-Git-Url: https://git.exim.org/users/jgh/exim.git/blobdiff_plain/f53d7cf7c6d5af5dd7c5c040e641b665e3d8f7e7..a799883d8ad340d935db4d729a31c02cb8a1d977:/doc/doc-docbook/spec.xfpt?ds=sidebyside diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt index 1c2fa8401..beb0522be 100644 --- 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. +.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" @@ -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. -.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" @@ -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 -need to add support for TLS as described in &<>&. +need to add support for TLS as described in section &<>&. 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 &<>&. +expression like one of the examples in chapter &<>&. Beware that the sequence of the parameters to PLAIN and LOGIN differ; the -usercode and password are in different positions. &<>& -covers both. +usercode and password are in different positions. +Chapter &<>& covers both. .ecindex IIDconfiwal @@ -15697,19 +15697,52 @@ by Thunderbird, while GnuTLS was suggesting 2432 bits as normal. If you prefer more security and are willing to break some clients, raise this number. + +Note that the value passed to GnuTLS for *generating* a new prime may be a +little less than this figure, because GnuTLS is inexact and may produce a +larger prime than requested. .wen .option tls_dhparam main string&!! unset .cindex "TLS" "D-H parameters for server" -The value of this option is expanded, and must then be the absolute path to -a file which contains the server's DH parameter values. -This is used only for OpenSSL. When Exim is linked with GnuTLS, this option is -ignored. See section &<>& 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. +The value of this option is expanded and indicates the source of DH parameters +to be used by Exim. + +If it is a filename starting with a &`/`&, then it names a file from which DH +parameters should be loaded. If the file exists, it should hold a PEM-encoded +PKCS#3 representation of the DH prime. If the file does not exist, for +OpenSSL it is an error. For GnuTLS, Exim will attempt to create the file and +fill it with a generated DH prime. For OpenSSL, if the DH bit-count from +loading the file is greater than &%tls_dh_max_bits$& then it will be ignored, +and treated as though the &%tls_dhparam%& were set to "none". + +If this option expands to the string "none", then no DH parameters will be +loaded by Exim. + +If this option expands to the string "historic" and Exim is using GnuTLS, then +Exim will attempt to load a file from inside the spool directory. If the file +does not exist, Exim will attempt to create it. +See section &<>& for further details. + +If Exim is using OpenSSL and this option is empty or unset, then Exim will load +a default DH prime; the default is the 2048 bit prime described in section +2.2 of RFC 5114, "2048-bit MODP Group with 224-bit Prime Order Subgroup", which +in IKE is assigned number 23. + +Otherwise, the option must expand to the name used by Exim for any of a number +of DH primes specified in RFC 2409, RFC 3526 and RFC 5114. As names, Exim uses +"ike" followed by the number used by IKE, of "default" which corresponds to +"ike23". + +The available primes are: +&`ike1`&, &`ike2`&, &`ike5`&, +&`ike14`&, &`ike15`&, &`ike16`&, &`ike17`&, &`ike18`&, +&`ike22`&, &`ike23`& (aka &`default`&) and &`ike24`&. + +Some of these will be too small to be accepted by clients. +Some may be too large to be accepted by clients. .wen @@ -17103,6 +17136,40 @@ look for A or AAAA records, unless the domain matches &%mx_domains%&, in which 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" @@ -24962,12 +25029,8 @@ There are some differences in usage when using GnuTLS instead of OpenSSL: 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 -facility for varying its Diffie-Hellman parameters. .new -Since then, the GnuTLS support has been updated to generate parameters upon -demand, keeping them in the spool directory. See &<>& for -details. +The default value for &%tls_dhparam%& differs for historical reasons. .wen .next .vindex "&$tls_peerdn$&" @@ -25036,6 +25099,10 @@ renaming. The relevant commands are something like this: # chown exim:exim new-params # chmod 0600 new-params # certtool --generate-dh-params --bits 2236 >>new-params +# openssl dhparam -noout -text -in new-params | head +[ check the first line, make sure it's not more than 2236; + if it is, then go back to the start ("rm") and repeat + until the size generated is at most the size requested ] # chmod 0400 new-params # mv new-params gnutls-params-2236 .endd @@ -25058,6 +25125,12 @@ 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. + +In fact, the requested value will be *lower* than &%tls_dh_max_bits%&, to +increase the chance of the generated prime actually being within acceptable +bounds, as GnuTLS has been observed to overshoot. Note the check step in the +procedure above. There is no sane procedure available to Exim to double-check +the size of the generated prime, so it might still be too large. .wen @@ -25068,7 +25141,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%& -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 @@ -25105,6 +25181,26 @@ includes any ciphers already present they will be ignored: that is, they will 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 @@ -25132,11 +25228,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 -&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. + +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 @@ -25197,13 +25309,24 @@ this). There is one other option that may be needed in other situations. If tls_dhparam = /some/file/name .endd is set, the SSL library is initialized for the use of Diffie-Hellman ciphers -with the parameters contained in the file. This increases the set of cipher -suites that the server supports. See the command +with the parameters contained in the file. +.new +Set this to &`none`& to disable use of DH entirely, by making no prime +available: +.code +tls_dhparam = none +.endd +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. + +See the command .code openssl dhparam .endd -for a way of generating this data. At present, &%tls_dhparam%& is used only -when Exim is linked with OpenSSL. It is ignored if GnuTLS is being used. +for a way of generating file data. +.wen The strings supplied for these three options are expanded every time a client host connects. It is therefore possible to use different certificates and keys