On Thu, 13 Dec 2001, Phil Chambers wrote:
> It appears that $original_local_part expands to "message filter" when a message has
> been generated by a "deliver" command in a system filter. In practice this means
> that it may not be possible to use $original_local_part when using a system filter
> which uses "deliver".
Correct.
> I can see two alternatives:
>
> 1) When using $original_local_part, make it conditional:
>
> ${if eq {$original_local_part}{message filter}\
> {$local_part}{$original_local_part}}
>
> so that a legal result is always obtained.
>
> 2) Make Exim evaluate $original_local_part in this way automatically.
>
> In the first case the documentation for $original_local_part should point out this
> potential problem.
When a system filter sets up a pipe, file, or autoreply delivery, it has
to create a "pseudo-parent" because these kinds of delivery cannot be
toplevel addresses in Exim. Futhermore, you want information on the log
to show why a particular delivery happened, not only for these
deliveries, but also for "deliver" deliveries. That's why a
pseudo-parent is also created for "deliver" addresses. Otherwise the log
would imply that the addresses created by the system filter were
toplevel recipients that arrived with the message, which of course they
are not. That is, you want the delivery record, on the log, to show
which deliveries were created by the system filter. The pseudo-parent is
a convenient way to do this.
Therefore, I do not think (2) is right, because it disguises the origin
of the address. If you really want to handle these addresses this way,
(1) is the way you have to do it.
Note that in Exim 4, the address is "system-filter", not "message
filter", or at least, it will be in the next alpha (the current alpha
has "system filter".
I will add words to the Exim 4 documentation for the $original_xxx and
$parent_xxx variables.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
