X-Git-Url: https://git.exim.org/exim.git/blobdiff_plain/9973c745f74341d8ffddabac4b05ade9be2f4310..bf9375eaa85bfa0dbb973aa03accbe5f21808732:/doc/doc-docbook/spec.xfpt?ds=sidebyside diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt index dc924678d..0bce6fe86 100644 --- a/doc/doc-docbook/spec.xfpt +++ b/doc/doc-docbook/spec.xfpt @@ -6257,6 +6257,9 @@ remote_smtp: dnssec_request_domains = * hosts_try_dane = * .endif +.ifdef _HAVE_PRDR + hosts_try_prdr = * +.endif .endd This transport is used for delivering messages over SMTP connections. The list of remote hosts comes from the router. @@ -6265,6 +6268,11 @@ with over-long lines. The built-in macro _HAVE_DANE guards configuration to try to use DNSSEC for all queries and to use DANE for delivery; see section &<>& for more details. +The &%hosts_try_prdr%& option enables an efficiency SMTP option. It is +negotiated between client and server and not expected to cause problems +but can be disabled if needed. The built-in macro _HAVE_PRDR guards the +use of the &%hosts_try_prdr%& configuration option. + The other remote transport is used when delivering to a specific smarthost with whom there must be some kind of existing relationship, instead of the usual federated system. @@ -6299,6 +6307,9 @@ smarthost_smtp: tls_require_ciphers = SECURE192:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1 .endif .endif +.ifdef _HAVE_PRDR + hosts_try_prdr = * +.endif .endd After the same &%message_size_limit%& hack, we then specify that this Transport can handle messages to multiple domains in one run. The assumption here is @@ -6318,6 +6329,9 @@ ROUTER_SMARTHOST macro, because that is unaffected by CNAMEs present in DNS. You want to specify the hostname which you'll expect to validate for, and that should not be subject to insecure tampering via DNS results. +For the &%hosts_try_prdr%& option see the previous transport. + +All other options are defaulted. .code local_delivery: driver = appendfile @@ -6731,6 +6745,11 @@ lookup types support only literal keys. &*Warning 2*&: In a host list, you must always use &(net-iplsearch)& so that the implicit key is the host's IP address rather than its name (see section &<>&). + +.new +&*Warning 3*&: Do not use an IPv4-mapped IPv6 address for a key; use the +IPv4. Such addresses being searched for are converted to IPv4. +.wen .next .cindex "linear search" .cindex "lookup" "lsearch" @@ -8649,8 +8668,12 @@ to quote keys was made available in &(lsearch)& files. However, the more recently implemented &(iplsearch)& files do require colons in IPv6 keys (notated using the quoting facility) so as to distinguish them from IPv4 keys. For this reason, when the lookup type is &(iplsearch)&, IPv6 addresses are -converted using colons and not dots. In all cases, full, unabbreviated IPv6 +converted using colons and not dots. +.new +In all cases except IPv4-mapped IPv6, full, unabbreviated IPv6 addresses are always used. +The latter are converted to IPv4 addresses, in dotted-quad form. +.wen Ideally, it would be nice to tidy up this anomalous situation by changing to colons in all cases, given that quoting is now available for &(lsearch)&. @@ -9523,6 +9546,8 @@ The expanded <&'string1'&> must be of the form: The braces, commas and colons, and the quoting of the member name are required; the spaces are optional. Matching of the key against the member names is done case-sensitively. +If a returned value is a JSON string, it retains its leading and +trailing quotes. . XXX should be a UTF-8 compare The results of matching are handled as above. @@ -9570,6 +9595,8 @@ apart from leading and trailing white space, which is ignored. Field selection and result handling is as above; there is no choice of field separator. +If a returned value is a JSON string, it retains its leading and +trailing quotes. .wen @@ -23567,7 +23594,8 @@ command = /bin/sh -c ${lookup{$local_part}lsearch{/some/file}} .cindex "filter" "transport filter" .vindex "&$pipe_addresses$&" Special handling takes place when an argument consists of precisely the text -&`$pipe_addresses`&. This is not a general expansion variable; the only +&`$pipe_addresses`& (no quotes). +This is not a general expansion variable; the only place this string is recognized is when it appears as an argument for a pipe or transport filter command. It causes each address that is being handled to be inserted in the argument list at that point &'as a separate argument'&. This @@ -32642,7 +32670,7 @@ intend to use an instance running on the local host you do not need to set you must set the &%spamd_address%& option in the global part of the Exim configuration as follows (example): .code -spamd_address = 192.168.99.45 387 +spamd_address = 192.168.99.45 783 .endd The SpamAssassin protocol relies on a TCP half-close from the client. If your SpamAssassin client side is running a Linux system with an @@ -39416,8 +39444,9 @@ Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits. .endd -Support for EC keys is being developed under -&url(https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/). +.new +EC keys for DKIM are defined by RFC 8463. +.wen They are considerably smaller than RSA keys for equivalent protection. As they are a recent development, users should consider dual-signing (by setting a list of selectors, and an expansion for this option) @@ -39437,10 +39466,12 @@ openssl pkey -outform DER -pubout -in dkim_ed25519.private | tail -c +13 | base6 certtool --load_privkey=dkim_ed25519.private --pubkey_info --outder | tail -c +13 | base64 .endd -Note that the format -of Ed25519 keys in DNS has not yet been decided; this release supports -both of the leading candidates at this time, a future release will -probably drop support for whichever proposal loses. +.new +Exim also supports an alternate format +of Ed25519 keys in DNS which was a candidate during development +of the standard, but not adopted. +A future release will probably drop that support. +.wen .option dkim_hash smtp string&!! sha256 Can be set to any one of the supported hash methods, which are: