postscreen_dnsbl_sites vs. reject_rbl_client

[Rich Wales]

If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since they will now be redundant?

Rich Wales
***@richw.org

[Jeroen Geilman]

Post by Rich Wales
If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since they will now be redundant?

On the interfaces and ports that postscreen(8) passes mail to, yes.

If you have a dedicated submission port, this is not affected by
postscreen running on port 25.


Do note that the behaviour is different; you will be able to directly
transplant your reject_rbl_client RBLs to postscreen, but postscreen has
many more options available, such as checking for exact return values,
and scoring different RBLs with separate weight values.

[Noel Jones]

Post by Jeroen Geilman

Post by Rich Wales
If I enable postscreen and specify my choice of blocklists
and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I
might as well
remove any reject_rbl_client and permit_dnswl_client clauses
from my
smtpd_*_restrictions, since they will now be redundant?

On the interfaces and ports that postscreen(8) passes mail to,
yes.
If you have a dedicated submission port, this is not affected
by postscreen running on port 25.
Do note that the behaviour is different; you will be able to
directly transplant your reject_rbl_client RBLs to postscreen,
but postscreen has many more options available, such as
checking for exact return values, and scoring different RBLs
with separate weight values.

The reject_rbl_client (and various relations) smtpd
restrictions can also check for exact values (postfix 2.1 and
newer), or for ranges (postfix 2.8 and newer, same range
syntax as postscreen). The weighted scores are unique to
postscreen.
http://www.postfix.org/postconf.5.html#reject_rbl_client

The other difference is that postscreen caches a "pass" dnsbl
result for $postscreen_dnsbl_ttl (default 1h). Some sites may
prefer to lower the cache TTL or do the tests in smtpd to
quickly catch previously good clients gone bad, or to increase
the TTL to reduce DNS lookups and latency.
http://www.postfix.org/postconf.5.html#postscreen_dnsbl_ttl


-- Noel Jones

[Rich Wales]

Post by Jeroen Geilman
On the interfaces and ports that postscreen(8) passes mail to, yes.
Do note that the behaviour is different; you will be able to directly
transplant your reject_rbl_client RBLs to postscreen, but postscreen
has many more options available, such as checking for exact return
values, and scoring different RBLs with separate weight values.

Yes, I see that, and I like it. As one important step in my postscreen
conversion, I reviewed the documentation for numerous blocklists (some
of which I had passed over earlier because I wasn't willing to trust
them completely) and assigned different scores depending on the returned
value from a given list. (I won't go into the details, they would be
off-topic here, but it's nice to have this capability.)

Rich Wales
***@richw.org

[Wietse Venema]

Post by Rich Wales
If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since they will now be redundant?

Almost. Note that postscreen caches the results of successful tests,
so that it does not repeat every test for every connection. This
is controlled by the postscreen_mumble_ttl parameters.

postconf | grep 'postscreen_.*_ttl'

Wietse

[Rich Wales]

Post by Wietse Venema
Note that postscreen caches the results of successful tests,
so that it does not repeat every test for every connection.
This is controlled by the postscreen_mumble_ttl parameters.

Some caching may also be done by my DNS server too, right? This would,
of course, be transparent to Postfix and would depend on the TTL info
from the whitelist / blocklist.

It appears, based on my server's logs, that postscreen always queries
every site I name in postscreen_dnsbl_sites -- subject, of course, to
caching by my DNS server and by postscreen's own TTL settings. I'd
think it would be possible, in some cases, to avoid some queries once
enough information is obtained to make a threshold decision -- e.g.,
by checking lists in descending order by absolute value of weight, a
point may be reached where no further results can make a difference
in the decision to permit or reject. Do you think there would be any
point in doing this? Or would it just be a meaningless exercise, and
you might as well query everything every time?

Rich Wales
***@richw.org

[Wietse Venema]

Post by Rich Wales

Post by Wietse Venema
Note that postscreen caches the results of successful tests,
so that it does not repeat every test for every connection.
This is controlled by the postscreen_mumble_ttl parameters.

Some caching may also be done by my DNS server too, right? This would,
of course, be transparent to Postfix and would depend on the TTL info
from the whitelist / blocklist.
It appears, based on my server's logs, that postscreen always queries
every site I name in postscreen_dnsbl_sites -- subject, of course, to
caching by my DNS server and by postscreen's own TTL settings. I'd
think it would be possible, in some cases, to avoid some queries once
enough information is obtained to make a threshold decision -- e.g.,
by checking lists in descending order by absolute value of weight, a
point may be reached where no further results can make a difference
in the decision to permit or reject. Do you think there would be any
point in doing this? Or would it just be a meaningless exercise, and
you might as well query everything every time?

Just like postscreen examines multiple clients in parallel, postscreen
sends DNSBL queries in parallel. Everything is done in parallel,
to minimize the delay for good clients.

Wietse

[Ralf Hildebrandt]

Post by Rich Wales
If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since they will now be redundant?

Since postscreen uses caching extensively, it might make sense to
query the RBLs another time, since a host may be blacklisted in the
meantime.

[Ralf Hildebrandt]

Post by Rich Wales
value from a given list. (I won't go into the details, they would be
off-topic here, but it's nice to have this capability.)

It will probably start a flamewar, but I personally am interested in
your particular weights on the different RBLs

[Wietse Venema]

Post by Rich Wales

Post by Wietse Venema
Note that postscreen caches the results of successful tests,
so that it does not repeat every test for every connection.
This is controlled by the postscreen_mumble_ttl parameters.

Some caching may also be done by my DNS server too, right? This would,
of course, be transparent to Postfix and would depend on the TTL info
from the whitelist / blocklist.

Note the following difference.

postscreen caches that the client IS NOT listed in DNSBL.
It doesn't cache clients that are listed.

DNS servers cache that the client IS listed in DNSBL.
They don't cache non-existent DNSBL records.

So, the two really cache opposite things, if we focus on "good"
SMTP clients. And that is where Postfix tries to minimize the
performance hit.

Wietse

[Victor Duchovni]

Post by Wietse Venema
Note the following difference.
postscreen caches that the client IS NOT listed in DNSBL.
It doesn't cache clients that are listed.
DNS servers cache that the client IS listed in DNSBL.
They don't cache non-existent DNSBL records.

This depends on the negative TTL of the RBL zone. Generally, RBL
zones have comparable positive and negative TTLs.

For example Zen seems to have a 3 minute negative TTL:

$ dig +noall +ans +auth -t a 127.2.0.192.zen.spamhaus.org
zen.spamhaus.org. 150 IN SOA need.to.know.only. hostmaster.spamhaus.org. 1106071530 3600 600 432000 150

And a 15 minute positive TTL:

$ dig +noall +ans -t a 126.145.66.190.zen.spamhaus.org
126.145.66.190.zen.spamhaus.org. 900 IN A 127.0.0.4
126.145.66.190.zen.spamhaus.org. 900 IN A 127.0.0.11

[Rich Wales]

Another thing I think I see about postscreen is that it apparently will only
look up IP addresses. There doesn't seem to be any "postscreen_rhsbl_sites"
feature (which might allow me to move my current reject_rhsbl_client and
permit_rhswl_client checks into postscreen). Is such a thing planned, not
planned, or perhaps intrinsically evil for some reason I'm not thinking of?

Rich Wales
***@richw.org

[Noel Jones]

Post by Rich Wales
Another thing I think I see about postscreen is that it apparently will only
look up IP addresses. There doesn't seem to be any "postscreen_rhsbl_sites"
feature (which might allow me to move my current reject_rhsbl_client and
permit_rhswl_client checks into postscreen). Is such a thing planned, not
planned, or perhaps intrinsically evil for some reason I'm not thinking of?
Rich Wales

The postscreen program doesn't do reverse DNS lookups in the
interest of speed and simplicity. As a consequence, it is not
possible to do any hostname-based filtering in postscreen.

There are no current plans to change this.


-- Noel Jones

[/dev/rob0]

Post by Rich Wales
Another thing I think I see about postscreen is that it apparently
will only look up IP addresses. There doesn't seem to be any
"postscreen_rhsbl_sites" feature (which might allow me to move my
current reject_rhsbl_client and permit_rhswl_client checks into
postscreen).

Why "move" any checks into postscreen? I basically left my smtpd
restrictions alone. I figure they can't hurt and might help. Sure,
they are lonely and mostly unused, but they were a good policy in
pre-postscreen days, so they're still good.

I can give an example of when/why they might help. Under stress,
postscreen reduces the greet pause to 2 seconds. Under stress, the
possibility that DNSBL responses might be delayed is greater. Why
would you not avail yourself of that second chance to query
zen.spamhaus.org? It's cached now at your nameserver, whether
positive or negative, so it hurts nothing.

Post by Rich Wales
Is such a thing planned, not planned, or perhaps intrinsically
evil for some reason I'm not thinking of?

I think postscreen needs to stay lightweight and fast. It does not
need to replace all the antispam functionality of smtpd.

[Wietse Venema]

Post by Rich Wales
Another thing I think I see about postscreen is that it apparently will only
look up IP addresses. There doesn't seem to be any "postscreen_rhsbl_sites"
feature (which might allow me to move my current reject_rhsbl_client and
permit_rhswl_client checks into postscreen). Is such a thing planned, not
planned, or perhaps intrinsically evil for some reason I'm not thinking of?

I concur with what others wrote, and would like to emphasize again
that postscreen is not a REPLACEMENT for existing smtpd features.

It is a filter that blocks the most suspicious clients with the
smallest possible effort. The existing postfix features can take
care of the rest of the problem.

Wietse