summaryrefslogtreecommitdiffstats
path: root/doc/experimental-spec.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/experimental-spec.txt')
-rw-r--r--doc/experimental-spec.txt866
1 files changed, 866 insertions, 0 deletions
diff --git a/doc/experimental-spec.txt b/doc/experimental-spec.txt
new file mode 100644
index 0000000..3beab4b
--- /dev/null
+++ b/doc/experimental-spec.txt
@@ -0,0 +1,866 @@
+From time to time, experimental features may be added to Exim.
+While a feature is experimental, there will be a build-time
+option whose name starts "EXPERIMENTAL_" that must be set in
+order to include the feature. This file contains information
+about experimental features, all of which are unstable and
+liable to incompatible change.
+
+
+Brightmail AntiSpam (BMI) support
+--------------------------------------------------------------
+
+Brightmail AntiSpam is a commercial package. Please see
+http://www.brightmail.com for more information on
+the product. For the sake of clarity, we'll refer to it as
+"BMI" from now on.
+
+
+0) BMI concept and implementation overview
+
+In contrast to how spam-scanning with SpamAssassin is
+implemented in exiscan-acl, BMI is more suited for per
+-recipient scanning of messages. However, each messages is
+scanned only once, but multiple "verdicts" for multiple
+recipients can be returned from the BMI server. The exiscan
+implementation passes the message to the BMI server just
+before accepting it. It then adds the retrieved verdicts to
+the messages header file in the spool. These verdicts can then
+be queried in routers, where operation is per-recipient
+instead of per-message. To use BMI, you need to take the
+following steps:
+
+ 1) Compile Exim with BMI support
+ 2) Set up main BMI options (top section of Exim config file)
+ 3) Set up ACL control statement (ACL section of the config
+ file)
+ 4) Set up your routers to use BMI verdicts (routers section
+ of the config file).
+ 5) (Optional) Set up per-recipient opt-in information.
+
+These four steps are explained in more details below.
+
+1) Adding support for BMI at compile time
+
+ To compile with BMI support, you need to link Exim against
+ the Brightmail client SDK, consisting of a library
+ (libbmiclient_single.so) and a header file (bmi_api.h).
+ You'll also need to explicitly set a flag in the Makefile to
+ include BMI support in the Exim binary. Both can be achieved
+ with these lines in Local/Makefile:
+
+ EXPERIMENTAL_BRIGHTMAIL=yes
+ CFLAGS=-I/path/to/the/dir/with/the/includefile
+ EXTRALIBS_EXIM=-L/path/to/the/dir/with/the/library -lbmiclient_single
+
+ If you use other CFLAGS or EXTRALIBS_EXIM settings then
+ merge the content of these lines with them.
+
+ Note for BMI6.x users: You'll also have to add -lxml2_single
+ to the EXTRALIBS_EXIM line. Users of 5.5x do not need to do
+ this.
+
+ You should also include the location of
+ libbmiclient_single.so in your dynamic linker configuration
+ file (usually /etc/ld.so.conf) and run "ldconfig"
+ afterwards, or else the produced Exim binary will not be
+ able to find the library file.
+
+
+2) Setting up BMI support in the Exim main configuration
+
+ To enable BMI support in the main Exim configuration, you
+ should set the path to the main BMI configuration file with
+ the "bmi_config_file" option, like this:
+
+ bmi_config_file = /opt/brightmail/etc/brightmail.cfg
+
+ This must go into section 1 of Exim's configuration file (You
+ can put it right on top). If you omit this option, it
+ defaults to /opt/brightmail/etc/brightmail.cfg.
+
+ Note for BMI6.x users: This file is in XML format in V6.xx
+ and its name is /opt/brightmail/etc/bmiconfig.xml. So BMI
+ 6.x users MUST set the bmi_config_file option.
+
+
+3) Set up ACL control statement
+
+ To optimize performance, it makes sense only to process
+ messages coming from remote, untrusted sources with the BMI
+ server. To set up a messages for processing by the BMI
+ server, you MUST set the "bmi_run" control statement in any
+ ACL for an incoming message. You will typically do this in
+ an "accept" block in the "acl_check_rcpt" ACL. You should
+ use the "accept" block(s) that accept messages from remote
+ servers for your own domain(s). Here is an example that uses
+ the "accept" blocks from Exim's default configuration file:
+
+
+ accept domains = +local_domains
+ endpass
+ verify = recipient
+ control = bmi_run
+
+ accept domains = +relay_to_domains
+ endpass
+ verify = recipient
+ control = bmi_run
+
+ If bmi_run is not set in any ACL during reception of the
+ message, it will NOT be passed to the BMI server.
+
+
+4) Setting up routers to use BMI verdicts
+
+ When a message has been run through the BMI server, one or
+ more "verdicts" are present. Different recipients can have
+ different verdicts. Each recipient is treated individually
+ during routing, so you can query the verdicts by recipient
+ at that stage. From Exim's view, a verdict can have the
+ following outcomes:
+
+ o deliver the message normally
+ o deliver the message to an alternate location
+ o do not deliver the message
+
+ To query the verdict for a recipient, the implementation
+ offers the following tools:
+
+
+ - Boolean router preconditions. These can be used in any
+ router. For a simple implementation of BMI, these may be
+ all that you need. The following preconditions are
+ available:
+
+ o bmi_deliver_default
+
+ This precondition is TRUE if the verdict for the
+ recipient is to deliver the message normally. If the
+ message has not been processed by the BMI server, this
+ variable defaults to TRUE.
+
+ o bmi_deliver_alternate
+
+ This precondition is TRUE if the verdict for the
+ recipient is to deliver the message to an alternate
+ location. You can get the location string from the
+ $bmi_alt_location expansion variable if you need it. See
+ further below. If the message has not been processed by
+ the BMI server, this variable defaults to FALSE.
+
+ o bmi_dont_deliver
+
+ This precondition is TRUE if the verdict for the
+ recipient is NOT to deliver the message to the
+ recipient. You will typically use this precondition in a
+ top-level blackhole router, like this:
+
+ # don't deliver messages handled by the BMI server
+ bmi_blackhole:
+ driver = redirect
+ bmi_dont_deliver
+ data = :blackhole:
+
+ This router should be on top of all others, so messages
+ that should not be delivered do not reach other routers
+ at all. If the message has not been processed by
+ the BMI server, this variable defaults to FALSE.
+
+
+ - A list router precondition to query if rules "fired" on
+ the message for the recipient. Its name is "bmi_rule". You
+ use it by passing it a colon-separated list of rule
+ numbers. You can use this condition to route messages that
+ matched specific rules. Here is an example:
+
+ # special router for BMI rule #5, #8 and #11
+ bmi_rule_redirect:
+ driver = redirect
+ bmi_rule = 5:8:11
+ data = postmaster@mydomain.com
+
+
+ - Expansion variables. Several expansion variables are set
+ during routing. You can use them in custom router
+ conditions, for example. The following variables are
+ available:
+
+ o $bmi_base64_verdict
+
+ This variable will contain the BASE64 encoded verdict
+ for the recipient being routed. You can use it to add a
+ header to messages for tracking purposes, for example:
+
+ localuser:
+ driver = accept
+ check_local_user
+ headers_add = X-Brightmail-Verdict: $bmi_base64_verdict
+ transport = local_delivery
+
+ If there is no verdict available for the recipient being
+ routed, this variable contains the empty string.
+
+ o $bmi_base64_tracker_verdict
+
+ This variable will contain a BASE64 encoded subset of
+ the verdict information concerning the "rules" that
+ fired on the message. You can add this string to a
+ header, commonly named "X-Brightmail-Tracker". Example:
+
+ localuser:
+ driver = accept
+ check_local_user
+ headers_add = X-Brightmail-Tracker: $bmi_base64_tracker_verdict
+ transport = local_delivery
+
+ If there is no verdict available for the recipient being
+ routed, this variable contains the empty string.
+
+ o $bmi_alt_location
+
+ If the verdict is to redirect the message to an
+ alternate location, this variable will contain the
+ alternate location string returned by the BMI server. In
+ its default configuration, this is a header-like string
+ that can be added to the message with "headers_add". If
+ there is no verdict available for the recipient being
+ routed, or if the message is to be delivered normally,
+ this variable contains the empty string.
+
+ o $bmi_deliver
+
+ This is an additional integer variable that can be used
+ to query if the message should be delivered at all. You
+ should use router preconditions instead if possible.
+
+ $bmi_deliver is '0': the message should NOT be delivered.
+ $bmi_deliver is '1': the message should be delivered.
+
+
+ IMPORTANT NOTE: Verdict inheritance.
+ The message is passed to the BMI server during message
+ reception, using the target addresses from the RCPT TO:
+ commands in the SMTP transaction. If recipients get expanded
+ or re-written (for example by aliasing), the new address(es)
+ inherit the verdict from the original address. This means
+ that verdicts also apply to all "child" addresses generated
+ from top-level addresses that were sent to the BMI server.
+
+
+5) Using per-recipient opt-in information (Optional)
+
+ The BMI server features multiple scanning "profiles" for
+ individual recipients. These are usually stored in a LDAP
+ server and are queried by the BMI server itself. However,
+ you can also pass opt-in data for each recipient from the
+ MTA to the BMI server. This is particularly useful if you
+ already look up recipient data in Exim anyway (which can
+ also be stored in a SQL database or other source). This
+ implementation enables you to pass opt-in data to the BMI
+ server in the RCPT ACL. This works by setting the
+ 'bmi_optin' modifier in a block of that ACL. If should be
+ set to a list of comma-separated strings that identify the
+ features which the BMI server should use for that particular
+ recipient. Ideally, you would use the 'bmi_optin' modifier
+ in the same ACL block where you set the 'bmi_run' control
+ flag. Here is an example that will pull opt-in data for each
+ recipient from a flat file called
+ '/etc/exim/bmi_optin_data'.
+
+ The file format:
+
+ user1@mydomain.com: <OPTIN STRING1>:<OPTIN STRING2>
+ user2@thatdomain.com: <OPTIN STRING3>
+
+
+ The example:
+
+ accept domains = +relay_to_domains
+ endpass
+ verify = recipient
+ bmi_optin = ${lookup{$local_part@$domain}lsearch{/etc/exim/bmi_optin_data}}
+ control = bmi_run
+
+ Of course, you can also use any other lookup method that
+ Exim supports, including LDAP, Postgres, MySQL, Oracle etc.,
+ as long as the result is a list of colon-separated opt-in
+ strings.
+
+ For a list of available opt-in strings, please contact your
+ Brightmail representative.
+
+
+
+
+SRS (Sender Rewriting Scheme) Support (using libsrs_alt)
+--------------------------------------------------------------
+See also below, for an alternative native support implementation.
+
+Exim currently includes SRS support via Miles Wilton's
+libsrs_alt library. The current version of the supported
+library is 0.5, there are reports of 1.0 working.
+
+In order to use SRS, you must get a copy of libsrs_alt from
+
+https://opsec.eu/src/srs/
+
+(not the original source, which has disappeared.)
+
+Unpack the tarball, then refer to MTAs/README.EXIM
+to proceed. You need to set
+
+EXPERIMENTAL_SRS=yes
+
+in your Local/Makefile.
+
+The following main-section options become available:
+ srs_config string
+ srs_hashlength int
+ srs_hashmin int
+ srs_maxage int
+ srs_secrets string
+ srs_usehash bool
+ srs_usetimestamp bool
+
+The redirect router gains these options (all of type string, unset by default):
+ srs
+ srs_alias
+ srs_condition
+ srs_dbinsert
+ srs_dbselect
+
+The following variables become available:
+ $srs_db_address
+ $srs_db_key
+ $srs_orig_recipient
+ $srs_orig_sender
+ $srs_recipient
+ $srs_status
+
+The predefined feature-macro _HAVE_SRS will be present.
+Additional delivery log line elements, tagged with "SRS=" will show the srs sender.
+For configuration information see https://github.com/Exim/exim/wiki/SRS .
+
+
+
+
+SRS (Sender Rewriting Scheme) Support (native)
+--------------------------------------------------------------
+This is less full-featured than the libsrs_alt version above.
+
+The Exim build needs to be done with this in Local/Makefile:
+EXPERIMENTAL_SRS_NATIVE=yes
+
+The following are provided:
+- an expansion item "srs_encode"
+ This takes three arguments:
+ - a site SRS secret
+ - the return_path
+ - the pre-forwarding domain
+
+- an expansion condition "inbound_srs"
+ This takes two arguments: the local_part to check, and a site SRS secret.
+ If the secret is zero-length, only the pattern of the local_part is checked.
+ The $srs_recipient variable is set as a side-effect.
+
+- an expansion variable $srs_recipient
+ This gets the original return_path encoded in the SRS'd local_part
+
+- predefined macros _HAVE_SRS and _HAVE_NATIVE_SRS
+
+Sample usage:
+
+ #macro
+ SRS_SECRET = <pick something unique for your site for this>
+
+ #routers
+
+ outbound:
+ driver = dnslookup
+ # if outbound, and forwarding has been done, use an alternate transport
+ domains = ! +my_domains
+ transport = ${if eq {$local_part@$domain} \
+ {$original_local_part@$original_domain} \
+ {remote_smtp} {remote_forwarded_smtp}}
+
+ inbound_srs:
+ driver = redirect
+ senders = :
+ domains = +my_domains
+ # detect inbound bounces which are SRS'd, and decode them
+ condition = ${if inbound_srs {$local_part} {SRS_SECRET}}
+ data = $srs_recipient
+
+ inbound_srs_failure:
+ driver = redirect
+ senders = :
+ domains = +my_domains
+ # detect inbound bounces which look SRS'd but are invalid
+ condition = ${if inbound_srs {$local_part} {}}
+ allow_fail
+ data = :fail: Invalid SRS recipient address
+
+ #... further routers here
+
+
+ # transport; should look like the non-forward outbound
+ # one, plus the max_rcpt and return_path options
+ remote_forwarded_smtp:
+ driver = smtp
+ # modify the envelope from, for mails that we forward
+ max_rcpt = 1
+ return_path = ${srs_encode {SRS_SECRET} {$return_path} {$original_domain}}
+
+
+
+
+DCC Support
+--------------------------------------------------------------
+Distributed Checksum Clearinghouse; http://www.rhyolite.com/dcc/
+
+*) Building exim
+
+In order to build exim with DCC support add
+
+EXPERIMENTAL_DCC=yes
+
+to your Makefile. (Re-)build/install exim. exim -d should show
+EXPERIMENTAL_DCC under "Support for".
+
+
+*) Configuration
+
+In the main section of exim.cf add at least
+ dccifd_address = /usr/local/dcc/var/dccifd
+or
+ dccifd_address = <ip> <port>
+
+In the DATA ACL you can use the new condition
+ dcc = *
+
+After that "$dcc_header" contains the X-DCC-Header.
+
+Return values are:
+ fail for overall "R", "G" from dccifd
+ defer for overall "T" from dccifd
+ accept for overall "A", "S" from dccifd
+
+dcc = */defer_ok works as for spamd.
+
+The "$dcc_result" variable contains the overall result from DCC
+answer. There will an X-DCC: header added to the mail.
+
+Usually you'll use
+ defer !dcc = *
+to greylist with DCC.
+
+If you set, in the main section,
+ dcc_direct_add_header = true
+then the dcc header will be added "in deep" and if the spool
+file was already written it gets removed. This forces Exim to
+write it again if needed. This helps to get the DCC Header
+through to eg. SpamAssassin.
+
+If you want to pass even more headers in the middle of the
+DATA stage you can set
+ $acl_m_dcc_add_header
+to tell the DCC routines to add more information; eg, you might set
+this to some results from ClamAV. Be careful. Header syntax is
+not checked and is added "as is".
+
+In case you've troubles with sites sending the same queue items from several
+hosts and fail to get through greylisting you can use
+$acl_m_dcc_override_client_ip
+
+Setting $acl_m_dcc_override_client_ip to an IP address overrides the default
+of $sender_host_address. eg. use the following ACL in DATA stage:
+
+ warn set acl_m_dcc_override_client_ip = \
+ ${lookup{$sender_helo_name}nwildlsearch{/etc/mail/multipleip_sites}{$value}{}}
+ condition = ${if def:acl_m_dcc_override_client_ip}
+ log_message = dbg: acl_m_dcc_override_client_ip set to \
+ $acl_m_dcc_override_client_ip
+
+Then set something like
+# cat /etc/mail/multipleip_sites
+mout-xforward.gmx.net 82.165.159.12
+mout.gmx.net 212.227.15.16
+
+Use a reasonable IP. eg. one the sending cluster actually uses.
+
+
+
+DSN extra information
+---------------------
+If compiled with EXPERIMENTAL_DSN_INFO extra information will be added
+to DSN fail messages ("bounces"), when available. The intent is to aid
+tracing of specific failing messages, when presented with a "bounce"
+complaint and needing to search logs.
+
+
+The remote MTA IP address, with port number if nonstandard.
+Example:
+ Remote-MTA: X-ip; [127.0.0.1]:587
+Rationale:
+ Several addresses may correspond to the (already available)
+ dns name for the remote MTA.
+
+The remote MTA connect-time greeting.
+Example:
+ X-Remote-MTA-smtp-greeting: X-str; 220 the.local.host.name ESMTP Exim x.yz Tue, 2 Mar 1999 09:44:33 +0000
+Rationale:
+ This string sometimes presents the remote MTA's idea of its
+ own name, and sometimes identifies the MTA software.
+
+The remote MTA response to HELO or EHLO.
+Example:
+ X-Remote-MTA-helo-response: X-str; 250-the.local.host.name Hello localhost [127.0.0.1]
+Limitations:
+ Only the first line of a multiline response is recorded.
+Rationale:
+ This string sometimes presents the remote MTA's view of
+ the peer IP connecting to it.
+
+The reporting MTA detailed diagnostic.
+Example:
+ X-Exim-Diagnostic: X-str; SMTP error from remote mail server after RCPT TO:<d3@myhost.test.ex>: 550 hard error
+Rationale:
+ This string sometimes give extra information over the
+ existing (already available) Diagnostic-Code field.
+
+
+Note that non-RFC-documented field names and data types are used.
+
+
+LMDB Lookup support
+-------------------
+LMDB is an ultra-fast, ultra-compact, crash-proof key-value embedded data store.
+It is modeled loosely on the BerkeleyDB API. You should read about the feature
+set as well as operation modes at https://symas.com/products/lightning-memory-mapped-database/
+
+LMDB single key lookup support is provided by linking to the LMDB C library.
+The current implementation does not support writing to the LMDB database.
+
+Visit https://github.com/LMDB/lmdb to download the library or find it in your
+operating systems package repository.
+
+If building from source, this description assumes that headers will be in
+/usr/local/include, and that the libraries are in /usr/local/lib.
+
+1. In order to build exim with LMDB lookup support add or uncomment
+
+EXPERIMENTAL_LMDB=yes
+
+to your Local/Makefile. (Re-)build/install exim. exim -d should show
+Experimental_LMDB in the line "Support for:".
+
+EXPERIMENTAL_LMDB=yes
+LDFLAGS += -llmdb
+# CFLAGS += -I/usr/local/include
+# LDFLAGS += -L/usr/local/lib
+
+The first line sets the feature to include the correct code, and
+the second line says to link the LMDB libraries into the
+exim binary. The commented out lines should be uncommented if you
+built LMDB from source and installed in the default location.
+Adjust the paths if you installed them elsewhere, but you do not
+need to uncomment them if an rpm (or you) installed them in the
+package controlled locations (/usr/include and /usr/lib).
+
+2. Create your LMDB files, you can use the mdb_load utility which is
+part of the LMDB distribution our your favourite language bindings.
+
+3. Add the single key lookups to your exim.conf file, example lookups
+are below.
+
+${lookup{$sender_address_domain}lmdb{/var/lib/baruwa/data/db/relaydomains.mdb}{$value}}
+${lookup{$sender_address_domain}lmdb{/var/lib/baruwa/data/db/relaydomains.mdb}{$value}fail}
+${lookup{$sender_address_domain}lmdb{/var/lib/baruwa/data/db/relaydomains.mdb}}
+
+
+Queuefile transport
+-------------------
+Queuefile is a pseudo transport which does not perform final delivery.
+It simply copies the exim spool files out of the spool directory into
+an external directory retaining the exim spool format.
+
+The spool files can then be processed by external processes and then
+requeued into exim spool directories for final delivery.
+However, note carefully the warnings in the main documentation on
+qpool file formats.
+
+The motivation/inspiration for the transport is to allow external
+processes to access email queued by exim and have access to all the
+information which would not be available if the messages were delivered
+to the process in the standard email formats.
+
+The mailscanner package is one of the processes that can take advantage
+of this transport to filter email.
+
+The transport can be used in the same way as the other existing transports,
+i.e by configuring a router to route mail to a transport configured with
+the queuefile driver.
+
+The transport only takes one option:
+
+* directory - This is used to specify the directory messages should be
+copied to. Expanded.
+
+The generic transport options (body_only, current_directory, disable_logging,
+debug_print, delivery_date_add, envelope_to_add, event_action, group,
+headers_add, headers_only, headers_remove, headers_rewrite, home_directory,
+initgroups, max_parallel, message_size_limit, rcpt_include_affixes,
+retry_use_local_part, return_path, return_path_add, shadow_condition,
+shadow_transport, transport_filter, transport_filter_timeout, user) are
+ignored.
+
+Sample configuration:
+
+(Router)
+
+scan:
+ driver = accept
+ transport = scan
+
+(Transport)
+
+scan:
+ driver = queuefile
+ directory = /var/spool/baruwa-scanner/input
+
+
+In order to build exim with Queuefile transport support add or uncomment
+
+EXPERIMENTAL_QUEUEFILE=yes
+
+to your Local/Makefile. (Re-)build/install exim. exim -d should show
+Experimental_QUEUEFILE in the line "Support for:".
+
+
+ARC support
+-----------
+Specification: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11
+Note that this is not an RFC yet, so may change.
+
+[RFC 8617 was published 2019/06. Draft 11 was 2018/01. A review of the
+changes has not yet been done]
+
+ARC is intended to support the utility of SPF and DKIM in the presence of
+intermediaries in the transmission path - forwarders and mailinglists -
+by establishing a cryptographically-signed chain in headers.
+
+Normally one would only bother doing ARC-signing when functioning as
+an intermediary. One might do verify for local destinations.
+
+ARC uses the notion of a "ADministrative Management Domain" (ADMD).
+Described in RFC 5598 (section 2.3), this is essentially a set of
+mail-handling systems that mail transits that are all under the control
+of one organisation. A label should be chosen to identify the ADMD.
+Messages should be ARC-verified on entry to the ADMD, and ARC-signed on exit
+from it.
+
+
+Building with ARC Support
+--
+Enable using EXPERIMENTAL_ARC=yes in your Local/Makefile.
+You must also have DKIM present (not disabled), and you very likely
+want to have SPF enabled.
+
+
+Verification
+--
+An ACL condition is provided to perform the "verifier actions" detailed
+in section 6 of the above specification. It may be called from the DATA ACL
+and succeeds if the result matches any of a given list.
+It also records the highest ARC instance number (the chain size)
+and verification result for later use in creating an Authentication-Results:
+standard header.
+
+ verify = arc/<acceptable_list> none:fail:pass
+
+ add_header = :at_start:${authresults {<admd-identifier>}}
+
+ Note that it would be wise to strip incoming messages of A-R headers
+ that claim to be from our own <admd-identifier>.
+
+There are four new variables:
+
+ $arc_state One of pass, fail, none
+ $arc_state_reason (if fail, why)
+ $arc_domains colon-sep list of ARC chain domains, in chain order.
+ problematic elements may have empty list elements
+ $arc_oldest_pass lowest passing instance number of chain
+
+Example:
+ logwrite = oldest-p-ams: <${reduce {$lh_ARC-Authentication-Results:} \
+ {} \
+ {${if = {$arc_oldest_pass} \
+ {${extract {i}{${extract {1}{;}{$item}}}}} \
+ {$item} {$value}}} \
+ }>
+
+Receive log lines for an ARC pass will be tagged "ARC".
+
+
+Signing
+--
+arc_sign = <admd-identifier> : <selector> : <privkey> [ : <options> ]
+An option on the smtp transport, which constructs and prepends to the message
+an ARC set of headers. The textually-first Authentication-Results: header
+is used as a basis (you must have added one on entry to the ADMD).
+Expanded as a whole; if unset, empty or forced-failure then no signing is done.
+If it is set, all of the first three elements must be non-empty.
+
+The fourth element is optional, and if present consists of a comma-separated list
+of options. The options implemented are
+
+ timestamps Add a t= tag to the generated AMS and AS headers, with the
+ current time.
+ expire[=<val>] Add an x= tag to the generated AMS header, with an expiry time.
+ If the value <val> is an plain number it is used unchanged.
+ If it starts with a '+' then the following number is added
+ to the current time, as an offset in seconds.
+ If a value is not given it defaults to a one month offset.
+
+[As of writing, gmail insist that a t= tag on the AS is mandatory]
+
+Caveats:
+ * There must be an Authentication-Results header, presumably added by an ACL
+ while receiving the message, for the same ADMD, for arc_sign to succeed.
+ This requires careful coordination between inbound and outbound logic.
+
+ Only one A-R header is taken account of. This is a limitation versus
+ the ARC spec (which says that all A-R headers from within the ADMD must
+ be used).
+
+ * If passing a message to another system, such as a mailing-list manager
+ (MLM), between receipt and sending, be wary of manipulations to headers made
+ by the MLM.
+ + For instance, Mailman with REMOVE_DKIM_HEADERS==3 might improve
+ deliverability in a pre-ARC world, but that option also renames the
+ Authentication-Results header, which breaks signing.
+
+ * Even if you use multiple DKIM keys for different domains, the ARC concept
+ should try to stick to one ADMD, so pick a primary domain and use that for
+ AR headers and outbound signing.
+
+Signing is not compatible with cutthrough delivery; any (before expansion)
+value set for the option will result in cutthrough delivery not being
+used via the transport in question.
+
+
+
+
+TLS Session Resumption
+----------------------
+TLS Session Resumption for TLS 1.2 and TLS 1.3 connections can be used (defined
+in RFC 5077 for 1.2). The support for this can be included by building with
+EXPERIMENTAL_TLS_RESUME defined. This requires GnuTLS 3.6.3 or OpenSSL 1.1.1
+(or later).
+
+Session resumption (this is the "stateless" variant) involves the server sending
+a "session ticket" to the client on one connection, which can be stored by the
+client and used for a later session. The ticket contains sufficient state for
+the server to reconstruct the TLS session, avoiding some expensive crypto
+calculation and one full packet roundtrip time.
+
+Operational cost/benefit:
+ The extra data being transmitted costs a minor amount, and the client has
+ extra costs in storing and retrieving the data.
+
+ In the Exim/Gnutls implementation the extra cost on an initial connection
+ which is TLS1.2 over a loopback path is about 6ms on 2017-laptop class hardware.
+ The saved cost on a subsequent connection is about 4ms; three or more
+ connections become a net win. On longer network paths, two or more
+ connections will have an average lower startup time thanks to the one
+ saved packet roundtrip. TLS1.3 will save the crypto cpu costs but not any
+ packet roundtrips.
+
+ Since a new hints DB is used, the hints DB maintenance should be updated
+ to additionally handle "tls".
+
+Security aspects:
+ The session ticket is encrypted, but is obviously an additional security
+ vulnarability surface. An attacker able to decrypt it would have access
+ all connections using the resumed session.
+ The session ticket encryption key is not committed to storage by the server
+ and is rotated regularly (OpenSSL: 1hr, and one previous key is used for
+ overlap; GnuTLS 6hr but does not specify any overlap).
+ Tickets have limited lifetime (2hr, and new ones issued after 1hr under
+ OpenSSL. GnuTLS 2hr, appears to not do overlap).
+
+ There is a question-mark over the security of the Diffie-Helman parameters
+ used for session negotiation. TBD. q-value; cf bug 1895
+
+Observability:
+ New log_selector "tls_resumption", appends an asterisk to the tls_cipher "X="
+ element.
+
+ Variables $tls_{in,out}_resumption have bits 0-4 indicating respectively
+ support built, client requested ticket, client offered session,
+ server issued ticket, resume used. A suitable decode list is provided
+ in the builtin macro _RESUME_DECODE for ${listextract {}{}}.
+
+Issues:
+ In a resumed session:
+ $tls_{in,out}_cipher will have values different to the original (under GnuTLS)
+ $tls_{in,out}_ocsp will be "not requested" or "no response", and
+ hosts_require_ocsp will fail
+
+
+
+Dovecot authenticator via inet socket
+------------------------------------
+If Dovecot is configured similar to :-
+
+service auth {
+...
+#SASL
+ inet_listener {
+ name = exim
+ port = 12345
+ }
+...
+}
+
+then an Exim authenticator can be configured :-
+
+ dovecot-plain:
+ driver = dovecot
+ public_name = PLAIN
+ server_socket = dovecot_server_name 12345
+ server_tls = true
+ server_set_id = $auth1
+
+If the server_socket does not start with a / it is taken as a hostname (or IP);
+and a whitespace-separated port number must be given.
+
+
+
+Twophase queue run fast ramp
+----------------------------
+To include this feature, add to Local/Makefile:
+ EXPERIMENTAL_QUEUE_RAMP=yes
+
+If the (added for this feature) main-section option "queue_fast_ramp" (boolean)
+is set, and a two-phase ("-qq") queue run finds, during the first phase, a
+suitably large number of message routed for a given host - then (subject to
+the usual queue-runner resource limits) delivery for that host is initiated
+immediately, overlapping with the remainder of the first phase.
+
+This is incompatible with queue_run_in_order.
+
+The result should be a faster startup of deliveries when a large queue is
+present and reasonable numbers of messages are routed to common hosts; this
+could be a smarthost case, or delivery onto the Internet where a large proportion
+of recipients hapen to be on a Gorilla-sized provider.
+
+As usual, the presence of a configuration option is associated with a
+predefined macro, making it possible to write portable configurations.
+For this one, the macro is _OPT_MAIN_QUEUE_FAST_RAMP.
+
+
+
+--------------------------------------------------------------
+End of file
+--------------------------------------------------------------