On 2019-09-06 at 22:04 +0200, Heiko Schlittermann via Exim-users wrote:
> The HELO ACL doesn't help either, as the first EHLO comes before
> STARTTLS, and the second EHLO doesn't have to come, the client may send
Oh pox. My memory is going. I hadn't realized that my protection
against this comes from long-standing local configuration, not Exim
defaulting to enforcing this:
acl_check_mail:
deny message = 503 Bad sequence of commands - must send HELO/EHLO first
condition = ${if !def:sender_helo_name}
If anyone wants to protect against stupidity: I've been using that guard
for "longer than the five years that the current mail-server is running"
and I'm not going diving through git history to find when it was
introduced to my older server.
To the best of my knowledge, that has never blocked legitimate mail.
Everyone does EHLO after STARTTLS.
Exim drops pre-TLS sender_helo_name after negotiating TLS. This is
required by RFC 3207 (section 4.2) but not explicitly mentioned in the
Exim Spec, AFAICT.
-Phil
