X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/1a2e76e1676bf405a464a233950a95012533c227..1cf47989a0376c3f7156c214c1d509d372e4262b:/doc/doc-txt/experimental-spec.txt diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt index 2b77d2647..47cd93f3d 100644 --- a/doc/doc-txt/experimental-spec.txt +++ b/doc/doc-txt/experimental-spec.txt @@ -292,10 +292,11 @@ These four steps are explained in more details below. -SRS (Sender Rewriting Scheme) Support +SRS (Sender Rewriting Scheme) Support (using libsrs_alt) -------------------------------------------------------------- +See also the main docs, for an alternative native support implementation. -Exiscan currently includes SRS support via Miles Wilton's +Exim can be built with SRS support using Miles Wilton's libsrs_alt library. The current version of the supported library is 0.5, there are reports of 1.0 working. @@ -308,10 +309,43 @@ https://opsec.eu/src/srs/ Unpack the tarball, then refer to MTAs/README.EXIM to proceed. You need to set -EXPERIMENTAL_SRS=yes +EXPERIMENTAL_SRS_ALT=yes in your Local/Makefile. +The built-in support, included by SUPPORT_SRS, +shuold *not* be enabled if you wish to use the libsrs_alt +version. + +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 . + + DCC Support @@ -432,52 +466,6 @@ Rationale: 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. @@ -542,6 +530,9 @@ 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. @@ -550,10 +541,18 @@ 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. +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 @@ -639,63 +638,47 @@ used via the transport in question. +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. + + + + +Logging protocol unusual states +--------------------------------------------------------------- +An extra log_selector, "protocol_detail" has been added in the default build. +The name may change in future, hence the Experimenal status. -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 +Currrently the only effect is to enable logging, under TLS, +of a TCP RST received directly after a QUIT (in server mode). +Outlook is consistently doing this; not waiting for the SMTP response +to its QUIT, not properly closing the TLS session and not properly closing +the TCP connection. Previously this resulted is an error from SSL_write +being logged. -------------------------------------------------------------- End of file