Docs: Add note on lsearch for IPv4-mapped IPv6 addresses

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

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 415c727127913e4b3e6846794535534397a266ce..c21bc0dcc2d308e27ab986f9fe3b494feed12f46 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -6741,6 +6741,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>>&).
+
+.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
 .new
 .cindex lookup json
@@ -8678,8 +8683,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)&.
@@ -37001,7 +37010,7 @@ the following table:
 &`F   `&        sender address (on delivery lines)
 &`H   `&        host name and IP address
 &`I   `&        local interface used
-&`id  `&        message id for incoming message
+&`id  `&        message id (from header) for incoming message
 &`K   `&        CHUNKING extension used
 &`L   `&        on &`<=`& and &`=>`& lines: PIPELINING extension used
 &`M8S `&        8BITMIME status for incoming message
@@ -37108,6 +37117,8 @@ selection marked by asterisks:
 &` incoming_port              `&  remote port on <= lines
 &`*lost_incoming_connection   `&  as it says (includes timeouts)
 &` millisec                   `&  millisecond timestamps and RT,QT,DT,D times
+&`*msg_id                     `&  on <= lines, Message-ID: header value
+&` msg_id_created             `&  on <= lines, Message-ID: header value when one had to be added
 &` outgoing_interface         `&  local interface on => lines
 &` outgoing_port              `&  add remote port to => lines
 &`*queue_run                  `&  start and end queue runs
@@ -37291,6 +37302,16 @@ connection is unexpectedly dropped.
 &%millisec%&: Timestamps have a period and three decimal places of finer granularity
 appended to the seconds value.
 .next
+.new
+.cindex "log" "message id"
+&%msg_id%&: The value of the Message-ID: header.
+.next
+&%msg_id_created%&: The value of the Message-ID: header, when one had to be created.
+This will be either because the message is a bounce, or was submitted locally
+(submission mode) without one.
+The field identifier will have an asterix appended: &"id*="&.
+.wen
+.next
 .cindex "log" "outgoing interface"
 .cindex "log" "local interface"
 .cindex "log" "local address and port"
@@ -39612,8 +39633,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)
@@ -39633,10 +39655,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: