[Mailman-Developers] Change to acceptable_aliases

Harald Meland Harald.Meland@usit.uio.no
25 Apr 2000 23:16:15 +0200

[Barry A. Warsaw]

> >>>>> "HM" == Harald Meland <Harald.Meland@usit.uio.no> writes:
>     HM> If we're going to complicate this interface further, why not
>     HM> go straight for some full-fledged ACL-like stuff?
> What do you have in mind?

I think this has been discussed before, but put on back burner due at
least partly because editing anything ACL-like with a web (non-Java
etc.) interface seems cumbersome.

I haven't had any brilliant ideas as to how that problem should be
solved, but nevertheless I'm more and more inclined to implement
something that would allow (clueful) admins to do things like:

  allow header_From matching @\S*\buio.no
  deny has_header X-RBL-Warning
  deny size > 1MB
  hold size > 40k
  allow header_From in members
  hold *                                        # default

As usual, the ACL is composed of rules, each consisting of an "action"
and a "condition".  The condition must be satisfied for the
corresponding action to take place.  The ACL is searched top-to-bottom
for the first rule whose condition is true.  If such a rule is found,
the corresponding action is executed, and the search stops.
Otherwise, the default action (which should be to "hold" the message,
I guess) is executed.

This would allow the filtering functionality to be configured in a
very generic way with a single config option, albeit a rather complex

[ The above ACL example is just something i jotted down off the top of
  my head -- I haven't given much thought to the syntax I have used,
  nor do I have any strong opinions about exactly which actions and
  conditions should exist. ]

Of course, a big concern is whether implementing such a beast will
make "filtering configuration" of Mailman lists too strange (or even
obfuscated) for most list admins.

It might be possible to construct some kind of mapping between the
current config options and an ACL option, and make it possible for
"inexperienced" users to continue using an interface similar to the
one we have today (allowing Mailman to only consult the ACL whenever
there's a need to decide which action should be taken for some
message), but it sounds rather full of thorns...