postscreen_cache_retention_time

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

postscreen_cache_retention_time

Rich Wales
I'm running Postfix 2.11.0 on Ubuntu 14.04.2 LTS.

I wonder whether the default value for postscreen_cache_retention_time
(7 days) may be too high for my situation.

I get a lot of spam despite using postscreen, and when I manually look
up the IP addresses of some of the sites that send me spam, I often find
that they are listed in DNSBL's which I have included (with high values)
in postscreen_dnsbl_sites.

I think what might be happening in some cases is that a new spam site
sends me something (which I accept because the site is new and hasn't
made it onto any DNSBLs yet) -- and soon thereafter, that site gets
picked up by Spamhaus and other DNSBLs -- but I'll continue to accept
mail from the site because I saw (and whitelisted) the site before the
DNSBLs started blacklisting it, and postscreen is going to cache that
whitelisting for several more days.

Should I consider reducing my postscreen_cache_retention_time --
possibly to a few hours?  Is that likely to have some unintended and
unwanted side effects?

I'm attaching a gzip'ed copy of the "postconf -n" output from one of my
MX servers.

Rich Wales
[hidden email]

richw-org-postconf.txt.gz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_cache_retention_time

Wietse Venema
Rich Wales:
> I'm running Postfix 2.11.0 on Ubuntu 14.04.2 LTS.
>
> I wonder whether the default value for postscreen_cache_retention_time
> (7 days) may be too high for my situation.

Making the table smaller has a negligible impact on access speed.
Garbage collection will take longer, but that is OK because this
activity is interleaved with ordinary access.

> I think what might be happening in some cases is that a new spam site
> sends me something (which I accept because the site is new and hasn't
> made it onto any DNSBLs yet) -- and soon thereafter, that site gets
> picked up by Spamhaus and other DNSBLs -- but I'll continue to accept
> mail from the site because I saw (and whitelisted) the site before the
> DNSBLs started blacklisting it, and postscreen is going to cache that
> whitelisting for several more days.

That is not entirely correct - different tests have differfent
expiration times. postscreen_cache_retention_time says what
happens with an IP address after *all* its tests expire.

> Should I consider reducing my postscreen_cache_retention_time --
> possibly to a few hours?  Is that likely to have some unintended and
> unwanted side effects?

Yes, see the postscreen_cache_retention_time manpage entry.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_cache_retention_time

furio ercolessi
In reply to this post by Rich Wales
On Thu, May 28, 2015 at 10:42:09AM -0700, Rich Wales wrote:
> [...]
> I think what might be happening in some cases is that a new spam site
> sends me something (which I accept because the site is new and hasn't
> made it onto any DNSBLs yet) -- and soon thereafter, that site gets
> picked up by Spamhaus and other DNSBLs -- but I'll continue to accept
> mail from the site because I saw (and whitelisted) the site before the
> DNSBLs started blacklisting it, and postscreen is going to cache that
> whitelisting for several more days.

Note that Spamhaus have repeatedly decreased their TTLs recently,
and are now running with a 60 seconds positive caching TTL and
a 10 seconds negative caching TTL for SBL (including CSS) and
the DBL (the domain list), that are the two databases targeting
'snowshoe' spammers.

This suggests the time scales involved nowadays.

There are spammers out there that fire from a specific IP and a
specific domain for something like 1 minute, with tremendous
intensity.  Then that IP and that domain go dark forever -
they live on the Internet for just one hot minute, burning
their reputation in a short blaze.
Of course they have plenty of IPs and plenty of domains.
You really do not want to cache negative listing information
for days or hours.

furio

Reply | Threaded
Open this post in threaded view
|

Re: postscreen_cache_retention_time

Rich Wales
In reply to this post by Wietse Venema


> That is not entirely correct - different tests have different
> expiration times. postscreen_cache_retention_time says what
> happens with an IP address after *all* its tests expire.

So, then, if I want to be able to respond more quickly to changes in an
SMTP client's DNSBL status, should I be looking at postscreen_dnsbl_ttl
instead (changing it from the default of 1 hour to something smaller)?

Rich Wales
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_cache_retention_time

Wietse Venema
Rich Wales:
> > That is not entirely correct - different tests have different
> > expiration times. postscreen_cache_retention_time says what
> > happens with an IP address after *all* its tests expire.
>
> So, then, if I want to be able to respond more quickly to changes in an
> SMTP client's DNSBL status, should I be looking at postscreen_dnsbl_ttl
> instead (changing it from the default of 1 hour to something smaller)?

Perhaps. This would be a reason to use the actual reply TTL,
and to use postscreen_dnsbl_ttl as an upper bound.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_cache_retention_time

Rich Wales
> Perhaps. This would be a reason to use the actual reply TTL,
> and to use postscreen_dnsbl_ttl as an upper bound.

Just so I'm sure I understand, then, is the following correct?

    postscreen_dnsbl_ttl is the minimum period of time during which
    the result of a DNS lookup will be treated as valid.  If the
    TTL given by a DNSBL site is less than postscreen_dnsbl_ttl, the
    postscreen code will use postscreen_dnsbl_ttl instead of the
    DNS TTL; but if the DNS TTL is greater than postscreen_dnsbl_ttl,
    the postscreen code will use the DNS TTL value.

Are there any considerations which would make it inadvisable to use a
very low postscreen_dnsbl_ttl value?  What is the minimum value you
would recommend using, regardless of any concerns about rapidly changing
DNSBL info?  If I were to use postscreen_dnsbl_ttl = 1s (in order to
track very short TTL's from Spamhaus or other DNSBLs), would that break
other things in the postscreen logic?

Rich Wales
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_cache_retention_time

Wietse Venema
Rich Wales:
> > Perhaps. This would be a reason to use the actual reply TTL,
> > and to use postscreen_dnsbl_ttl as an upper bound.
>
> Just so I'm sure I understand, then, is the following correct?

No.

a) currently, postscreen_dnsbl_ttl always overrides the DNS reply TTL.

b) the corrected implementation is an upper bound, i.e. a maximum,
i.e.  postscreen_dnsbl_ttl overrides only larger reply TTL values.

> Are there any considerations which would make it inadvisable to use a
> very low postscreen_dnsbl_ttl value?

It would increase the query traffic between Postfix and the local
DNS resolver, and increase the query/update traffic between Postfix
and the local postscreen cache.

But, with the current implementation, it would better handle the
case of reply TTLs less than 1 hour.

        Wietse