>> If I am reading this right, then expand.c isn't expanding added headers
>> because they're not in the link list it is checking. This would explain the
>> behavior I'm seeing.
>
> I ignored your post because it referred to Exim 3, and my brain has now
> more or less expunged any memory that I had, since Exim 4 has been out
> for well over a year (and I've been working on it for about 2 years
> now).
>
>> Is this expected behavior, or am I doing something wrong?
>
> Yes, it is expected, and it is the same in Exim 4, where the manual
> contains the following in the section on $header_xxx insertions:
>
> Only header lines that are common to all copies of a message are visible to
> this mechanism. These are the original header lines that are received with
> the message, and any that are added by an ACL "warn" statement or by a |
> system filter. Header lines that are added to a particular copy of a
> message by a router or transport are not accessible.
Philip:
Thank you very much for your reply; as always it is greatly appreciated. It
hadn't occurred to me to check the Exim 4 docs for an Exim 3 issue.
Sorry to bring up Exim 3 problems, but until the good folks at Debian bless
Exim 4.20 as being "stable" I think that many of us Debian users will
continue running Exim 3.35. This is for administrative reasons and not due
to any lack of faith in Exim 4.
List:
How does one go about setting a flag in one director for use by another in
Exim 3? The only thing I can think of is to add a header with headers_add
and then pipe the result back into Exim. This seems somewhat inefficient to
me (the cost of a new process generation). Any suggestions?
Thanks. - John R. S.
