On Wed, 12 Apr 2006, Tony Finch wrote:
> Earlier this week I had a discussion with Ian Jackson and Jon Amery about
> support for chiark's Exim configuration in Exim 4. They want to be able to
> run users' .forward files at verification time, in order to be able to
> reject local parts with affixes that the user has not defined.
Presumably by running a redirect router with no_more set for affixed
local parts?
I understand the requirement, but I am not happy with the proposed
solution. It seems to me to be too kludgey. I don't like the fact that
it won't work if a user's .forward file is not readable by the exim
user. I don't see how this:
> What we want to be able to do is safely run a .forward file at
> verification time, with all the dangerous features turned off;
> then re-run it at delivery time with all the funky stuff available.
can work. If stuff isn't available at verification time, how can it do
the same things it is going to do at delivery time? And if it can't, how
can it properly verify?
> (1) The set of forbid_filter_* options increases over time, and omitting
> one of them in this verification router opens a security hole. So I
> suggest a forbid_filter_all option which encompases all of them and will
> not become insecure in the future.
forbid_filter_all (or forbid_all) seems reasonable as an independent
point.
> Any comments on these suggestions? Philip, do you have time to do the
> coding? :-)
I wondered how one might implement the requirement without changing
Exim. One possibility is to say this to the users:
"If you want to support multiple addresses such as yourid-suffix, you
must create a file called .address-suffixes in your home directory
that is readable by the exim user (world-readable is fine). In this
file, you must list the suffixed addresses that you want to support.
For example:
yourid-suffix1
yourid-suffix2
If you do this, email with those local parts will be accepted, and the
addresses will be passed to your filter file, with yourid in
$local_part and the suffix in $local_part_suffix. You can use these
variables to process the messages as you wish, for example, sorting
them into different mail folders. If your filter file does not handle
a suffixed address, it will be delivered into your normal mailbox.
[Similar details for Sieve if it is supported.]
If you do not create .address-suffixes, or if it is not readable by
the exim user, or if a message arrives with a suffixed address that is
not in your file, the message will not be accepted."
Implementation of this is left as an exercise. It is trivially
extensible to prefixes or affixes in general, of course.
Another way of doing this, perhaps, would be to use a queryprogram
router, but I suspect that would be pretty kludgey and it would
certainly be inefficient.
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
