Gerben Wierda:
> What is the correct way to clean out (make a fresh start) with the postscreen
> cache?
>
> Can I clean the postscreen cache while postfix is running?
Delete the file, then "postfix reload".
Wietse
On 2022-03-05 15:04, Gerben Wierda wrote:
What is the correct way to clean out (make a fresh start) with the
postscreen cache?
Can I clean the postscreen cache while postfix is running?
cache file only holds data in _TTL time, where auto expire does all the
self maintaince
you should not
What is the correct way to clean out (make a fresh start) with the postscreen
cache?
Can I clean the postscreen cache while postfix is running?
Thanks,
Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
R&A IT Strategy <https://ea.rna.nl/> (main site)
Book: C
t the number of connections postfix can service.
> btree is suggested because it's fast and supports the features needed.
> I don't use lmdb, so I can't really answer if it's suitable for the
> postscreen cache.
IIUC, lmdb is based on / derived from btree.
The
On 4/6/2016 10:38 AM, jaso...@mail-central.com wrote:
> In my logs I see postscreen cache cleanups
>
> postfix/postscreen[18826]: cache
> btree:/var/lib/postfix/postscreen_cache full cleanup: retained=224 dropped=12
> entries
>
> It looks like it's happening bec
In my logs I see postscreen cache cleanups
postfix/postscreen[18826]: cache
btree:/var/lib/postfix/postscreen_cache full cleanup: retained=224 dropped=12
entries
It looks like it's happening because they're 'full' at the time.
Under "CACHE CONTROLS"
d to an RBL, will postscreen block it? Or does
> the postscreen cache allow it through?
The postscreen_dnsbl_sites "pass" status, like other postscreen tests,
has an expiration time.
It depends on Postfix version:
Postfix < 3.1:
postscreen_dnsbl_ttl, ignores DNS TTLs
Postfix
> Why do you care?
Because I'm actually trying to understand how things works and are best used.
On Thu, Mar 31, 2016, at 04:57 PM, Wietse Venema wrote:
> However the dnsblog client is stateless; it relies on caching in your local
> DNS resolver.
Okay, that's the part I missed.
Thanks.
Jason
ore postscreen will log a "PASS".
Wietse
If a spamming IP is at first not listed on an RBL and gets a postscreen
PASS, but is later added to an RBL, will postscreen block it? Or does
the postscreen cache allow it through?
> > Mar 29 18:25:28 mail01 postfix/dnsblog[24238]: addr 79.13.92.233 listed
> > by domain zen.spamhaus.org as 127.0.0.10
> > Mar 29 18:25:28 mail01 postfix/dnsblog[24240]: addr 79.13.92.233 listed
> > by domain dnsbl.sorbs.net as 127.0.0.10
...
> > Mar 29 18:26:02 mail01 postfix/dnsbl
subject to the TTL set by the DNSBL
operator **.
>
> My understanding was that postscreen, once it catches a bad actor, it caches
> the result so subsequent attempts get a response from the cache.
IIRC postscreen caches PASS results only.
>
> Is what I'm seeing here, the 2n
at postscreen, once it catches a bad actor, it caches
the result so subsequent attempts get a response from the cache.
Is what I'm seeing here, the 2nd set of dnsblog results, actually from the
postscreen cache? Or am I actually seeing the check run (unnecessarily) twice?
If it's the
brad.chand...@mbchandler.net:
> On 2015-06-03 10:49 am, wie...@porcupine.org wrote:
> > brad.chand...@mbchandler.net:
> >> How does the memcache interact with the
> >> proxy:btree:/var/lib/postfix/postscreen_cache?
> >
> > It happens in the Postfix memcache client.
> >
> > When you specify a back
On 2015-06-03 10:49 am, wie...@porcupine.org wrote:
brad.chand...@mbchandler.net:
How does the memcache interact with the
proxy:btree:/var/lib/postfix/postscreen_cache?
It happens in the Postfix memcache client.
When you specify a backup store in the Postfix memcache client
configuration file
brad.chand...@mbchandler.net:
> How does the memcache interact with the
> proxy:btree:/var/lib/postfix/postscreen_cache?
It happens in the Postfix memcache client.
When you specify a backup store in the Postfix memcache client
configuration file, the Postfix memcache client will update
both the
I've read over the how-to, man page, and all of the postscreen stuff as
I could find in the mailing list archives, but I'm still unsure about
something. How does the memcache interact with the
proxy:btree:/var/lib/postfix/postscreen_cache? Which one does postscreen
use to determine if a connect
hodor:
> Hello,
>
> I've got 3 machines running postfix 2.11-20131001. Incoming connections are
> balanced via haproxy (and postscreen_upstream_proxy_protocol=haproxy). Right
> now each postfix instance has its own postscreen_cache_map. Everything works
> fine.
>
> I thought I could share the cac
f any leftovers.
Would something like this work? And would the postscreen cache logic remain
intact?
I have read [1] and [2], but I didn't see it neither mention nor forbid such
setup. Did I overlook something?
BTW, in case of non-persistent memcache ([1], section "Sharing the temporary
whitel
18 matches
Mail list logo
