Wrong HELO
I’m testing out policyd-weight, a spamfilter that looks at blocklists and HELO compared with IP number.
I strained my logs for possibly legit mails that would have been rejected had I used default setting: 1. It’s fairly easy since we’re in Norway, and I can just grep for .no and let it go at that at first pass.
Anyway, I was surprised to find quite a few legitimate senders with incorrectly configured HELO. Even mailservers that had been configured to have only the domain in the HELO. I was astounded! There are quite a lot of clueless admins out there!
After a second pass at this, I found even more incorrectly configured HELO’s. And this even from some pretty prestigious companies! Looks like a common plague…
January 23rd, 2006 at 1:49 pm
What are “incorrectly configured HELO” strings? In my experience with SA, you can’t assume that a HELO string will even share a TLD with any of the other attributes of the mail session so far (remote RDNS, MAIL FROM, remote IP, RCPT TO, header “From:” etc.). I’d expect a high false positive rate if that’s the test.
It’s not really a matter of “incorrectly configured”, it’s a matter of “unrealistic expectations”
January 27th, 2006 at 12:01 am
Yeah, there’s a surprising amount of junk in EHLOs, especially considering that it’s clearly defined in the standards, and relatively easy to get right (multihomed servers, split-horizon DNS, and NATs being the big edge cases). Fortunately, at least some of the junk is virtually 100% spam and can be blocked using check_helo_access (preferably with a generic error message — some spammers are catching on, why help the rest?).
My personal favorite is a financial services company mail server that HELOs as a string of 72 ‘#’ characters. That almost has to be a firewall ‘fixing’ the HELO.