Use dsn_from for success-DSN messages. Bug 2404

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

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 112c1efa20beeb8f2674bdfc1da9956a5b7cd9f1..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)&.