Fix info on using local_scan() in the default Makefile
[exim.git] / doc / doc-docbook / spec.xfpt
index c53a392a4fb4e6eadc0fe078d18c665598944d6a..112c1efa20beeb8f2674bdfc1da9956a5b7cd9f1 100644 (file)
@@ -9537,6 +9537,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.
 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.
 . XXX should be a UTF-8 compare
 
 The results of matching are handled as above.
@@ -9584,6 +9586,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.
 
 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
 
 
 .wen
 
 
@@ -23581,7 +23585,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
 .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
 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
@@ -39430,8 +39435,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
 
 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)
 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)
@@ -39451,10 +39457,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
 
 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:
 
 .option dkim_hash smtp string&!! sha256
 Can be set to any one of the supported hash methods, which are: