Re: postscreen_dnsbl_sites vs. reject_rbl_client
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
Re: postscreen_dnsbl_sites vs. reject_rbl_client
On Wed, Jun 08, 2011 at 10:05:05AM -0700, Rich Wales wrote: > 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. > 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. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: postscreen_dnsbl_sites vs. reject_rbl_client
On 6/8/2011 12:05 PM, Rich Wales wrote: 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 ri...@richw.org 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
Re: postscreen_dnsbl_sites vs. reject_rbl_client
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 ri...@richw.org
Re: postscreen_dnsbl_sites vs. reject_rbl_client
On Tue, Jun 07, 2011 at 07:03:34AM -0400, Wietse Venema wrote: > 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 -- Viktor.
Re: postscreen_dnsbl_sites vs. reject_rbl_client
Rich Wales: > > 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
Re: postscreen_dnsbl_sites vs. reject_rbl_client
* 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 -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: 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? 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 Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: postscreen_dnsbl_sites vs. reject_rbl_client
Rich Wales: > > 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
Re: postscreen_dnsbl_sites vs. reject_rbl_client
> 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 ri...@richw.org
Re: 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? 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
Re: postscreen_dnsbl_sites vs. reject_rbl_client
> 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 ri...@richw.org
Re: postscreen_dnsbl_sites vs. reject_rbl_client
On 6/6/2011 5:34 PM, Jeroen Geilman wrote: On 06/06/2011 10:45 PM, Rich Wales wrote: 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
Re: postscreen_dnsbl_sites vs. reject_rbl_client
On 06/06/2011 10:45 PM, Rich Wales wrote: 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. -- J.
postscreen_dnsbl_sites vs. reject_rbl_client
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 ri...@richw.org
