> In particular RFC-1123 specifies that only MAIL, RCPT, DATA, RSET,
> VRFY, NOOP, and QUIT be mandatory in response to HELO.
Yes, but on the other hand we try to be compatible with the standard
qmail-smtpd, which recognizes (but has no further support for) the
AUTH-Command both when the client used HELO as well as EHLO. The various
patches for qmail which add the SMTP AUTH functionality hook in there, and
therefore support SMTP AUTH with both EHLO and HELO. Postfix too recognizes
the AUTH-Command after HELO.
Yes, the client _is_ broken. But there is another (unwritten?) rule stating
that one should be robust and tolerant in what to accept. There is NO
technical reason to deny SMTP AUTH just because the client used HELO instead
of EHLO. Adding support for this does break NOTHING but increases
compability.
> And even if it were accepted, it should never be implemented by deleting
> perfectly legitimate code; it could be a config option if at all.
I just wanted to show the code lines in question. However the original code
is wrong anyways, because there is no need to disable the SMTP AUTH at two
positions: First SMTP.pm disables the AUTH-Command for Clients which used
HELO, but second the Auth.pm also check for HELO/EHLO and disable again. The
second check is obsolete.
-kju
--
It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
