著者: Michael Haardt 日付: To: exim-dev 題目: Re: [exim-dev] Running .forward files at verification time
On Thu, Apr 13, 2006 at 10:19:30AM +0100, Philip Hazel wrote: > > 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?
IMHO, kludge is exactly the correct word for any solution to this. While
you could indeed (with some modifications to prevent all side effects,
only keeping the result of accept or deny) run a filter at verification
time, you could not access the message at this time, and that would hurt.
Of course one could say: If it hurts if you do that, then don't do that,
but that won't prevent users from deciding by accessing headers if they
accept a mail, so you have to deal with that case. How? By merging the
side effects of both branches of a test you can't perform, and accepting
the mail for verification, if either might accept it? Quite a hack, but
at least it would not lose mail by accident.
> 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.]
That solves this one particular problem, yes.
> 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."
I can almost hear people telling me that "suffixed addresses are broken". :-)
The topic of running filters at verification time has been discussed on
the Sieve mailing list to death several times in the context of SMTP
level refusal. So far, I did not see a consensus for filters that use
more than the envelope in their tests, and most real filters do.
To me, verification should be done by the MDA, with user priviledges, and
Exim can not do that. That's a design problem. AFAIK, Qmail has the
same problem, and I expect most MTAs work that way. Unfortunately, the
Exim filter, and Sieve as well (and again I expect other filters to
follow), are not well suited to perform verification only, either.
With that in mind, the kludge of an external list of accepted addresses
does not sound as bad as before.