Support use-but-not-create of notifier socket

[user/henk/code/exim.git] / doc / doc-docbook / spec.xfpt

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 6545d091be164d36c8b677a3785f47b3624260db..cc59230698cd8af1bc59f403923edeaf0fca40e9 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -4397,15 +4397,21 @@ It is only relevant when the &%-bd%& (start listening daemon) option is also
 given.
 Normally the daemon creates this socket, unless a &%-oX%& and &*no*& &%-oP%&
 option is also present.
-If this option is given then the socket will not be created.  This could be
-required if the system is running multiple daemons.
+.new
+If this option is given then the socket will not be created.  This is required
+if the system is running multiple daemons, in which case it should
+be used on all.
+The features supported by the socket will not be available in such cases.
 
 The socket is currently used for
 .ilist
 fast ramp-up of queue runner processes
 .next
+caching compiled regexes
+.next
 obtaining a current queue size
 .endlist
+.wen
 
 .cmdopt -pd
 .cindex "Perl" "starting the interpreter"
@@ -4489,23 +4495,33 @@ every domain. Addresses are routed, local deliveries happen, but no remote
 transports are run.
 
 Performance will be best if the &%queue_run_in_order%& option is false.
-If that is so and the &%queue_fast_ramp%& option is true then
-in the first phase of the run,
+If that is so and
+the &%queue_fast_ramp%& option is true
+and a daemon-notifier socket is available
+then in the first phase of the run,
 once a threshold number of messages are routed for a given host,
 a delivery process is forked in parallel with the rest of the scan.
 
 .cindex "hints database" "remembering routing"
 The hints database that remembers which messages are waiting for specific hosts
-is updated, as if delivery to those hosts had been deferred. After this is
-complete, a second, normal queue scan happens, with routing and delivery taking
-place as normal. Messages that are routed to the same host should mostly be
+is updated, as if delivery to those hosts had been deferred.
+
+After the first queue scan complete,
+a second, normal queue scan is done, with routing and delivery taking
+place as normal.
+Messages that are routed to the same host should mostly be
 delivered down a single SMTP
 .cindex "SMTP" "passed connection"
 .cindex "SMTP" "multiple deliveries"
 .cindex "multiple SMTP deliveries"
 connection because of the hints that were set up during the first queue scan.
-This option may be useful for hosts that are connected to the Internet
+
+.new
+Two-phase queue runs should be used on systems which, even intermittently,
+have a large queue (such as mailing-list operators).
+They may also be useful for hosts that are connected to the Internet
 intermittently.
+.wen
 
 .vitem &%-q[q]i...%&
 .oindex "&%-qi%&"
@@ -18458,7 +18474,7 @@ acceptable bound from 1024 to 2048.
 .cindex TLS "EC cryptography"
 This option selects EC curves for use by Exim when used with OpenSSL.
 It has no effect when Exim is used with GnuTLS
- (the equivalent can be done using a priority string for the
+(the equivalent can be done using a priority string for the
 &%tls_require_ciphers%& option).
 
 After expansion it must contain
@@ -30000,13 +30016,10 @@ file from every certificate authority they know of.
 .next
 The way with most moving parts at query time is Online Certificate
 Status Protocol (OCSP), where the client verifies the certificate
-against an OCSP server run by the CA.
-OCSP is based on HTTP and can be proxied accordingly.
-It requires the CA running software with access to the
-private key of the CA, to sign the responses to the OCSP queries.
-Because every client TLS transaction with a server results in an OCSP
-access to the CA, it results in a heavy load on the CA.
-It also lets the CA track all usage of the certs, which is a privacy problem.
+against an OCSP server run by the CA.  This lets the CA track all
+usage of the certs.  It requires running software with access to the
+private key of the CA, to sign the responses to the OCSP queries.  OCSP
+is based on HTTP and can be proxied accordingly.
 
 The only widespread OCSP server implementation (known to this writer)
 comes as part of OpenSSL and aborts on an invalid request, such as
@@ -30016,8 +30029,7 @@ re-entering the passphrase each time some random client does this.
 .next
 The third way is OCSP Stapling; in this, the server using a certificate
 issued by the CA periodically requests an OCSP proof of validity from
-the OCSP server (probably using the original OCSP above),
-then serves it up inline as part of the TLS
+the OCSP server, then serves it up inline as part of the TLS
 negotiation.   This approach adds no extra round trips, does not let the
 CA track users, scales well with number of certs issued by the CA and is
 resilient to temporary OCSP server failures, as long as the server