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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/