Prev: postscreen ps_cache fatal
Next: up'd Fedora from 10->11, now postmap won't query pgsql db
From: Wietse Venema on 9 Dec 2009 16:25
Kenneth Marshall:
> On Wed, Dec 09, 2009 at 03:42:30PM -0500, Wietse Venema wrote:
> > Len Conrad:
> > > postconf -n | egrep postscreen
> > >
> > > postscreen_blacklist_action = drop
> > > postscreen_blacklist_networks = mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
> > ...
> > > postscreen_whitelist_networks = $mynetworks, hash:/usr/local/etc/postfix/mta_clients_white.map
> > >
> > > postmap -q "12.184.45.106" /usr/local/etc/postfix/mta_clients_white.map
> > > ok
> > >
> > > but still
> > >
> > > Dec 9 15:16:01 mx101 postfix/postscreen[94732]: BLACKLISTED 12.184.45.106
> >
> > The postscreen manpage lists the tests in the order of execution.
> > Thus, the blacklist is done tested first. If the client is not
> > blacklisted, then the whitelist test is done. And so on.
> >
> > I could swap the order of black/white tests if there is agreement that
> > the current order is not optimal, but something has to go first.
> >
> > Wietse
> >
> It would make more sense to have the whitelist first since that
> is its normal use, overriding a restriction.

No problem. I suppose I lost sight of the prime directive, which
is to deliver mail.

Wietse

From: Wietse Venema on 9 Dec 2009 18:13
Len Conrad:
> btw, how to get:
>
> postmap -d "ip.ad.re.ss" mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
>
> not to return:
>
> postmap: fatal: mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf map requires O_RDONLY access mode

That would require updating the documentation that has only "select"
commands, and updating the code that implements the documented behavior.

Wietse

From: Mark Martinec on 10 Dec 2009 11:25
Wietse Venema wrote:
> The postscreen manpage lists the tests in the order of execution.
> Thus, the blacklist is done tested first. If the client is not
> blacklisted, then the whitelist test is done. And so on.
>
> I could swap the order of black/white tests if there is agreement that
> the current order is not optimal, but something has to go first.

That reminds me of a mistake in early tcp_wrappers, which
kept allow and deny lists separate - later fixed by introducing
hosts_options(5) which allowed mixing of allow and deny entries.

The same mistake was repeated by Apache httpd config, which works
around the problem of having two lists instead of one merged list
by a horrible kluge in a form of an 'Order' directive.

There is no 'one size fits all' right order of allow/deny or
black/white lists, if these are limited to one list of each type.
Conceivably one could need a:
white 10.1.1.1, black 10.1.1.0/24, white 10.0.0.0/8

Some solution like a postfix access(5) or cidr_table(5) table
would be best, with entries each claiming an OK/REJECT or whatever
is documented.

Mark

From: Wietse Venema on 10 Dec 2009 13:54
Mark Martinec:
> Wietse Venema wrote:
> > The postscreen manpage lists the tests in the order of execution.
> > Thus, the blacklist is done tested first. If the client is not
> > blacklisted, then the whitelist test is done. And so on.
> >
> > I could swap the order of black/white tests if there is agreement that
> > the current order is not optimal, but something has to go first.
>
> That reminds me of a mistake in early tcp_wrappers, which
> kept allow and deny lists separate - later fixed by introducing
> hosts_options(5) which allowed mixing of allow and deny entries.
>
> The same mistake was repeated by Apache httpd config, which works
> around the problem of having two lists instead of one merged list
> by a horrible kluge in a form of an 'Order' directive.
>
> There is no 'one size fits all' right order of allow/deny or
> black/white lists, if these are limited to one list of each type.
> Conceivably one could need a:
> white 10.1.1.1, black 10.1.1.0/24, white 10.0.0.0/8
>
> Some solution like a postfix access(5) or cidr_table(5) table
> would be best, with entries each claiming an OK/REJECT or whatever
> is documented.

We may have a mis-understanding. Postscreen is unlike a firewall
whose purpose is to flag authorized/unauthorized connections with
static allow/deny rules. Postscreen's primary purpose is to flag
bad/good clients by dynamic observation of their behavior, or by
dynamic queries for their third-party reputation.

The postscreen whitelist and blacklist are not the primary
authorization mechanisms. In fact, they did not even exist when I
reported some initial results in July. The whitelist purpose is
to work around the inevitable false positives, and the blacklist
purpose is to avoid wasting limited resources.

The problem of mixed allow/deny lists is that no-one understands
how they work. Changing the order of two rules can completely change
the meaning of the filter. With separate white and black lists,
the order of the rules does not matter; it is easier to understand,
like pure declarative programming.

For practical reasons, the postscreen whitelists and blacklists do
support negation (x, !y, z, ...), but unlike mixed allow/deny lists,
they don't require that this property be used.

I don't think that postscreen needs mixed allow/deny list (i.e.
access map) functionality. That would just raise the expectation
that postscreen works like an smtpd clone. That is fundamentally
not possible: postscreen is one program that must be able to
protect 1000 SMTP servers, so it cannot be a smtpd lookalike.

As of snapshot 20091209, postscreen searches the whitelist first.
This ensures that postscreen does not block whitelisted clients.
There's a cut-and-paste error in the postscreen manpage that has
meanwhile been corrected.

Wietse

From: "Len Conrad" on 10 Dec 2009 14:02

>As of snapshot 20091209, postscreen searches the whitelist first.

great, thanks

Len

First  |  Prev  | 
Pages: 1 2
Prev: postscreen ps_cache fatal
Next: up'd Fedora from 10->11, now postmap won't query pgsql db