On 3 Oct 2012, at 14:46, Noel Jones wrote:
On 10/3/2012 1:15 PM, Bill Cole wrote:
I recently updated a Postfix system from 2.4 to 2.9 and I have found
what I believe is a change in behavior for
reject_unknown_sender_domain which is confusing. In the past, an
effective means of dealing with some classes of persistent spammers
was to tell the local DNS resolver (BIND 9) to "blackhole" the
authoritative nameservers of spammers who cycled rapidly through
changes in nearly every other easily detected aspect of their spam.
In conjunction with reject_unknown_sender_domain, this rejected a
lot of spam cheaply for a while but in recent years I've not paid
much attention to it because there are fewer spammers using their
own fixed IP space for DNS. Last week I started getting spam again
that fit this tactic well, so for the first time in years I added to
my DNS blackhole list. And the subsequent spam was not rejected.
Upon investigation I have determined that if a domain definitively
has no A or MX records (i.e. DNS answers with NXDOMAIN or NOERR with
zero answers) then Postfix rejects the mail at RCPT. However, if DNS
queries garner SERVFAIL responses, as happens when authorities are
blackholed, Postfix is permitting delivery.
This is not normal postfix behavior, and suggests either your DNS is
giving some sort of unintended answer, or the client is getting an
OK/permit somewhere prior to the unknown domain check.
It certainly seems abnormal, especially since it is dependent on whether
DNS answers with NXDOMAIN or SERVFAIL. Since rejection works as intended
when a sender in a definitively bogus domain is given, it is clear that
reject_unknown_sender_domain is being applied rather than bypassed.
The key seems to be in the unknown_address_tempfail_action handling
cited by Dr. Venema, which came with Postfix 2.6. The docs say that
Postfix by default postpones deferral on temporary DNS failures while
looking for reasons to reject outright.
This is definitely not
what I want. This may be related to the addition in version 2.6 of
unknown_address_tempfail_action, but it seems to me based on the
postconf manpage that since this defaults via reject_tempfail_action
to "defer_if_permit" (and I have confirmed that this is so on this
system) that Postfix should *at best* be sending a 4xx reply to RCPT
rather than accepting mail sent from these intentionally
unresolvable domains.
Postfix has always deferred upon DNS failure, and that behavior has
not changed. The *_tempfail_action defaults duplicate previous
behavior.
I would like to believe that to be accurate, but the evidence I have
implies otherwise. I am sure the ancestor of the current rig was not
accepting the targeted spam as intended at some point using Postfix
2.4.5 and that the config changes since I last paid attention to this
particular tactic have been minimal and almost entirely due to the
2.4.5->2.9.3 update. The reject_tempfail_action documentation says that
it came with 2.6, so if prior behavior was to defer immediately rather
than the "defer_if_permit" strategy, it would partially explain what I
am seeing. However, nothing I can find documented should be redeeming
the transaction from eventual deferral, and that is what is puzzling me.
At any rate, the tool to reject spammer-haven DNS is a
check_sender_ns_access map.
http://www.postfix.org/postconf.5.html#check_sender_ns_access
THANK YOU!
That should do precisely what I need and eliminates the need to poke
around in named.conf and ponder how Postfix is interacting with BIND.
The only remaining mystery is how I managed to not notice its existence
before, but that's not a pressing issue.
