TLS: Session resumption, under the EXPERIMENTAL_TLS_RESUME build option.
[exim.git] / doc / doc-docbook / spec.xfpt
index 415c727127913e4b3e6846794535534397a266ce..783aeb429d70406a5c2d394fd83d396b9573558e 100644 (file)
@@ -2766,6 +2766,8 @@ used to specify a path on the command line if a pid file is required.
 The SIGHUP signal
 .cindex "SIGHUP"
 .cindex "daemon" "restarting"
+.cindex signal "to reload configuration"
+.cindex daemon "reload configuration"
 can be used to cause the daemon to re-execute itself. This should be done
 whenever Exim's configuration file, or any file that is incorporated into it by
 means of the &%.include%& facility, is changed, and also whenever a new version
@@ -6741,6 +6743,12 @@ 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, in dotted-quad form. (Exim converts IPv4-mapped IPv6 addresses to this
+notation before executing the lookup.)
+.wen
 .next
 .new
 .cindex lookup json
@@ -8678,8 +8686,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)&.
@@ -16157,7 +16169,7 @@ harm. This option overrides the &%pipe_as_creator%& option of the &(pipe)&
 transport driver.
 
 
-.option openssl_options main "string list" "+no_sslv2 +single_dh_use +no_ticket"
+.option openssl_options main "string list" "+no_sslv2 +no_sslv3 +single_dh_use +no_ticket"
 .cindex "OpenSSL "compatibility options"
 This option allows an administrator to adjust the SSL options applied
 by OpenSSL to connections.  It is given as a space-separated list of items,
@@ -28307,7 +28319,7 @@ There is no current way to staple a proof for a client certificate.
 
 
 
-.section "Configuring an Exim client to use TLS" "SECID185"
+.section "Configuring an Exim client to use TLS" "SECTclientTLS"
 .cindex "cipher" "logging"
 .cindex "log" "TLS cipher"
 .cindex "log" "distinguished name"
@@ -30832,7 +30844,7 @@ For SMTP input that does not come over TCP/IP (the &%-bs%& command line
 option), this condition is always true.
 
 
-.vitem &*verify&~=&~not_blind*&
+.vitem &*verify&~=&~not_blind/*&<&'options'&>
 .cindex "verifying" "not blind"
 .cindex "bcc recipients, verifying none"
 This condition checks that there are no blind (bcc) recipients in the message.
@@ -30842,6 +30854,11 @@ case-sensitively; domains are checked case-insensitively. If &'Resent-To:'& or
 &'Resent-Cc:'& header lines exist, they are also checked. This condition can be
 used only in a DATA or non-SMTP ACL.
 
+.new
+There is one possible option, &`case_insensitive`&.  If this is present then
+local parts are checked case-insensitively.
+.wen
+
 There are, of course, many legitimate messages that make use of blind (bcc)
 recipients. This check should not be used on its own for blocking messages.
 
@@ -37001,7 +37018,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 +37125,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 +37310,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 +39641,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 +39663,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: