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.
-
-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 {
-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.
+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.
+
+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.
+
+
+
+Limits ESMTP extension
+---------------------------------------------------------------
+Per https://datatracker.ietf.org/doc/html/draft-freed-smtp-limits-01
+
+If compiled with EXPERIMENTAL_ESMTP_LIMITS=yes :-
+
+As a server, Exim will advertise, in the EHLO response, the limit for RCPT
+commands set by the recipients_max main-section config option (if it is set),
+and the limit for MAIL commands set by the smtp_accept_max_per_connection
+option.
+
+Note that as of writing, smtp_accept_max_per_connection is expanded but
+recipients_max is not.
+
+A new main-section option "limits_advertise_hosts" controls whether
+the limits are advertised; the default for the option is "*".
+
+As a client, Exim will:
-This is incompatible with queue_run_in_order.
+ - note an advertised MAILMAX; the lower of the value given and the
+ value from the transport connection_max_messages option is used.
-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.
+ - note an advertised RCPTMAX; the lower of the
+ value given and the value from the transport max_rcpt option is used.
+ Parallisation of transactions is not done if due to a RCPTMAX, unlike
+ max_rcpt.
-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.
+ - note an advertised RCPTDOMAINMAX, and behave as if the transport
+ multi_domains option was set to false. The value advertised is ignored.
+Values advertised are only noted for TLS connections and ones for which
+the server does not advertise TLS support.
--------------------------------------------------------------
git://git.exim.org / exim.git / blobdiff