On Tue, Apr 23, 2013 at 08:05:34PM -0400, Wietse Venema wrote:
> On Fri, Apr 12, 2013 at 06:34:24AM -0400, Wietse Venema wrote:
> > /dev/rob0:
> > > I finally got around to my upgrade to 2.11-20130405 and was 
> > > watching logs. A gmail message fell afoul of the after-220 
> > > tests; each time it came from a different host. Each one got
> > > a "PASS NEW" and of course the "450 4.3.2 Service currently 
> > > unavailable" rejection.
> > > 
> > > These gmail outbounds are all listed in list.dnswl.org as 
> > > 127.0.5.1, and I give that a negative score in my 
> > > postscreen_dnsbl_sites. So with no offsetting DNSBL scores, 
> > > these hosts all got a subzero score. It would be nice if we 
> > > could put those whitelist scores to work, and not have to 
> > > maintain so big of a postscreen_access_list whitelist.
> > 
> > Disabling tests based on DNSWL score would make sense (currently
> > they "disable" DNSBL tests only). Perhaps this needs a "disable"
> > flag in the postscreen cache.
> 
> On second consideration, this can be done as follows:
> 
> - One parameter with the (negative) postscreen_dnsbl_sites score
>   that is needed to allow the client to skip tests.

"postscreen_skip_tests_threshold", or should there be a _dnsbl or 
_dnswl in there? "postscreen_dnsbl_skip_tests_threshold" is good 
because it lumps it in with the other postscreen_dnsbl_* settings 
and makes it clear that this is associated with the DNSBL lookups.
OTOH _dnswl almost does this too, and it's more accurate. To see how 
it looks: "postscreen_dnswl_skip_tests_threshold".

> - One parameter with the names of tests that are skipped (using
>   !name to exclude a name, and static:all to match everything).
>   This may include "greet" to cancel a "greet wait" in progress.

As for "type:name", like postscreen_access_list, you're going to want 
to discourage lookups which might slow this down. I guess only pcre, 
regexp, static, and texthash would be suitable for this? I did not 
include such a warning in the proposed documentation below.

I think you might want to consider an "all", because that's used in 
numerous other places and meets the "minimum surprise" ideal.


        * Postscreen Skippable Test Names *

before-220                      after-220
==========                      =========
                                bare_newline
blacklist
greet
mx_policy
                                non_smtp_command
                                pipelining
                static:all


I don't think there's much point in skipping the blacklist test. It 
would be very strange if the postscreen_access_list lookup came in 
after the DNSBL lookups. Furthermore, if I listed something there 
that I don't want to see, it should never pass. But maybe someone 
would want this? A test can be "skipped" even if already completed. 
(But what if the postscreen_access_list result is reject? Shouldn't 
that be done immediately, before the DNSBL lookups are in?)

Likewise, I think the mx_policy (postscreen_whitelist_interfaces) 
test should also be absolute. If a client is not connecting on the 
proper IP address, this should be cause for at least having it talk 
to postscreen and try again later. But again, maybe someone would 
trust the DNS whitelists' judgment?

I like the idea of two umbrella categories, before-220 and after-220, 
in the spirit of inet_interfaces' "all" and "loopback-only". But 
there's only three per category, so this is not major at this point. 
(I suppose in the future more tests could be added.)

I think the default should be either "after-220" or "greet, 
after-220". Typically the result would come in during a greet pause, 
and even though it's only a few seconds, it can add up in the Big 
Scheme of Things.

> The procedure is: postscreen does a postscreen_dnsbl_sites query 
> for the client IP address.  If the score satifies the threshold
> in the first parameter, then all tests with a name that matches
> the second parameter will be skipped until the next 
> postscreen_dnsbl_sites query for that client IP address (i.e.
> after postscreen_dnsbl_ttl).

"""
postscreen_skip_tests (default: greet, after-220)

        Allow a remote SMTP client with a score less than or equal to
        postscreen_skip_tests_threshold based on its combined DNSBL
        score as defined with the postscreen_dnsbl_sites parameter,
        to skip the listed tests, if enabled. Specify zero or more of
        blacklist, greet, mx_policy (these three collectively can be
        "before-220"), bare_newline, non_smtp_command, pipelining 
        (these three collectively can be "after-220"), or
        "static:all" to skip all postscreen tests except for the
        DNSBL test itself. Specify "!pattern" to exclude a test from 
        the list.

        Example:

            /etc/postfix/main.cf:
                postscreen_dnsbl_sites = dnsbl.example.org,
                        whitelist.example.com*-1
                postscreen_skip_tests = !blacklist, !mx_policy,
                        static:all

        This feature is available in Postfix 2.11.

postscreen_skip_tests_threshold (default: -1)

        The inclusive upper bound for allowing a remote SMTP client,
        based on its combined DNSBL score as defined with the 
        postscreen_dnsbl_sites parameter, to bypass the tests listed
        in the postscreen_skip_tests parameter.

        Note: this typically would be a negative number, and it only
        makes sense when using DNS whitelists with negative weights
        in the postscreen_dnsbl_sites list. See the example at
        postscreen_skip_tests.

        This feature is available in Postfix 2.11.
"""

I hope this is getting closer? The only point of confusion about it 
in my mind is whether/how to skip the blacklist test. Should 
postscreen, knowing "blacklist" is in the postscreen_skip_tests list, 
await the dnsblog results for a blacklisted client? Why? It's 
certainly not going to hold up a postscreen_access_list "permit" 
client.

Thanks again for considering this.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Reply via email to