Amedeo Rinaldo:
> Il 08/04/2011 14:27, Wietse Venema ha scritto:
> > Amedeo Rinaldo:
> >> But i've (obviously) noticed an high increase in dns queries (unbound
> >> local resolver) and checking my logs i've realized that about 80% of
> >> 'defer/reject' would be done by less expensive tests (not rbl
> >> dependent). Consider that at the end of my 'accept-chain' i've postfwd2
> >
> > Why do you believe that postscreen DNSBL lookups are expensive?
> > They happen in parallel; there are no extra delays.
>
> Wietse, i don't really believe 'postscreen DNSBL lookups are expensive'
> ..i believe 'DNSBL lookups are expensive' ;) when i can reduce them
> (e.g. with the use of well tested PCRE tables.. or selective graylist).
> In the scenario when the client will be rejected by pcre or anyway
> selectively graylisted (and i obviously hope that bad client
> 'only-1_hit-graylisted' will never came back) ..you know.. no further
> dns/dnsbl checks are needed.
postscreen changes the calculation of "cost".
First, postscreen keeps a cache. When a client passes DNSBL tests
once, it won't generate any postscreen DNSBL lookups for an hour
or so (or whatever postscreen_dnsbl_ttl value is configured). When
some stranger connects, they have to wait for pregreet tests anyway,
so DNSBL lookups won't hurt performance-wise.
Second, PCRE and content inspection mechanisms consume CPU time
which increases the length of an SMTP session, meaning you can
handle less mail per unit of time. This is an issue for people
with large PCRE tables or content inspection mechanisms. CIDR
performance is comparably good, though it can be improved.
All this does not mean that postscreen solves all problems, but
the local "cost" of DNSBL lookup is negligible compared with all
the work that Postfix must do once a session is given to an SMTP
server process, especially when you get into things such as
greylisting and other plugins.
Wietse
