Note: just before sending this I went back to read the rest of
the thread, wherein I see that you're using a pre-2.0 Postfix. Some
of my advice below is thereby not relevant to this host, namely, the
suggestion to use newer syntax and the newer restriction,
reject_unknown_reverse_client_hostname. IMO that would be worth an
upgrade.
On Sun, Apr 18, 2010 at 02:19:15PM -0400, Alex wrote re:
reject_unknown_client_hostname :
> Is it common practice to have that restriction in a production
> environment?
Recently I had a failure of reverse DNS at my colo provider. It went
some days before I was aware of the issue (it's a small site and I
don't monitor the logs.)
When I discovered the issue, I found a lot of mail in the queue, but
few outright 5xx rejections had been done. Temporary rejections were
occurring from numerous large providers, including Gmail, AOL, Yahoo,
and Comcast.
I temporarily shut down outbound mail and set up a relayhost while
the provider fixed the rDNS issues (my PTR query was returning
NXDOMAIN during this time.)
Note, from the documentation suggested for you, that there are
different conditions which trigger reject_unknown_client_hostname.
Mine was lack of PTR, which also triggers the less aggressive
reject_unknown_reverse_client_hostname restriction. This is fairly
common, and IMO, a pretty likely spam sign. Given my experience, I
think it is time to use reject_unknown_reverse_client_hostname. At
least you know you're not alone in enforcing that policy.
Another condition is when there is a PTR, but the name given does not
resolve. This, too, is not unusual. But IMO it's probably less likely
a spam sign. You might block a few sites where the understanding of
DNS and mail issues is not so strong.
A third condition is when the PTR name resolves to a different IP
address. This is arguably the "worst" case, because it could mean
that a spammer or scammer/spammer is trying to spoof a legitimate
domain. IRL this is not usually the case; more likely just another
poorly managed site.
Most spam is going to come from malware-infected Windows machines or
other compromised hosts being used as a zombie. There are many useful
strategies in dealing with those, including Spamhaus Zen and
reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname
is also very effective, as I think some ISPs might deliberately not
provide reverse DNS for their dynamic ranges.
Most of the rest of it is going to come from large "snowshoe" ranges.
These networks will typically have perfect FCrDNS for every IP
address.
> It appears to be the third case here, that the name->address mapping
> does not match the client IP address. Could this be from a legitimate
> cause, or typically intentionally to be evasive?
>
> Could it be found in a legitimate dynamic environment, such as at an ISP?
>
> Is there a way to log these specific failures so I can get a better
> idea of under what circumstances they occur in my environment?
>
> I'm currently rejecting the following, in this order:
>
> reject_non_fqdn_sender,
Reasonable, not going to block much; not likely to block any spam,
but the mail it blocks is mail you should not accept anyway.
> reject_non_fqdn_recipient,
Harmless but useless.
> reject_unknown_sender_domain,
ditto reject_non_fqdn_sender
> reject_unknown_recipient_domain,
Harmless but useless. Who is giving you invalid recipients at this
point?
> reject_unauth_pipelining,
Might catch some zombies.
> reject_invalid_hostname,
Old syntax, ditto reject_non_fqdn_sender except might also catch a
zombie here and there.
> reject_non_fqdn_hostname,
Old syntax, very effective against zombies, safe and reasonable.
> reject_unauth_destination,
(Necessary, no comment needed.)
> reject_maps_rbl,
Old syntax, could be good or could be disastrous. Switch to the "new"
syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name".
At this point I'm only using zen.spamhaus.org, but I might be adding
spameatingmonkey. Most important advice regarding DNSBLs is to be
familiar with their policies and aware of their status. Given the
dominance of ancient syntax in your restrictions, I wouldn't be
surprised to see some dead lists among your maps_rbl_domains. :)
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
