Re: [Exim] HELO syntax checking in Exim 4

Top Page
Delete this message
Reply to this message
Author: John W Baxter
Date:  
To: exim-users
Subject: Re: [Exim] HELO syntax checking in Exim 4
At 8:35 +0000 3/15/2002, Philip Hazel wrote:
>That is precisely why I made the change in Exim 4. Exim 3 treated
>underscore as a "special aberration" (there was an option to enforce
>it), and I decided that allowing only one kind of syntax error was
>silly and inconsistent. Note that this IS documented in doc/Exim4.upgrade:
>
>. helo_strict_syntax has been abolished. The default is now to enforce strict
> domain syntax for HELO/EHLO arguments. You can use helo_accept_junk_hosts if
> you want to avoid this.
>
>The checking is done by simple code, not by regexp. If you want to patch
>it, look at line 552 in smtp_in.c.
>
>I suppose I could make things easier by inventing an option which lists
>the characters you are prepared to accept, other than alphanumerics.


A note: Exim 3.32, if the remote host ignores the 501 error and presses on
with the message after sending an invalid EHLO, delivers the message with
no special notations I can find in mainlog. None are associated with the
message ID, anyhow. Do the RFCs require/allow this behavior?

The H= item in the incoming entry in the log has the invalid character
stripped out.

bash2.05 john@fox ~ % telnet mail.olympus.net smtp
Trying 198.133.237.1...
Connected to mail.olympus.net.
Escape character is '^]'.
220 olympus.net ESMTP Exim 3.32 #1 Fri, 15 Mar 2002 08:07:08 -0800
ehlo f#ox.olympus.net
501 syntactically invalid EHLO argument(s)
mail from:
etc...

Were someone to deliberately configure an invalid EHLO or HELO, that person
might well elect to ignore the resulting 501 error. So Exim may already be
stopping dumb good guys while letting smart bad guys through.

As soon as I get an Exim 4.01 built (today?) I'll kick those tires some
more. I'll start with an unpatched Exim 4.01. Then I'll work the existing
patches into our scripted build process (which begins by extracting Exim
from the tarball, copying a pre-prepared Makefile into place, etc). Then
I'll play with _ (it's going to be simple here: we allow it, or customers
whose incoming mail doesn't get handled will move to an ISP which does).

--John

--
John Baxter   jwblist@???      Port Ludlow, WA, USA