X-Git-Url: https://git.exim.org/users/jgh/exim.git/blobdiff_plain/48155ab3b10f5357609b083ec83d70bd544a5783..eb445b049c9b78cbe187b9cb3c318d65862d4851:/doc/doc-txt/experimental-spec.txt diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt index 855f9899a..4e244ac5f 100644 --- a/doc/doc-txt/experimental-spec.txt +++ b/doc/doc-txt/experimental-spec.txt @@ -430,14 +430,12 @@ package controlled locations (/usr/include and /usr/lib). 2. Use the following global settings to configure DMARC: -Optional: +Required: dmarc_tld_file Defines the location of a text file of valid top level domains the opendmarc library uses during domain parsing. Maintained by Mozilla, the most current version can be downloaded from a link at http://publicsuffix.org/list/. - If unset, "/etc/exim/opendmarc.tlds" (hardcoded) - is used. Optional: dmarc_history_file Defines the location of a file to log results @@ -525,6 +523,9 @@ Of course, you can also use any other lookup method that Exim supports, including LDAP, Postgres, MySQL, etc, as long as the result is a list of colon-separated strings. +Performing the check sets up information used by the +${authresults } expansion item. + Several expansion variables are set before the DATA ACL is processed, and you can use them in this ACL. The following expansion variables are available: @@ -548,9 +549,8 @@ expansion variables are available: are "none", "reject" and "quarantine". It is blank when there is any error, including no DMARC record. - o $dmarc_ar_header - This is the entire Authentication-Results header which you can - add using an add_header modifier. +A now-redundant variable $dmarc_ar_header has now been withdrawn. +Use the ${authresults } expansion instead. 5. How to enable DMARC advanced operation: @@ -590,7 +590,6 @@ b. Configure, somewhere before the DATA ACL, the control option to warn dmarc_status = accept : none : off !authenticated = * log_message = DMARC DEBUG: $dmarc_status $dmarc_used_domain - add_header = $dmarc_ar_header warn dmarc_status = !accept !authenticated = * @@ -609,161 +608,7 @@ b. Configure, somewhere before the DATA ACL, the control option to !authenticated = * message = Message from $dmarc_used_domain failed sender's DMARC policy, REJECT - - -DANE ------------------------------------------------------------- -DNS-based Authentication of Named Entities, as applied -to SMTP over TLS, provides assurance to a client that -it is actually talking to the server it wants to rather -than some attacker operating a Man In The Middle (MITM) -operation. The latter can terminate the TLS connection -you make, and make another one to the server (so both -you and the server still think you have an encrypted -connection) and, if one of the "well known" set of -Certificate Authorities has been suborned - something -which *has* been seen already (2014), a verifiable -certificate (if you're using normal root CAs, eg. the -Mozilla set, as your trust anchors). - -What DANE does is replace the CAs with the DNS as the -trust anchor. The assurance is limited to a) the possibility -that the DNS has been suborned, b) mistakes made by the -admins of the target server. The attack surface presented -by (a) is thought to be smaller than that of the set -of root CAs. - -It also allows the server to declare (implicitly) that -connections to it should use TLS. An MITM could simply -fail to pass on a server's STARTTLS. - -DANE scales better than having to maintain (and -side-channel communicate) copies of server certificates -for every possible target server. It also scales -(slightly) better than having to maintain on an SMTP -client a copy of the standard CAs bundle. It also -means not having to pay a CA for certificates. - -DANE requires a server operator to do three things: -1) run DNSSEC. This provides assurance to clients -that DNS lookups they do for the server have not -been tampered with. The domain MX record applying -to this server, its A record, its TLSA record and -any associated CNAME records must all be covered by -DNSSEC. -2) add TLSA DNS records. These say what the server -certificate for a TLS connection should be. -3) offer a server certificate, or certificate chain, -in TLS connections which is traceable to the one -defined by (one of?) the TSLA records - -There are no changes to Exim specific to server-side -operation of DANE. - -The TLSA record for the server may have "certificate -usage" of DANE-TA(2) or DANE-EE(3). The latter specifies -the End Entity directly, i.e. the certificate involved -is that of the server (and should be the sole one transmitted -during the TLS handshake); this is appropriate for a -single system, using a self-signed certificate. - DANE-TA usage is effectively declaring a specific CA -to be used; this might be a private CA or a public, -well-known one. A private CA at simplest is just -a self-signed certificate which is used to sign -cerver certificates, but running one securely does -require careful arrangement. If a private CA is used -then either all clients must be primed with it, or -(probably simpler) the server TLS handshake must transmit -the entire certificate chain from CA to server-certificate. -If a public CA is used then all clients must be primed with it -(losing one advantage of DANE) - but the attack surface is -reduced from all public CAs to that single CA. -DANE-TA is commonly used for several services and/or -servers, each having a TLSA query-domain CNAME record, -all of which point to a single TLSA record. - -The TLSA record should have a Selector field of SPKI(1) -and a Matching Type field of SHA2-512(2). - -At the time of writing, https://www.huque.com/bin/gen_tlsa -is useful for quickly generating TLSA records; and commands like - - openssl x509 -in -pubkey -noout /dev/null \ - | openssl sha512 \ - | awk '{print $2}' - -are workable for 4th-field hashes. - -For use with the DANE-TA model, server certificates -must have a correct name (SubjectName or SubjectAltName). - -The use of OCSP-stapling should be considered, allowing -for fast revocation of certificates (which would otherwise -be limited by the DNS TTL on the TLSA records). However, -this is likely to only be usable with DANE-TA. NOTE: the -default of requesting OCSP for all hosts is modified iff -DANE is in use, to: - - hosts_request_ocsp = ${if or { {= {0}{$tls_out_tlsa_usage}} \ - {= {4}{$tls_out_tlsa_usage}} } \ - {*}{}} - -The (new) variable $tls_out_tlsa_usage is a bitfield with -numbered bits set for TLSA record usage codes. -The zero above means DANE was not in use, -the four means that only DANE-TA usage TLSA records were -found. If the definition of hosts_request_ocsp includes the -string "tls_out_tlsa_usage", they are re-expanded in time to -control the OCSP request. - -This modification of hosts_request_ocsp is only done if -it has the default value of "*". Admins who change it, and -those who use hosts_require_ocsp, should consider the interaction -with DANE in their OCSP settings. - - -For client-side DANE there are two new smtp transport options, -hosts_try_dane and hosts_require_dane. -[ should they be domain-based rather than host-based? ] - -Hosts_require_dane will result in failure if the target host -is not DNSSEC-secured. - -DANE will only be usable if the target host has DNSSEC-secured -MX, A and TLSA records. - -A TLSA lookup will be done if either of the above options match -and the host-lookup succeeded using dnssec. -If a TLSA lookup is done and succeeds, a DANE-verified TLS connection -will be required for the host. If it does not, the host will not -be used; there is no fallback to non-DANE or non-TLS. - -If DANE is requested and useable (see above) the following transport -options are ignored: - hosts_require_tls - tls_verify_hosts - tls_try_verify_hosts - tls_verify_certificates - tls_crl - tls_verify_cert_hostnames - -If DANE is not usable, whether requested or not, and CA-anchored -verification evaluation is wanted, the above variables should be set -appropriately. - -Currently dnssec_request_domains must be active (need to think about that) -and dnssec_require_domains is ignored. - -If verification was successful using DANE then the "CV" item -in the delivery log line will show as "CV=dane". - -There is a new variable $tls_out_dane which will have "yes" if -verification succeeded using DANE and "no" otherwise (only useful -in combination with EXPERIMENTAL_EVENT), and a new variable -$tls_out_tlsa_usage (detailed above). - -Under GnuTLS, DANE is only supported from versin 3.0.0 onwards + warn add_header = :at_start:${authresults {$primary_hostname}} @@ -879,7 +724,7 @@ the queuefile driver. The transport only takes one option: * directory - This is used to specify the directory messages should be -copied to +copied to. Expanded. The generic transport options (body_only, current_directory, disable_logging, debug_print, delivery_date_add, envelope_to_add, event_action, group, @@ -912,6 +757,75 @@ 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. + +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 the set of +mail-handling systems that the mail transits. 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. + + +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/ none:fail:pass + + add_header = :at_start:${authresults {}} + + Note that it would be wise to strip incoming messages of A-R headers + that claim to be from our own . + +There are two new variables: $arc_state and $arc_state_reason. + +Receive log lines for an ARC pass will be tagged "ARC". + + +Signing +-- +arc_sign = : : +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 three elements must be non-empty. + +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. + * 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. + + + -------------------------------------------------------------- End of file --------------------------------------------------------------