Best practices link for postscreen

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practices link for postscreen

Durga Prasad Malyala
Hi
Does anyone have best practices link for postscreen implementation.

Thank you 
DP
Reply | Threaded
Open this post in threaded view
|

Re: Best practices link for postscreen

Nicky Thomassen
Sat, 22 Jun 2019 12:48:36 +0530 skrev Durga Prasad Malyala
<[hidden email]>:

> Hi
> Does anyone have best practices link for postscreen implementation.
>
> Thank you
> DP

The how-to document might be a good start

https://postfix.aptget.dk/POSTSCREEN_README.html

The best,
Reply | Threaded
Open this post in threaded view
|

Re: Best practices link for postscreen

Lefteris Tsintjelis
In reply to this post by Durga Prasad Malyala
On 22/6/2019 10:18, Durga Prasad Malyala wrote:
> Hi
> Does anyone have best practices link for postscreen implementation.

http://rob0.nodns4.us/postscreen.html
http://www.postfix.org/POSTSCREEN_README.html

It is a start but I would also like to see more examples and
recommendations in more advanced setups like multiple MXs sharing the
same cache map for example, together with additional IPs in multiple
servers to permanently block invalid attempts.

Lefteris
Reply | Threaded
Open this post in threaded view
|

Re: Best practices link for postscreen

Wietse Venema
Lefteris Tsintjelis:

> On 22/6/2019 10:18, Durga Prasad Malyala wrote:
> > Hi
> > Does anyone have best practices link for postscreen implementation.
>
> http://rob0.nodns4.us/postscreen.html
> http://www.postfix.org/POSTSCREEN_README.html
>
> It is a start but I would also like to see more examples and
> recommendations in more advanced setups like multiple MXs sharing the
> same cache map for example, together with additional IPs in multiple
> servers to permanently block invalid attempts.

Sharing a non-persistent cache (memcache) is the only option because
it can respond with low latency both for old and new queries. But
that of course limits the cache size.

Sharing a persistent cache is not an option because that requires
a DBMS with milliscond query latency (with a query latency of 50ms,
one postscreen instance would handle at most 20 clients per second).

You could try to combine a shared memcache and a shared persistent
cache, but that will only improve the best case where most connections
come from a limited set of clients. The memcache will not improve
the worst case, for example a backscatter scenario where most clients
are clients new. In that case the postscreen performance would be
exactly as bad as in the previous paragraph.

With Internet services, it would be a mistake to optimize the best
case only; especially if it makes worst-case behavior worse.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Best practices link for postscreen

Lefteris Tsintjelis
On 22/6/2019 17:36, Wietse Venema wrote:
>
> Sharing a non-persistent cache (memcache) is the only option because
> it can respond with low latency both for old and new queries. But
> that of course limits the cache size.
>
> Sharing a persistent cache is not an option because that requires
> a DBMS with milliscond query latency (with a query latency of 50ms,
> one postscreen instance would handle at most 20 clients per second).

DBMS would very possibly be slow for large backscatter scenarios.

> You could try to combine a shared memcache and a shared persistent
> cache, but that will only improve the best case where most connections
> come from a limited set of clients. The memcache will not improve
> the worst case, for example a backscatter scenario where most clients
> are clients new. In that case the postscreen performance would be
> exactly as bad as in the previous paragraph.

Wouldn't the worst case scenario with many new clients improve also by
reducing latency though? I suspect this has a lot to do with DNSBL
response time(???) or maybe there are other important delay factors
besides that? What I have in mind is a local only postscreen DNSBL and
the 50ms can easily go down to a millisecond.

> With Internet services, it would be a mistake to optimize the best
> case only; especially if it makes worst-case behavior worse.

Lefteris
Reply | Threaded
Open this post in threaded view
|

Re: Best practices link for postscreen

Wietse Venema
Lefteris Tsintjelis:

> On 22/6/2019 17:36, Wietse Venema wrote:
> >
> > Sharing a non-persistent cache (memcache) is the only option because
> > it can respond with low latency both for old and new queries. But
> > that of course limits the cache size.
> >
> > Sharing a persistent cache is not an option because that requires
> > a DBMS with milliscond query latency (with a query latency of 50ms,
> > one postscreen instance would handle at most 20 clients per second).
>
> DBMS would very possibly be slow for large backscatter scenarios.
>
> > You could try to combine a shared memcache and a shared persistent
> > cache, but that will only improve the best case where most connections
> > come from a limited set of clients. The memcache will not improve
> > the worst case, for example a backscatter scenario where most clients
> > are clients new. In that case the postscreen performance would be
> > exactly as bad as in the previous paragraph.
>
> Wouldn't the worst case scenario with many new clients improve also by
> reducing latency though? I suspect this has a lot to do with DNSBL
> response time(???) or maybe there are other important delay factors
> besides that? What I have in mind is a local only postscreen DNSBL and
> the 50ms can easily go down to a millisecond.

FYI, postscreen queries its cache BEFORE it decides if DNSXL checks
are needed. Therefore you can't speed up postscreen cache queries
with faster DNS.

        Wietse