On 4/20/2011 7:07 AM, /dev/rob0 wrote:
On Tue, Apr 19, 2011 at 11:09:07PM -0400, Alex wrote:
zen.spamhaus.org=127.0.0.10 reject_rbl_client
zen.spamhaus.org=127.0.0.11 reject_rbl_client
zen.spamhaus.org check_client_access
Why the .10 and .11 Zen rejections, when you go ahead and use any
other Zen result anyway?
I was wondering that too, but I found it on postfix.org:
1 /etc/postfix/main.cf:
2 smtpd_client_restrictions =
3 permit_mynetworks
4 reject_rbl_client zen.spamhaus.org=127.0.0.10
5 reject_rbl_client zen.spamhaus.org=127.0.0.11
6 reject_rbl_client zen.spamhaus.org
Maybe I'm just misinterpreting how that should be read, and the
reject_rbl_client lines are individual examples?
I don't think Wietse tries to put forth any specific antispam
recommendations in the documentation, so it's dangerous to read
examples like that too literally. Well, perhaps not dangerous, as
nothing was harmed by that except a few of your CPU cycles.
This example fragment is found in STRESS_README in the context
of using rbl_reply_maps to disconnect likely zombies when the
server is under stress.
Here's the link for those interested:
http://www.postfix.org/STRESS_README.html#hangup
While using this full-time is unlikely to present any
problems, it's best to understand the intent of the document
rather than cut+paste examples.
This is an "advanced" configuration and I suggest that, as
with all complex software, beginners familiarize themselves
with the basics before adding all the bells and whistles.
Also, the new postscreen feature makes much of the
STRESS_README less important, as postscreen's main intent is
to keep zombies away from the expensive smtpd processes.
(Adding bells and whistles can be a fun learning exercise too,
so don't take this as a "don't touch" sign. Be careful to
read the docs in context, three or five times.)
-- Noel Jones
