Re: [exim] router "unseen", and headers_add

Top Page
Delete this message
Reply to this message
Author: Jeremy Harris
Date:  
To: exim-users
Subject: Re: [exim] router "unseen", and headers_add
Philip Hazel wrote:
> On Wed, 26 Jan 2005, Jeremy Harris wrote:
>
>
>>Version 4.43
>>
>>I'm setting up headers_add in router "A", doing an unseen delivery in router
>>"B" then a real delivery in router "C". The real delivery
>>doesn't seem to get the headers added. Is this expected?
>
>
> Yes. The documentation says it, but the current edition is not very
> clear. It says:
>
>     Exim does not check the syntax of these added header lines. If an address
>     passes through several routers as a result of aliasing or forwarding
>     operations, any "headers_add" or "headers_remove" specifications are cumu-
>     lative. This does not apply for multiple routers that result from the use
>     of 'unseen'.

>
> As it happens, I have in fact already re-written the documentation about
> header modifications for the next edition.
>
> What happens when a router does the "unseen" thing is that the original
> address becomes a "parent" with two children, the unseen delivery one,
> and a new clone that is passed to the next router (like an alias with
> two children). The delivered address gets all the header modifications
> so far specified - from previous routers and from the "unseen" router
> itself. The new clone gets none.
>
> This setup allows you to add headers to an address until it is "unseen"
> delivered; the subsequent routers then start again with an empty slate.
>
> In the code, there is this comment:
>
> /* As it has turned out, we haven't set headers_add or headers_remove for the  
>  * clone. Thinking about it, it isn't entirely clear whether they should be
>  * copied from the original parent, like errors_address, or taken from the  
>  * unseen router, like address_data and the flags. Until somebody brings this
>  * up, I propose to leave the code as it is.                             
>  */     

>
> I think the current facility is probably useful to some people, and I
> don't think that making an incompatible change is a good idea. I suppose
> this means that, if copying the headers from router "A" and its
> ancestors is wanted, an option will be needed. I presume that copying
> header_{add,remove} settings from router "C" is NOT wanted. Or are they?
> Maybe it should be all or nothing?


Ah, I'd been expecting two identical clones as a result of "unseen", one
delivered and one passed on to the next router. But I agree that
incompatible changes are bad. I'll rethink my coding.

Thanks,
    Jeremy