Comments on: Lazy postmasters in Norway

by: Administrator

Fri, 07 Apr 2006 07:24:49 +0000

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…

by: John Daemon

Fri, 07 Apr 2006 01:48:28 +0000

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 :\.

by: Administrator

Thu, 16 Feb 2006 10:26:59 +0000

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.

by: Robert Felber

Thu, 16 Feb 2006 07:27:20 +0000

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.

by: Administrator

Sat, 11 Feb 2006 15:53:18 +0000

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.

by: Matthias Leis

Sat, 11 Feb 2006 15:40:04 +0000

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.

by: Chris Mikkelson

Sat, 11 Feb 2006 04:01:06 +0000

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…