Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Listaccount (lst_hoe01kwsoft.de)
Date: Fri Oct 26 2007 - 08:17:23 CDT
Zitat von Wietse Venema <wietseporcupine.org>:
> Zoltan Balogh:
>> Hello Everybody,
>> on my Postfix I am using both Graylisting (using a Policy daemon) and
>> RBL checks. This is a snap from my config:
>> smtpd_recipient_restrictions =
>> check_policy_service inet:127.0.0.1:10031,
>> reject_rbl_client bl.spamcop.net,
>> reject_rbl_client cbl.abuseat.org,
>> reject_rbl_client zen.spamhaus.org
>> My concern is that even when an email is graylisted (i.e.
>> "graylist=new"), it is passed to RBL checks. I assume this generates
>> many unnecessary DNS requests = unnecessary server load. What should I
>> do to avoid RBL checks upon graylisted emails?
> See: http://www.postfix.org/postconf.5.html#defer_if_permit
>> Here is an example of an RBL-blocked email already graylisted by a
>> Policy daemon:
>> Oct 24 18:37:04 ns2 postfix/smtpd: connect from
>> Oct 24 18:37:05 ns2 policyd: rcpt=163267, greylist=new,
>> host=18.104.22.168 (unknown), from=bubba-hadiapovda.com,
>> to=3dtkac-sadosomedomain.com, size=1713
>> Oct 24 18:37:05 ns2 postfix/smtpd: NOQUEUE: reject: RCPT from
>> unknown[22.214.171.124]: 554 5.7.1 Service unavailable; Client host
>> [126.96.36.199] blo
>> cked using cbl.abuseat.org; Blocked - see
>> from=<Bubba-hadiapovda.com> to=<3dtkac-sadometamax.sk> proto=ESMTP
>> Oct 24 18:37:05 ns2 postfix/smtpd: disconnect from
> This is exactly why defer_if_permit exists. It avoids the need for
> the client to come back again and then be rejected anyway.
I was under the impression that the OP is concerned the other way
around to only ask the RBLs after greylisting is passed and not submit
too many DNS queries for clients not retrying anyway.
This possible with the policy-server answering with 4xx-Code i guess..