X-Git-Url: https://git.exim.org/users/jgh/exim.git/blobdiff_plain/2b8d6aff36a25e06f418aec9e90fe7668562914b..3c07dd2d53dbb0e4a569e26e5c0f3dcaa55ce251:/doc/doc-docbook/spec.xfpt

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 8ae08e787..8fde6397c 100644
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -509,7 +509,7 @@ message to the &'exim-dev'& mailing list and have it discussed.
 .cindex "distribution" "https site"
 The master distribution site for the Exim distribution is
 .display
-.url(https://downloads.exim.org/)
+&url(https://downloads.exim.org/)
 .endd
 The service is available over HTTPS, HTTP and FTP.
 We encourage people to migrate to HTTPS.
@@ -27773,7 +27773,7 @@ session with a client, you must set either &%tls_verify_hosts%& or
 apply to all TLS connections. For any host that matches one of these options,
 Exim requests a certificate as part of the setup of the TLS session. The
 contents of the certificate are verified by comparing it with a list of
-expected certificates.
+expected trust-anchors or certificates.
 These may be the system default set (depending on library version),
 an explicit file or,
 depending on library version, a directory, identified by
@@ -27790,6 +27790,9 @@ openssl x509 -hash -noout -in /cert/file
 .endd
 where &_/cert/file_& contains a single certificate.
 
+There is no checking of names of the client against the certificate
+Subject Name or Subject Alternate Names.
+
 The difference between &%tls_verify_hosts%& and &%tls_try_verify_hosts%& is
 what happens if the client does not supply a certificate, or if the certificate
 does not match any of the certificates in the collection named by
@@ -27951,6 +27954,11 @@ The &%tls_verify_hosts%& and &%tls_try_verify_hosts%& options restrict
 certificate verification to the listed servers.  Verification either must
 or need not succeed respectively.
 
+The &%tls_verify_cert_hostnames%& option lists hosts for which additional
+checks are made: that the host name (the one in the DNS A record)
+is valid for the certificate.
+The option defaults to always checking.
+
 The &(smtp)& transport has two OCSP-related options:
 &%hosts_require_ocsp%&; a host-list for which a Certificate Status
 is requested and required for the connection to proceed.  The default
@@ -28125,7 +28133,7 @@ The Apache web-server was for a long time the canonical guide, so their
 documentation is a good place to start; their SSL module's Introduction
 document is currently at
 .display
-.url(https://httpd.apache.org/docs/current/ssl/ssl_intro.html)
+&url(https://httpd.apache.org/docs/current/ssl/ssl_intro.html)
 .endd
 and their FAQ is at
 .display
@@ -28256,7 +28264,7 @@ 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 (with certain
-attributes) which is used to sign cerver certificates, but running one securely
+attributes) which is used to sign server certificates, but running one securely
 does require careful arrangement.
 With DANE-TA, as implemented in Exim and commonly in other MTAs,
 the server TLS handshake must transmit the entire certificate chain from CA to server-certificate.
@@ -40089,6 +40097,8 @@ with the event type:
 .display
 &`dane:fail            `& failure reason
 &`msg:delivery         `& smtp confirmation message
+&`msg:fail:internal    `& failure reason
+&`msg:fail:delivery    `& smtp error message
 &`msg:rcpt:host:defer  `& error string
 &`msg:rcpt:defer       `& error string
 &`msg:host:defer       `& error string