I had not been able to send mail since this change. My Outgoing Server
(SMTP) Settings were set to Port 25 (TLS). Changing to Port 465 (SSL)
fixed this. This is contrary to the instructions currently at
http://techbase.msu.edu/viewpathfinder.asp?id=117
-Pete
m. kolb wrote:
> 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]>
|
