Philip Hazel writes:
> On Tue, 28 Sep 1999, Malcolm Beattie wrote:
>
> > Suppose I have the following sort of setup:
> >
> > # transports
> > my_save_file:
> > driver = pipe
> > command = "............"
> >
> > # directors
> > filter:
> > driver = forwardfile
> > filter
> > file_transport = my_save_file
> >
> > and a filter triggered by a message through that director contains
> >
> > save foo
> >
> > How can I get at that filename (foo) in the command run by the
> > my_save_file transport?
>
> >From TFM:
>
> $address_file: When, as a result of aliasing or forwarding, a message is
> directed to a specific file, this variable holds the name of the file when
> the transport is running. For example, using the default configuration, if
> user r2d2 has a .forward file containing
>
> /home/r2d2/savemail
>
> then when the address_file transport is running, $address_file contains
> '/home/r2d2/savemail'. At other times, the variable is empty.
Looks like it's time to upgrade my nice printed bound manual: my copy
from July '98 (Exim 2.0x) doesn't mention that variable (at least not
in 9.5 "Expansion variables" where I looked). Thanks for the quote.
> Oh. You are using a *file* name to get to a *pipe*. Hmm. Have to read
> the code ... type, type, type ... well, it looks as though it should
> still set $address_file, though I've never tested this.
This is because I'm using mbx format mailboxes and I want users to be
able to have "save foo" in a filter to save to mbx format mailbox foo.
I can think of two ways to do this: (1) use a pipe transport to call
tmail to deliver to the folder (which is why I asked about which
variable held the filename) or (2) use the new native mbx support in
Exim. The latter requires that I upgrade Exim on the live cluster and
either switch completely to Exim native mbx delivery or else trust
that the locking between tmail and Exim are completely compatible.
Last time you mentioned Exim's mbx support ISTR you said the code was
pretty much taken straight from cclient and so really *should* work OK
but that it probably hadn't undergone a huge amount of testing. By
sticking with tmail for a little while longer I was hoping to avoid
any teething difficulties (like corrupting a few tens of thousands of
mail folders) before I'd tested Exim's native support thoroughly.
Has anyone else now used Exim's mbx support in serious production use?
Another issue with allowing users access to filters is that there are
one or two other things which need forbidding. This is a mail cluster
where no user has interactive access to the machine which simplifies
a lot of things and drastically cuts down on the number of DoS attacks
(either malicious or accidental) that users can carry out. The options
available for configuring filters are good (forbid_pipe, forbid_reply
and such like) but I found one gotcha. Variable expansion isn't
controllable and a user could include
${lookup{foo}lsearch{/dev/zero}{ha}{ha}}
or, stretching the point even further,
${lookup{version 1.0}lsearch{/etc/someapp.conf}{security_hole}{darn}}
in a filter (or NIS or LDAP queries). It would be nice if there was an
option to forbid_lookup (or a generic option for
"dont_trust_users_as_far_as_you_can_throw_them") For the even more
paranoid there's also the "exists" function which allows them to test
existence of files in the filesystem.
I realise this may well be a rather esoteric wish and, for now, I'm
simply going to disallow them to create a filter which uses lookup or
exists since their only access to the filestore is via IMAP (which is
blackboxed to ~/Mail) and the web gateway (which I control). The only
difficulty there is that for completeness I also have to worry about
${expand:...} (which means they could construct a naughty function at
runtime) and exim's lexing rules (backslash continuations or escaping
and such like).
--Malcolm
--
Malcolm Beattie <mbeattie@???>
Unix Systems Programmer
Oxford University Computing Services
