Docs: change note

[users/heiko/exim.git] / doc / doc-docbook / spec.xfpt

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 2938de5761645f7fc7fcf229e43d9f98683405c2..4c79e87cf81aae44eb0bbd798ddd53f058d7ee79 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -28181,6 +28181,10 @@ supplied by the server.
 .option server_channelbinding gsasl boolean false
 Do not set this true and rely on the properties
 without consulting a cryptographic engineer.
+. Unsure what that's about.  It might be the "Triple Handshake"
+. vulnerability; cf. https://www.mitls.org/pages/attacks/3SHAKE
+. If so, we're ok, requiring Extended Master Secret if TLS
+. Session Resumption was used.
 
 Some authentication mechanisms are able to use external context at both ends
 of the session to bind the authentication to that context, and fail the
@@ -38312,8 +38316,11 @@ parentheses afterwards.
 When more than one address is included in a single delivery (for example, two
 SMTP RCPT commands in one transaction) the second and subsequent addresses are
 flagged with &`->`& instead of &`=>`&. When two or more messages are delivered
-down a single SMTP connection, an asterisk follows the IP address in the log
-lines for the second and subsequent messages.
+down a single SMTP connection, an asterisk follows the
+.new
+remote IP address (and port if enabled)
+.wen
+in the log lines for the second and subsequent messages.
 When two or more messages are delivered down a single TLS connection, the
 DNS and some TLS-related information logged for the first message delivered
 will not be present in the log lines for the second and subsequent messages.