Quoth Philip Hazel on Wed, Nov 08, 2000:
> I have realized that the forwardfile and aliasfile directors are really
> very similar, the main difference being that the former just takes the
> entire contents of a file, while the latter uses the file as a database
> (or looks in a real database) to extract something.
I would also say that aliasfile and smartuser are very similar
(as in, aliasfile can be emulated very easily using smartuser),
so maybe it's time to bring them closer together too.
Maybe it's time to unify everything and have one big director
router? (actually, not such a bad idea, when I think about it)
> One of the things I am planning to propose in the "White Paper" I'm
> planning to write early in the new year is to amalgmate these two
> drivers into a single driver called "redirect". (The two old names,
> inherited from Smail, are increasingly inaccurate.)
Maybe it'd be nice to have a smartuser-like director with
features like "pull a record from the file and use it as a list
from addresses" (aliasfile, and yes, it already exists) and "use
the file as a list of addresses (and maybe filter)" (to emulate
forwardfile).
> In a combined driver, setting "file" without "search_type" would do the
> forwardfile thing; setting both "file" and "search_type" would do the
> aliasfile thing; setting "query" or "queries" instead of "file" would
> also do the aliasfile thing. In all cases, filtering would be possible.
Nice! Sounds groovy.
> However, we aren't there yet. The most logical way to add the filtering
> feature you want to the existing drivers would be to add a "filter"
> option to aliasfile. However, that is an annoyingly large amount of
> work, because of the associated options that forbid various things.
>
> Therefore: In the expectation that this is in some sense a stop-gap,
> temporary solution, I propose to add "query" and "queries" options to
> forwardfile, mutually exclusive with the "file" option. The text looked
> up by the query will be handled as if it were the contents of a .forward
> file. For filtering, either it will have to contain \n characters, or
> you will have to use the ${sg} string operator to turning something else
> into \n for Exim to process. The reason \n characters are needed is to
> terminate comment lines, and the initial "# Exim filter" line (which is
> a sort of comment).
Umm... If someone wants to have filter-like commands in
aliasfile, maybe it would be nice to have, in addition to "see if
it's filter and do the appropriate thing", an option meaning
"treat it as a filter in any case", requiring no magic line in
the beginning. In this case it would be possible to have
aliasfile with filter-only entries like:
foo: if personal than finish elsif [...]
bar: save /sbin/init
> OK?
Cool.
It's raining in Cambridge tonight, isn't it? ;)
Vadik.
--
To the systems programmer, users and applications serve only to
provide a test load.
