Lazy postmasters in Norway
An explanation of HELO configuration for admins.
I just tested this postfix setting:
reject_unknown_hostname
If you implement that setting under smtpd_helo_restrictions in main.cf in postfix, it checks the HELO of all sending servers, and checks if the HELO actually resolves (to the IP number that again resolves to the HELO, by checking DNS). If it doesn’t, the mail is rejected.
It’s wonderful, because it rejects a lot of spam. But there’s a problem…
Lots of legitimate mail was rejected. Why? Because Norwegian postmasters are either lazy or incompetent.
OK, so they’re not the only ones who have incorrectly configured servers, but I’m in Norway, so chances are I’ll see more of those.
Please, please, please, postmaster: Check that your mailservers have the correct HELO.
It’s a common rookie mistake, but for a production server, you really NEED to make sure it’s right!
If you’re administering a mail server and don’t have a clue what I’m talking about, then get serious about your job and learn!
——-
You could get away with using this instead:
reject_non_fqdn_hostname
It will reject mail from HELO’s that don’t look like IP numbers or ending in a TLD. It won’t check if the address is valid. You’ll still reject legitimate mail with this setting, for the same reason as above: Lazy or clueless admins. But at least the casualties won’t be quite as many.
Most of the mails that would have been rejected by this one, is also rejected by policyd-weight.
Today I’ve seen HELO’s from (probably) legitimate servers, on these formats (some of these are the actual HELO’s or very lightly munged):
EXCHANGE2K3.domain.int
tplist.adm.adm
z50v002.domain.local
February 10th, 2006 at 10:01 pm
I don’t think reject_uknown_hostname checks the IP. It merely requires the given name to resolve (according to postconf(5), anyway).
If you’re not blocking hosts without matching reverse DNS outright, this might not be a bad check to apply to them. If there’s no reverse, make sure the HELO host resolves to the client IP. If that fails, reject the connection with:
450 cannot find your hostname — and we really tried, too
:-)
Even the relatively conservative reject_invalid_hostname will catch a lot of mail sent through PIXes…
There are very few HELO checks you can do that don’t have false positives. About the best you can do is choose some with minimal false positives, put them after a check_recipient_access call allowing mail to postmaster, etc., and hope that the few legitimate senders will either fix their problem or contact you to be whitelisted…
February 11th, 2006 at 9:40 am
I would also like to reject based on invalid/bogus/wrong/whatever HELOs, since it would make further filtering steps a lot easier (and it would cut out a good proportion of rDNS-less areas of China…).
However, when I did exactly that (ie reject based on no-good HELO), I was confronted with a ton of false positives - otherwise perfectly legit mail servers that either had no rDNS, or that HELOed with an name that only made sense behind some firewall/router, or unqualified hostnames…
Additionally, DNS problems (timeouts etc) may impact the whole setup as well.
The trade-off between efficiency, accuracy, reliability and administration effort was just not right for my systems.
February 11th, 2006 at 9:53 am
I concur on foregoing reject_unknown_hostname for now (that’s the one that checks reverse DNS).
And I expect legit mail to be rejected with reject_non_fqdn_hostname. But the check is not expensive in terms of time. And it cuts down on the number of lookups done with policyd-weight. While I was testing (using warn_if_reject in front of the restriction), I found that most of the mail that would have been rejected with the reject_non_fqdn_hostname check was in fact rejected by policyd-weight.
And servers that use non-qualified domains as HELO’s really need to grow up.
February 16th, 2006 at 1:27 am
The interessting thing on all that HELO checking is, that it often produces false positives. Thus policyd-weight does _not only_ check the HELO vs IP but also the envelope sender domain:
HELO_(SUB)_DOMAIN == Client IP/16/24/32 ||
SENDER_(SUB)_DOMAIN == Client IP/16/24/32
then: HELO OK
else: HELO NOT OK, check this with reverse records, and so on;
additionally it weights it with RBL/RHSBL results
We say HELO (NOT OK|OK) here because it is a little bit hard to differenciate scriptwise between HELO and sender envelope for “reporting”.
The reason for this check is, that we could do this also with SPF, but SPF breaks forwarding, policyd-weight doesn’t as either the HELO _should_ match, and as a backup we check whether the sender domain matches. As a very last resort we also check the reverse records.
Another reason for policyd-weight was, that reject_unknown_*, reject_rbl_client and others produced way too much false positives as postfix restrictions are on a 1|0 base. Either ok, or not ok.
February 16th, 2006 at 4:26 am
I currently use reject_non_fqdn_hostname and policyd-weight.
There are a few false positives with reject_non_fqdn_hostname, but not more than I can live with. I usually notify the senders I and my customers want to receive mail from.
April 6th, 2006 at 7:48 pm
I stumbled across this article on google while searching for the reason my mailqueue was filling up from AOL sends. the HELO check is a good one, and I’m willing to get a bit BOFH’ish if it means reducing my spam load. I cant use the “nuclear option” of a mass-block against china, as we (the company i work for) do business in china. Now i just need to wait on my lazy NS hosting providor to map me a RDNS :\.
April 7th, 2006 at 1:24 am
Note to readers who aren’t up on admin talk:
BOFH means Bastard Operator From Hell.
There’s a website someone created with lots of creative excuses for admin personnel to use in order to not fix computer problems. And a few stories of the first BOFH and how he tormented his users. It’s belly laughs guaranteed for admins, but I wouldn’t recommend emulating that stuff.
Though I must admit insisting on at least a fully qualified hostname makes some people angry. And I rarely get any thanks for notifying fellow admins that they don’t know how to do their jobs…