Postfix filter: HELO
For the admins here:
One way to cut down on spam considerably, is to add a HELO filter to your mail server. It’s easy to implement on Postfix, which is what I use.
Here’s the recipe I used:
Blocking spammers with Postfix HELO controls
A little gotcha is that your main.cf may not like like his. Both run on lines and one variable per line works, in the same file.
I add both the IP numbers of the mailservers, and the domain names it houses. The server will only relay mail to outside domains if the sender is in “my networks”, so the only false positives I’ve seen so far was when someone decided to route mail through my server and gave me the wrong IP number (didn’t consider that they had a firewall in front of their Exchange server) to include in “my networks”.
This filter is wonderful. It blocks a lot of mail each day. And when I pair it with policyd-weight and Spamassassin, as well as recipient maps, I get a pretty good end result.
The good thing about the HELO filter and policyd-weight, is that it reduces spam to existing users. I have users that receive up to 300 mails per day, and a good percentage is spam. So cutting down on that number is a very good thing for them. It’s noticeable for the end users.
So, why is a HELO filter a good thing?
Many spammers use YOUR IP number or domain as THEIR HELO. I assume some mail servers are tricked somehow. Maybe the server will think it’s a local mail, and bypass the spam check? I don’t know. I just know many spammers use that trick. And I suppose few servers have filters for it, so it’s not worth their while to figure out if you reject mail based on it. Which means those filters will be effective for a while longer, until a certain percentage of the world’s mail servers implement such filters.
The other consideration, is that much of the spam I receive is from zombied boxes. So the virus would have to figure out the correct helo for each IP number, in order to get mail through. And some filters will reject or penalize mail with HELO that appear to be from a dynamic IP range. And numeric HELO will also be penalized by some filters.
It isn’t easy being a mail spammer. They have to figure out lots of stuff in order to get their spam through…
February 7th, 2006 at 12:21 am
I’m sure that you grepped through lots and lots of ham mail before you turned on the postfix option. No broken clients that will cause false positives with that?
February 7th, 2006 at 6:20 am
Clients do not normally send out HELO’s. That’s done by servers, when greeting another server. There might be an app somewhere that thinks it’s a server, of course.
There are lots of broken mailservers out there. They send HELO’s that do not correspond with their IP number. It’s really easy to screw up there (if you’re an admin, or run your own home mail server). If you set policyd-weight to kick out mails that have a rate of +1, then you’ll throw away lots of legitimate mail. If you set it more conservatively, say around +4, you should be relatively safe (but you’ll admit more spam that way).
But the HELO check to kick out mails that have forged YOUR domains or IP is different. You’ll whitelist anyone coming from your IP numbers, or IP numbers of customers who are allowed to relay mail through your server. The HELO check doesn’t apply to them. So the only way you could kick out legitimate mail would be if you failed to include an IP address in “my networks”. An administrator would have to mangle a server pretty severely for a false positive to ever happen. The only way I could see that happening is if you move a server from one network to another, and then forget to change the HELO setting.
February 7th, 2006 at 7:38 am
There is another way the HELO check could reject legitimate mail.
If you have a collection of domains on your server. Then a customer silently moves the domain from your server (could happen if DNS is handled by someone else). Mail is now handled by another server, that may or may not have a HELO reflecting that domain name. When mail arrives to one of your customers, FROM that domain, mail may be rejected, until you clean up your list of HELO restrictions.
February 7th, 2006 at 9:35 am
Also be on the lookout for subdomains - something.domain.com matches a HELO rule for domain.com.
That one bit me in the butt the first day I implemented the filter. I hadn’t noticed that one of the domains I had was a subdomain, and had blindly included it in the filter. Which meant it rejected mail from that whole domain (it has LOTS of subdomains).
February 9th, 2006 at 9:13 pm
This HELO check is a very good one. You may be able to find other HELOs to block by logging HELO values and seeing which ones are used by multiple IPs. In my case, the top 20 or so are mostly variations on my IPs/domain names, but there are a few interesting ones there used by trojans, spamware, and viruses. A little data mining can go a long way here.
For extra protection, consider putting these into a local blacklist, at least temporarily. I see a lot of hosts HELO as me, then come back with another unblocked HELO value. The second spam will get through…
There’s also the FAKE_OB_HELO rule in spamassassin, which supplies some HELO values that can be rejected safely (i.e. no host will legitimately HELO with these values).
Regarding the subdomain thing, did you wind up removing smtpd_access maps from the parent_domain_matches_subdomain config, or did you put “.example.com DUNNO” entries in the map? (I’m planning a migration from mangled qmail to postfix at some point, and this was one of the glitches I anticipated…)
February 10th, 2006 at 4:32 am
I ended up removing that troublesome subdomain. It no longer pointed to our server, though it did at one time.
But I would have removed it from the HELO access map, if we’d still been serving that subdomain. No sense in complicating things when you don’t have to.
We have several other subdomains, but in those cases, the whole domain points to us, so the subdomains are just pointing to different places in our transport map.
I would have loved to put in a block for these:
aol.com
concentric.net
Problem is, that the helo access map would also match imo-d20.mx.aol.com or similar (the real mailservers at aol).
If that wasn’t so, we could have blocked a good deal more spam.
February 11th, 2006 at 1:29 am
That parent_domain_matches_subdomain default does get annoying doesn’t it?
There doesn’t appear to be a way to say “this domain, but no subdomains” with it on, which makes a lot of good HELO checks difficult to do. Bummer. At this point, you’re left with turning off the parent_domain_matches_subdomain feature, or writing a policy server to do what the access maps should :-/