Docs: add note on HELO rejections, and add requirment on good HELO in

the example configuration

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 6b4b5f314d6ede7342922b013b7d2e1087510547..44623a5502523e90e3594a25656be4e3290709a5 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -27548,6 +27548,12 @@ Note that a client may issue more than one EHLO or HELO command in an SMTP
 session, and indeed is required to issue a new EHLO or HELO after successfully
 setting up encryption following a STARTTLS command.
 
+.new
+Note also that a deny neither forces the client to go away nor means that
+mail will be refused on the connection.  Consider checking for
+&$sender_helo_name$& being defined in a MAIL or RCPT ACL to do that.
+.wen
+
 If the command is accepted by an &%accept%& verb that has a &%message%&
 modifier, the message may not contain more than one line (it will be truncated
 at the first newline and a panic logged if it does). Such a message cannot

diff --git a/src/src/configure.default b/src/src/configure.default
index ec60700dfefbef91b2d97dd8d285e26f006e5cbb..ee94d2f910b72636f2217f25e401f752943d6f74 100644 (file)
--- a/src/src/configure.default
+++ b/src/src/configure.default
@@ -436,6 +436,11 @@ acl_check_rcpt:
           control       = submission
           control       = dkim_disable_verify
 
+  # Insist that a HELO/EHLO was accepted.
+
+  require message      = nice hosts say HELO first
+          condition    = ${if def:sender_helo_name}
+
   # Insist that any other recipient address that we accept is either in one of
   # our local domains, or is in a domain for which we explicitly allow
   # relaying. Any other domain is rejected as being unacceptable for relaying.