Am 2012-09-24 19:06, schrieb Wietse Venema:
Michael Storz:
seems I was
not able to show the underlying problem, let me rephrase my problem:
How can I configure arbitrarily complex if-then-else
constructs
for every possible table type?
You will have to outsource that logic with tcp_table lookups.
Considering that if-then-else table search is useful for maybe
0.0001% of the installed base, I don't think it makes no sense to
spend significant of development resources on it now, and to spend
maintenance resources on it for eternity. There is a lot that needs
to be done and that benefits most of the installed base.
Yes, I suppose that it's possible to emulate conditional processing
with magical query keys and magical lookup results. No, I don't
think that restriction_classes is an example that deserves expansion.
References:
http://www.postfix.org/tcp_table.5.html
Wietse
The installed base really does not matter. E.g. none of the about
10.000 nodes
on our supercoputer each with a Postfix installation will ever benefit
from the
work you did the last years because there is only a null mailer
installed and
thats similar for nearly all installations of Postfix.
New features are only of interest for the mail server of a whole site.
Building
there own reject-restriction is of interest for more sites than you
think. Just
two examples from the archives:
In http://archives.neohapsis.com/archives/postfix/2010-02/0333.html
the user wanted to have the following reject-restriction
if (is_from_mynetwork AND is_sasl_authenticated) {
DUNNO
} else {
REJECT
}
which is aequivalent to
if (is_from_mynetwork) {
DUNNO
} else {
REJECT
}
if (is_sasl_authenticated) {
DUNNO
} else {
REJECT
}
Noel Jones solution uses the approach I suggested to implement the two
if-then-else constructs:
2 restriction classes with a jump-to-the-end-of-restriction-class
action.
In http://archives.neohapsis.com/archives/postfix/2010-12/0981.html
Vi[ck]tor Duchovni made a very nice transformation of the requirement
if (allowed-clients || (allowed-senders AND allowed-recipients)) {
DUNNO
} else {
DISCARD
}
to
if (allowed-senders) {
DUNNO
} else {
if (allowed-clients) {
DUNNO
} else {
DISCARD
}
}
if (allowed-recipients) {
DUNNO
} else {
if (allowed-clients) {
DUNNO
} else {
DISCARD
}
}
and implemented the inner if-then-else construct with a cidr-table
using the
default value for the else and again -- like Noel -- implementing the
outer
if-then-else with restriction classes and jump action.
However, since they could not use a user-defined restriction class
because of
the missing jump action for this kind of class they had to use system
defined
restriction classes and OK as the jump action. This has the drawback
that only
this reject-restriction can be implemented and no other restriction
because
that would be over-jumped by OK whereas this would not be a problem
with my
expansion.
Therefore I think my approach fits very well in the architecture of
Postfix and
the actual usage.
The main advantage and usage case of this expansion would not be the
user
defined reject-restrictions but the possibility to have a whitelist for
every
single system-defined reject-restriction without jumping over the rest
of the
restrictions. his is a wish many admins have.
How often you can read
put the check_mumble_restriction AFTER
reject_unauth_destination,
otherwise you could become an open relay.
on the list? The reason is the jump characteristic of OK. If people
have a
configuration
smtpd_client_restrictions =
check_client_access whitelist
reject_mumble_client_restriction
smtpd_helo_restrictions =
check_helo_access whitelist
reject_mumble_helo_restriction
smtpd_sender_restrictions =
check_sender_access whitelist
reject_mumble_sender_restriction
smtpd_recipient_restrictions =
reject_unauth_destination
everything works fine. But if they move all the restrictions to
smtpd_recipient_restrictions then suddenly they become an open relay
because
the semantic has CHANGED:
smtpd_recipient_restrictions =
check_client_access whitelist
reject_mumble_client_restriction
check_helo_access whitelist
reject_mumble_helo_restriction
check_sender_access whitelist
reject_mumble_sender_restriction
reject_unauth_destination
This would not be the case with my proposed expansion. They could move
their
restrictions around like they want without a semantic change.
Now I have to discuss with my team what will cost us more: living with
our
workarounds of this deficiency of Postfix, writing our own policy
daemon
(could be expensive to implement because of all the ldap queries) or
patching
Postfix ourself. As far as I can see from the internals of
smtpd_check.c the
LAST action should be very easy to implement.
Thanks for the discussion and your time. I have learned a lot about how
Postfix
implements its checks while preparing my posts.
Michael
