X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/5054c4fdb5c5949872020d75beb5722eabe3d1d3..75c121f07a85b4029458f11b113a4655114af126:/doc/doc-txt/experimental-spec.txt?ds=sidebyside diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt index aa93e07bf..49935fb40 100644 --- a/doc/doc-txt/experimental-spec.txt +++ b/doc/doc-txt/experimental-spec.txt @@ -447,11 +447,19 @@ dmarc_history_file Defines the location of a file to log results directory of this file is writable by the user exim runs as. -dmarc_forensic_sender The email address to use when sending a +dmarc_forensic_sender Alternate email address to use when sending a forensic report detailing alignment failures if a sender domain's dmarc record specifies it and you have configured Exim to send them. - Default: do-not-reply@$default_hostname + + If set, this is expanded and used for the + From: header line; the address is extracted + from it and used for the envelope from. + If not set, the From: header is expanded from + the dsn_from option, and <> is used for the + envelope from. + + Default: unset. 3. By default, the DMARC processing will run for any remote, @@ -709,6 +717,8 @@ 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 @@ -793,7 +803,7 @@ standard header. Note that it would be wise to strip incoming messages of A-R headers that claim to be from our own . -There are three new variables: $arc_state, $arc_state_reason, $arc_domains: +There are four new variables: $arc_state One of pass, fail, none $arc_state_reason (if fail, why) @@ -860,6 +870,40 @@ used via the transport in question. + +REQUIRETLS support +------------------ +Ref: https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-03 + +If compiled with EXPERIMENTAL_REQUIRETLS support is included for this +feature, where a REQUIRETLS option is added to the MAIL command. +The client may not retry in clear if the MAIL+REQUIRETLS fails (or was never +offered), and the server accepts an obligation that any onward transmission +by SMTP of the messages accepted will also use REQUIRETLS - or generate a +fail DSN. + +The Exim implementation includes +- a main-part option tls_advertise_requiretls; host list, default "*" +- an observability variable $requiretls returning yes/no +- an ACL "control = requiretls" modifier for setting the requirement +- Log lines and Received: headers capitalise the S in the protocol + element: "P=esmtpS" + +Differences from spec: +- we support upgrading the requirement for REQUIRETLS, including adding + it from cold, within an MTA. The spec only define the sourcing MUA + as being able to source the requirement, and makes no mention of upgrade. +- No support is coded for the RequireTLS header (which can be used + to annul DANE and/or STS policiy). [this can _almost_ be done in + transport option expansions, but not quite: it requires tha DANE-present + but STARTTLS-failing targets fallback to cleartext, which current DANE + coding specifically blocks] + +Note that REQUIRETLS is only advertised once a TLS connection is achieved +(in contrast to STARTTLS). If you want to check the advertising, do something +like "swaks -s 127.0.0.1 -tls -q HELO". + + -------------------------------------------------------------- End of file --------------------------------------------------------------