X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/4a90d4879978fe062e0539da0942c3f9176f5b9b..4a92bfe6da547eb599b76da068b8b908e1c509b7:/doc/doc-txt/experimental-spec.txt diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt index 8c9a866a2..47cd93f3d 100644 --- a/doc/doc-txt/experimental-spec.txt +++ b/doc/doc-txt/experimental-spec.txt @@ -639,7 +639,7 @@ used via the transport in question. Dovecot authenticator via inet socket ------------------------------------- +-------------------------------------------------------------- If Dovecot is configured similar to :- service auth { @@ -666,29 +666,19 @@ 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. +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. -------------------------------------------------------------- End of file