On Saturday March 5th, we implemented some HELO/EHLO checking for
mail.msu.edu's SMTP connection handling.
When a client makes a connection to an SMTP server, that client is
required by the RFC to identify itself. This is done in the form of
either:
HELO my.hostname
or,
EHLO my.hostname
where my.hostname is the hostname of their computer, so for example if
I were to send mail from bender.cl.msu.edu to [log in to unmask], the start
of my transaction would go like this:
<mail.msu.edu> Connected to mail.msu.edu.
<mail.msu.edu> Escape character is '^]'.
<mail.msu.edu> 220 sys19.mail.msu.edu ESMTP Exim 4.44 Wed, 09 Mar 2005 08:06:29 -0500
<bender> EHLO bender.cl.msu.edu
<mail.msu.edu> 250-sys19.mail.msu.edu Hello bender.cl.msu.edu [35.8.1.192]
<mail.msu.edu> 250-SIZE 52428800
<mail.msu.edu> 250-PIPELINING
<mail.msu.edu> 250-AUTH PLAIN LOGIN
<mail.msu.edu> 250-STARTTLS
<mail.msu.edu> 250 HELP
and then you continue with your SMTP negotiation. What most virus'
and spammers do, is send a faulty EHLO or HELO line (or no HELO line
at all!). Sometimes they try to identify themselves as the actual
server they're trying to connect to, sometimes they identify
themselves as localhost, etc etc. So, what we did was put some rules
in the exim configuration file to deny some of these spams and viruses
before we have to actually scan them. This has taken quite a load off
of our servers. Yesterday for example, we rejected ~260k delivery
attempts via ~1.5k independent connections.
Here is a failed negotiation, attempting to use the server's own name:
<mail.msu.edu> Connected to mail.msu.edu.
<mail.msu.edu> Escape character is '^]'.
<mail.msu.edu> 220 sys28.mail.msu.edu ESMTP Exim 4.44 Wed, 09 Mar 2005 08:38:37 -0500
<bender> ehlo sys28.mail.msu.edu
<mail.msu.edu> 550 Invalid HELO. HELO/EHLO with my domain name.
The problems we are seeing is, some older clients (and some newer
ones, unfortunately) are sending invalid HELO/EHLO responses. These
include:
* MS Outlook (at least some versions send hostname with dots
stripped out, e.g. benderclmsuedu)
* Pegasus (old client, used (afaik) almost exclusively by the physics
department, does the same thing as outlook, sends hostname w/o dots)
* Eudora (different versions appear to act differently, but try
sending their hostname in the form of
machinename.server.they.connect.to,
e.g. nibbler.sys19.mail.msu.edu).
We have also had problems with some versions of Apple's Mail.app, and
Netscape 7.1.
In an effort to deal with these broken client responses, we have
slackened up the rules greatly. We now accept a variety of clearly
illegal ehlo names. However, we are still doing *some* checking.
Based on some analysis we have done, it appears that this all may root
back to the client not having their hostname set, or not having their
hostnames set correctly.
Greater than 90% of the hosts we blocked had IP addresses which did
not resolve via DNS. This could be the cause of some clients not
knowing what to do, and thus spoofing their own hostname. If you guys
are noticing any problems, or having users complain, if you could
collect some data on that, maybe we can setup a solid fix for clients
on their own end.
Q: Can we turn these EHLO rules off?
A: Easily.
Q: Why is it on at all then?
A: Even with our reduced ruleset to allow the junk from the above
clients, we are still blocking ~260k virus/spams per day
without the cost of scanning them, or delivering them. We are
trying to do better about strictly following RFCs.
If you google for "block on helo" you'll find some more links that
describe what's happening.
If you have questions please feel free to e-mail me directly, or keep
it on list if you feel it is appropriate. I want the greater MSU
community to know what's going on, and I'd like to get some feedback
as well.
./matt
--
m. kolb <[log in to unmask]>
