Solar Designer:
> On Thu, Nov 17, 2011 at 06:39:29AM -0500, Wietse Venema wrote:
> > Solar Designer:
> > > Does this mean you're going to implement it? Sounds great if so. And
> > > the default action feature, please - I'd use them together.
> >
> > ACCEPT in header_checks == turn off header checks for this message.
>
> Right. (And maybe body checks as well, or maybe this contradicts the
> policy stated below...)
>
> > No Postfix table-driven feature has support for unmatched patterns;
> > No Postfix table-driven "yes/permit/accept" feature overrides other
> > table-driven features.
>
> I suppose adhering to this policy has both pros and cons.
Let's for a monent look at what the system does well and why. The
system is designed for blocking stuff. There are N rule sets that
can block/discard independently (smtpd_client_restrictions etc.,
header_checks etc.,). If any of them blocks, mail is not queued.
It's a vetoing system. All the other actions such as filter or
redirect are just riding along on the train.
This model is a good fit for vetoing. If is a poor fit for lots of
other things including 1) conditional decisions and 2) "don't reject"
decisions that override other rulesets. So let's not do that.
You have a need for conditional decisions, which could be modeled
as a "maybe reject" action that only takes effect if some other
action (accept) in the same rule set does not fire.
But why stop here? Why not have "maybe filter", "maybe redirect",
and so on that are also dependent on the absence of some other
action (what other action? OK, so we do "ifnot accept reject",
"ifnot filter redirect", etc. to make the condition explicit.
Yes, it is possible. No, it is not a good idea. The resulting
system would be an incomprehensible mess.
In addition you have a need for a positive decision (already a poor
fit for a vetoing system!) in one rule set to override decisions of
other rulesets (here, an accept in header_checks that overrides
rule sets that happen to be co-located in the cleanup daemon).
I'm not saying that your needs are wrong. I am saying that you
need to use a model that is a good fit. It would be a mistake to
change a model that is a poor fit, such as a veto-based system.
It is very well possible that your needs require a model with rules
that have precedences. For example, one receives the entire message,
and applies all the rules in order of precedence and stops at the
first final decision (ACCEPT or REJECT).
Postfix does not work that way. It does not have to solve all
problems. That is what the extension interfaces (including SMTP)
are for.
Wietse
