Document (and enforce) that DKIM-signing is not supported in cobination with cutthrou...
[exim.git] / doc / doc-docbook / spec.xfpt
index f29c38722ccb6e90a9461553b28b6e04e11c6ce2..1ba0a10ddab110b0e9cf1c411a9b26d3266800db 100644 (file)
@@ -27292,7 +27292,12 @@ It is usable in the RCPT ACL and valid only for single-recipient mails forwarded
 from one SMTP connection to another.  If a recipient-verify callout connection is
 requested in the same ACL it is held open and used for the data, otherwise one is made
 after the ACL completes.
-Note that routers are used in verify mode.
+
+Note that routers are used in verify mode.  Note also that headers cannot be
+modified by any of the post-data ACLs (DATA, MIME and DKIM).
+Cutthrough delivery is not supported via transport-filters or when DKIM signing
+of outgoing messages is done, because it sends data to the ultimate destination
+before the entire message has been received from the source.
 
 Should the ultimate destination system positively accept or reject the mail,
 a corresponding indication is given to the source system and nothing is queued.
@@ -27546,12 +27551,15 @@ warn dnslists = sbl.spamhaus.org : \
      add_header = X-blacklisted-at: $dnslist_domain
 .endd
 The &%add_header%& modifier is permitted in the MAIL, RCPT, PREDATA, DATA,
-MIME, and non-SMTP ACLs (in other words, those that are concerned with
+MIME, DKIM, and non-SMTP ACLs (in other words, those that are concerned with
 receiving a message). The message must ultimately be accepted for
 &%add_header%& to have any significant effect. You can use &%add_header%& with
 any ACL verb, including &%deny%& (though this is potentially useful only in a
 RCPT ACL).
 
+Headers will not be added to the message if the modifier is used in
+DATA, MIME or DKIM ACLs for messages delivered by cutthrough routing.
+
 Leading and trailing newlines are removed from
 the data for the &%add_header%& modifier; if it then
 contains one or more newlines that
@@ -27645,12 +27653,15 @@ warn   message        = Remove internal headers
        remove_header  = x-route-mail1 : x-route-mail2
 .endd
 The &%remove_header%& modifier is permitted in the MAIL, RCPT, PREDATA, DATA,
-MIME, and non-SMTP ACLs (in other words, those that are concerned with
+MIME, DKIM, and non-SMTP ACLs (in other words, those that are concerned with
 receiving a message). The message must ultimately be accepted for
 &%remove_header%& to have any significant effect. You can use &%remove_header%&
 with any ACL verb, including &%deny%&, though this is really not useful for
 any verb that doesn't result in a delivered message.
 
+Headers will not be removed to the message if the modifier is used in
+DATA, MIME or DKIM ACLs for messages delivered by cutthrough routing.
+
 More than one header can be removed at the same time by using a colon separated
 list of header names. The header matching is case insensitive. Wildcards are
 not permitted, nor is list expansion performed, so you cannot use hostlists to
@@ -36338,7 +36349,9 @@ disabled by setting DISABLE_DKIM=yes in Local/Makefile.
 Exim's DKIM implementation allows to
 .olist
 Sign outgoing messages: This function is implemented in the SMTP transport.
-It can co-exist with all other Exim features, including transport filters.
+It can co-exist with all other Exim features
+(including transport filters)
+except cutthrough delivery.
 .next
 Verify signatures in incoming messages: This is implemented by an additional
 ACL (acl_smtp_dkim), which can be called several times per message, with
@@ -36429,6 +36442,10 @@ used.
 Verification of DKIM signatures in incoming email is implemented via the
 &%acl_smtp_dkim%& ACL. By default, this ACL is called once for each
 syntactically(!) correct signature in the incoming message.
+A missing ACL definition defaults to accept.
+If any ACL call does not acccept, the message is not accepted.
+If a cutthrough delivery was in progress for the message it is
+summarily dropped (having wasted the transmission effort).
 
 To evaluate the signature in the ACL a large number of expansion variables
 containing the signature status and its details are set up during the