It seems that above message is logged by sendmail at default LogLevel (9)
when remote host tries to use invalid name in HELO/EHLO command
(e.g. name with non ascii characters) and "retries" after being rejected.

The message seems to be "confusing" for some postmasters.
Would it be possible to add some "clarification part"?
e.g. by logging reason why last HELO/EHLO was rejected ("non ascii in
HELO/EHLO parameter).

--
[pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl

Andrzej Adam Filip <anfi@onet.eu> wrote:
> It seems that above message is logged by sendmail at default LogLevel (9)
> when remote host tries to use invalid name in HELO/EHLO command
> (e.g. name with non ascii characters) and "retries" after being rejected.

Sample of an real session on wire:

200 (my greeting with 5s delay)
EHLO |
501 5.0.0 Invalid domain name
HELO |
501 5.0.0 Invalid domain name
EHLO bzq-84-108-76-149.cablep.bezeqint.net
250-

Andrzej Adam Filip wrote:
> It seems that above message is logged by sendmail at default LogLevel (9)
> when remote host tries to use invalid name in HELO/EHLO command
> (e.g. name with non ascii characters) and "retries" after being rejected.
>
> The message seems to be "confusing" for some postmasters.
> Would it be possible to add some "clarification part"?
> e.g. by logging reason why last HELO/EHLO was rejected ("non ascii in
> HELO/EHLO parameter).

I've started getting tons of those in my log files too. Googling
around, I found an article claiming that increasing log level from 9 to
10 will also log the argument of EHLO/HELO. Basically something you
were looking for. I haven't tested it myself.

The IP addresses indicate vast majority are from dialup pools. From
that, I concluded they are most likely generated by some virus/worm.
Interestingly, at the beggining most of them originated from networks
that have first byte 80-something. Maybe random number generator in
the virus is a bit biased to that range.

Looking at what goes on the wire, I see the host issuing EHLO and HELO
commands with sinlge | as argument, or | followed by some URL. "EHLO
|" or "EHLO |http://some-host/blah/blah". After it's rejected, it
attempts with HELO, and finally does "EHLO real-host". This is the
point where sendmail logs the warning. After that it is normal SMTP
conversation. Remote side issues MAIL FROM with address that looks
fake, followed by RCPT TO. At this point, my graylisting filter kicks
in and generates temporary failure. The remote side never attempts
redelivery. This indicates whatever was on the other side, wasn't
really an SMTP server, it was most likely some virus/worm or broken
mass mailer.

As long as you have antivirus installed, and virus database updated
regullary, I wouldn't worry about those lines in the log files.
Because of the graylisting, those emails never get to reach my
antivirus It would interesting if somebody without graylisting could
correlate his sendmail and antivirus logs. My guess is all of the
emails that triggered "possible SMTP attack" would end up being viruses.

Aleksandar Milivojevic wrote:
> As long as you have antivirus installed, and virus database updated
> regullary, I wouldn't worry about those lines in the log files.
> Because of the graylisting, those emails never get to reach my
> antivirus It would interesting if somebody without graylisting could
> correlate his sendmail and antivirus logs. My guess is all of the
> emails that triggered "possible SMTP attack" would end up being viruses.
>
To me it looks like normal spam.
Sometimes non existing users names are tried as a recepient.

Below is one of my last logs. I didn't raise the loglevel
to see the EHLO/HELO string that was tried.
After the DATA phase the message passed my ClamAV Milter
without being logged (that means no virus detected) and is
handed over to MimeDefang with SpamAssassin for spam
detection.

Oct 20 20:16:13 webmail sendmail[3992]: k9KIGCe8003992:
fctnnbsc16w-156034223002.nb.aliant.net [156.34.223.2]:
possible SMTP attack: command=HELO/EHLO, count=3
Oct 20 20:16:18 webmail sendmail[3992]: k9KIGCe8003992:
from=<ppratherqier@digitaldudes.com>,
size=20308, class=0, nrcpts=1,
msgid=<000b01c6f472$f8689390$6e01a8c0@fctnnbsc16w-156
Oct 20 20:16:23 webmail mimedefang.pl[3427]: k9KIGCe8003992,
Spam score: 12.481, BAYES_99,EXTRA_MPART_TYPE,HTML_MESSAGE,
RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL
Oct 20 20:16:23 webmail mimedefang.pl[3427]:
MDLOG,k9KIGCe8003992,Message bounced:,12.481,156.34.223.2,
<ppratherqier@digitaldudes.com>,<xxxxxx@rijnh.nl>, yo
Oct 20 20:16:23 webmail mimedefang.pl[3427]: filter: k9KIGCe8003992:
bounce=1
Oct 20 20:16:23 webmail mimedefang[2209]: k9KIGCe8003992:
Bouncing because filter instructed us to
Oct 20 20:16:23 webmail sendmail[3992]: k9KIGCe8003992: Milter: data,
reject=554 5.7.1 Spam rejected.
Oct 20 20:16:23 webmail sendmail[3992]: k9KIGCe8003992:
to=<xxxxxx@rijnh.nl>, delay=00:00:06, pri=50308,
stat=Spam rejected.




--
Kees Theunissen.