X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/b13354a7c428fdb2286d2227fdad5378a1ee9426..ffc3d145e3819e1a3762caa1bbe8b07e723fbaf2:/doc/doc-docbook/spec.xfpt?ds=sidebyside

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 7d4dfbbe7..1f45a6f04 100644
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -9410,7 +9410,9 @@ This forces an expansion failure (see section &<<SECTforexpfai>>&);
 {<&'string2'&>} must be present for &"fail"& to be recognized.
 
 .new
-.vitem "&*${extract json{*&<&'key'&>&*}{*&<&'string1'&>&*}{*&<&'string2'&>&*}&&&
+.vitem "&*${extract json {*&<&'key'&>&*}{*&<&'string1'&>&*}{*&<&'string2'&>&*}&&&
+       {*&<&'string3'&>&*}}*&" &&&
+       "&*${extract jsons{*&<&'key'&>&*}{*&<&'string1'&>&*}{*&<&'string2'&>&*}&&&
        {*&<&'string3'&>&*}}*&"
 .cindex "expansion" "extracting from JSON object"
 .cindex JSON expansions
@@ -9425,8 +9427,11 @@ 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.
-If a returned value is a JSON string, it retains its leading and
+For the &"json"& variant,
+if a returned value is a JSON string, it retains its leading and
 trailing quotes.
+For the &"jsons"& variant, which is intended for use with JSON strings, the
+leading and trailing quotes are removed from the returned value.
 . XXX should be a UTF-8 compare
 
 The results of matching are handled as above.
@@ -9465,7 +9470,9 @@ empty (for example, the fifth field above).
 
 
 .new
-.vitem "&*${extract json{*&<&'number'&>&*}}&&&
+.vitem "&*${extract json {*&<&'number'&>&*}}&&&
+        {*&<&'string1'&>&*}{*&<&'string2'&>&*}{*&<&'string3'&>&*}}*&" &&&
+       "&*${extract jsons{*&<&'number'&>&*}}&&&
         {*&<&'string1'&>&*}{*&<&'string2'&>&*}{*&<&'string3'&>&*}}*&"
 .cindex "expansion" "extracting from JSON array"
 .cindex JSON expansions
@@ -9474,8 +9481,11 @@ 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.
-If a returned value is a JSON string, it retains its leading and
+For the &"json"& variant,
+if a returned value is a JSON string, it retains its leading and
 trailing quotes.
+For the &"jsons"& variant, which is intended for use with JSON strings, the
+leading and trailing quotes are removed from the returned value.
 .wen
 
 
@@ -11204,6 +11214,25 @@ being processed, to enable these expansion items to be nested.
 
 To scan a named list, expand it with the &*listnamed*& operator.
 
+.new
+.vitem "&*forall_json{*&<&'a JSON array'&>&*}{*&<&'a condition'&>&*}*&" &&&
+       "&*forany_json{*&<&'a JSON array'&>&*}{*&<&'a condition'&>&*}*&" &&&
+       "&*forall_jsons{*&<&'a JSON array'&>&*}{*&<&'a condition'&>&*}*&" &&&
+       "&*forany_jsons{*&<&'a JSON array'&>&*}{*&<&'a condition'&>&*}*&"
+.cindex JSON "iterative conditions"
+.cindex JSON expansions
+.cindex expansion "&*forall_json*& condition"
+.cindex expansion "&*forany_json*& condition"
+.cindex expansion "&*forall_jsons*& condition"
+.cindex expansion "&*forany_jsons*& condition"
+As for the above, except that the first argument must, after expansion,
+be a JSON array.
+The array separator is not changeable.
+For the &"jsons"& variants the elements are expected to be JSON strings
+and have their quotes removed before the evaluation of the condition.
+.wen
+
+
 
 .vitem &*ge&~{*&<&'string1'&>&*}{*&<&'string2'&>&*}*& &&&
        &*gei&~{*&<&'string1'&>&*}{*&<&'string2'&>&*}*&
@@ -13191,6 +13220,12 @@ The deprecated &$tls_cipher$& variable is the same as &$tls_in_cipher$& during m
 but in the context of an outward SMTP delivery taking place via the &(smtp)& transport
 becomes the same as &$tls_out_cipher$&.
 
+.new
+.vitem &$tls_in_cipher_std$&
+.vindex "&$tls_in_cipher_std$&"
+As above, but returning the RFC standard name for the cipher suite.
+.wen
+
 .vitem &$tls_out_cipher$&
 .vindex "&$tls_out_cipher$&"
 This variable is
@@ -13199,6 +13234,12 @@ and then set to the outgoing cipher suite if one is negotiated. See chapter
 &<<CHAPTLS>>& for details of TLS support and chapter &<<CHAPsmtptrans>>& for
 details of the &(smtp)& transport.
 
+,new
+.vitem &$tls_out_cipher_std$&
+.vindex "&$tls_out_cipher_std$&"
+As above, but returning the RFC standard name for the cipher suite.
+.wen
+
 .vitem &$tls_out_dane$&
 .vindex &$tls_out_dane$&
 DANE active status.  See section &<<SECDANE>>&.
@@ -16430,23 +16471,26 @@ on at the end (preceded by a semicolon). The string is expanded each time it is
 used. If the expansion yields an empty string, no &'Received:'& header line is
 added to the message. Otherwise, the string should start with the text
 &"Received:"& and conform to the RFC 2822 specification for &'Received:'&
-header lines. The default setting is:
+header lines.
+.new
+The default setting is:
 
 .code
 received_header_text = Received: \
   ${if def:sender_rcvhost {from $sender_rcvhost\n\t}\
-  {${if def:sender_ident \
-  {from ${quote_local_part:$sender_ident} }}\
-  ${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}\
+    {${if def:sender_ident \
+      {from ${quote_local_part:$sender_ident} }}\
+        ${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}\
   by $primary_hostname \
-  ${if def:received_protocol {with $received_protocol}} \
-  ${if def:tls_in_cipher {($tls_in_cipher)\n\t}}\
+  ${if def:received_protocol {with $received_protocol }}\
+  ${if def:tls_in_cipher_std { tls $tls_in_cipher_std\n\t}}\
   (Exim $version_number)\n\t\
   ${if def:sender_address \
   {(envelope-from <$sender_address>)\n\t}}\
   id $message_exim_id\
   ${if def:received_for {\n\tfor $received_for}}
 .endd
+.wen
 
 The reference to the TLS cipher is omitted when Exim is built without TLS
 support. The use of conditional expansions ensures that this works for both
@@ -27321,7 +27365,7 @@ but is a full SMTP SASL authenticator
 rather than being implicit for TLS-connection carried
 client certificates only.
 
-The examples and discussion in this chapter assume that 
+The examples and discussion in this chapter assume that
 client-certificate authentication is being done.
 
 The client must present a certificate,
@@ -28202,6 +28246,15 @@ checks are made: that the host name (the one in the DNS A record)
 is valid for the certificate.
 The option defaults to always checking.
 
+.new
+Do not use a client certificate that contains an "OCSP Must-Staple" extension.
+TLS 1.2 and below does not support client-side OCSP stapling, and
+(as of writing) the TLS libraries do not provide for it even with
+TLS 1.3.
+Be careful when using the same certificate for server- and
+client-certificate for this reason.
+.wen
+
 The &(smtp)& transport has two OCSP-related options:
 &%hosts_require_ocsp%&; a host-list for which a Certificate Status
 is requested and required for the connection to proceed.  The default