| Main Archive Page > Month Archives > postfix-users archives |
Re: more actions for *header_checks/body_checks
From: Wietse Venema <wietse_at_nospam>Date: Wed Nov 16 2011 - 17:55:34 GMT
To: Postfix users <postfix-users@postfix.org>
Solar Designer:
> On Wed, Nov 16, 2011 at 10:39:00AM -0600, /dev/rob0 wrote:
> > On Wednesday 16 November 2011 10:06:36 Solar Designer wrote:
> > > I admit I'm not familiar with the code and I haven't tried to
> > > implement ACCEPT yet, but aren't DISCARD and REJECT also
> > > whole-message actions? Is ACCEPT somehow very different?
> >
> > Yes. What do you think this ACCEPT action would do, unconditionally
> > permit the mail regardless of other reject actions elsewhere?
>
> No, it would merely bypass checks of further input lines against the
> same table.
You mean:
header_checks = xx:xx, yy:yy, zz:zz
There are several problems with this idea.
Some background first. Many Postfix table lookups are handled by
three layers of code:
1) Table-driven mechanisms (header_checks, virtual_alias_maps,
transport_maps). This layer knows what ACCEPT means in header_checks,
but it has no information about the table that provided the result.
2) Drivers for multi-table searches. This driver has no clue about
header_checks or transport_maps, it has no clue what the lookup
result means, and it does not record any information about the table
that provided a match, because it has never needed to worry about
such things.
3) Table lookup mechanisms (hash, regexp, pcre, ldap, tcp). These
have no clue about header_checks or transport_maps, and they have
no clue what the lookup result means.
> In other words, it would be similar to DUNNO, with the difference being
> that further input lines are not inspected.
So the second header_checks table can ACCEPT the message, but the
first header_checks table can still REJECT it upon a later input.
I expect usability problems with this approach.
Wietse