GnuTLS: fix the advertising of acceptable certs by the server. Bug 2389

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

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 4d4bab7c256c1e3bf79562ced7050b4b76f7e30e..0bce6fe86135e14b33572c7c5f6aa8db1c29447e 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -6745,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
 &<<SECThoslispatsikey>>&).
 &*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
 &<<SECThoslispatsikey>>&).

+
+.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"
 .next
 .cindex "linear search"
 .cindex "lookup" "lsearch"


@@ -8663,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
 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.
 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)&.
 
 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)&.


@@ -9537,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.
 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 +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.
 
 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
 
 


@@ -39431,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
 
 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)


@@ -39452,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
 
 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: