On Thu, Aug 28, 2003 at 01:36:20PM +0100, Giuliano Gavazzi wrote:
> At 15:26 -0400 2003/08/27, Greg A. Woods wrote:
> >[ On Wednesday, August 27, 2003 at 12:18:16 (-0400), Wakko Warner wrote: ]
> >> Subject: Re: [Exim] exim HELO ack
> >>
> >> If you check the helo string in the helo don't. Put it in the MAIL or
> >> RCPT
> >> acl.
> >
> >There's no reason to do that any more -- the mailers that ignored 5xx
> >errors on HELO have effectively disappeared for all intents and purposes.
>
> only problem is that spammers use software which can ignore HELO/EHLO
> errors, and last time I checked (IIRW) exim will accept the delivery
> even after a failed HELO (at least for illegal chars).
> If this is still true one must, also or only, reject at RCPT or DATA time.
I don't know if this used to be true but doesn't appear to be the case
any more:
2003-08-28 03:59:32 rejected HELO from mail.cuno.com [12.40.254.66]:
syntactically invalid argument(s): cuno_mail_usa.cuno.com
this appears to be implemented in src/smtp_in.c:
/*************************************************
* Check HELO line and set sender_helo_name *
*************************************************/
/* Check the format of a HELO line. The data for HELO/EHLO is supposed to be
the domain name of the sending host, or an ip literal in square brackets. The
arrgument is placed in sender_helo_name, which is in malloc store, because it
must persist over multiple incoming messages. If helo_accept_junk is set, this
host is permitted to send any old junk (needed for some broken hosts).
Otherwise, helo_allow_chars can be used for rogue characters in general
(typically people want to let in underscores).
Argument:
s the data portion of the line (already past any white space)
Returns: TRUE or FALSE
*/
--
Jez
http://www.munk.nu/
