X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/1ad20e19a669731c19852c865facabe4816ae4f9..ee3c2fea18d0c940c2256c6bf041f546c703c375:/doc/doc-docbook/spec.xfpt diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt index 23f34a3d0..7372dd3fe 100644 --- a/doc/doc-docbook/spec.xfpt +++ b/doc/doc-docbook/spec.xfpt @@ -6424,9 +6424,9 @@ smarthost_smtp: # request with your smarthost provider to get things fixed: hosts_require_tls = * tls_verify_hosts = * - # As long as tls_verify_hosts is enabled, this won't matter, but if you - # have to comment it out then this will at least log whether you succeed - # or not: + # As long as tls_verify_hosts is enabled, this this will have no effect, + # but if you have to comment it out then this will at least log whether + # you succeed or not: tls_try_verify_hosts = * # # The SNI name should match the name which we'll expect to verify; @@ -27235,7 +27235,7 @@ choose to honour. A &'realm'& is a text string, typically a domain name, presented by a server to a client to help it select an account and credentials to use. In some -mechanisms, the client and server probably agree on the realm, but clients +mechanisms, the client and server provably agree on the realm, but clients typically can not treat the realm as secure data to be blindly trusted. @@ -29807,7 +29807,7 @@ Ivan is the author of the popular TLS testing tools at .section "Certificate chains" "SECID186" -The file named by &%tls_certificate%& may contain more than one +A file named by &%tls_certificate%& may contain more than one certificate. This is useful in the case where the certificate that is being sent is validated by an intermediate certificate which the other end does not have. Multiple certificates must be in the correct order in the file. @@ -41025,7 +41025,7 @@ There is no dot-stuffing (and no dot-termination). .section "DKIM (DomainKeys Identified Mail)" SECDKIM .cindex "DKIM" -DKIM is a mechanism by which messages sent by some entity can be probably +DKIM is a mechanism by which messages sent by some entity can be provably linked to a domain which that entity controls. It permits reputation to be tracked on a per-domain basis, rather than merely upon source IP address. DKIM is documented in RFC 6376.