Re: [exim] prepending to the localuser - what would be "the …

Top Page
Delete this message
Reply to this message
Author: Ray Chudzinski
Date:  
To: exim-users
CC: exim-users
Subject: Re: [exim] prepending to the localuser - what would be "the exim way"?
Phil,

Thank you for this response.

You provided exactly the right amount of detail. Especially the explanation of the 'way' exim likes to process.
like they say, teach a [wo]man to fish vs give h[im|er] a fish. :-)

I am leaving a bit of your response in the message for the sake of the archives.

Sincerely,
ray

--
Raymond P Chudzinski
rpc1.0@???


On Thursday, February 07, 2008, at 02:38PM, "Phil Pennock" <exim-users@???> wrote:
>On 2008-02-07 at 11:40 -0800, Ray Chudzinski wrote:
>> In a nutshell, I need to:
>>
>> - recognize an incoming message is one of the 'special' messages (most easily done by examining the source host. all of these will come from one MTA)
>> - verify that the localuser is all numeric
>> - rewrite the localhost portion by pre-pending a string
>> - forward the re-written message to a specific remote host for delivery
>>
>> My question is were should I perform each piece of the logic.
>>
>> e.g.
>> 1) matching the format in a router (and reccomendations on the router)
>> 2) verification of the localuser in the router
>> 3) pre-pending the string via a re-write (really not sure of this step)
>> 4) deliverly using the remote_smtp transport
>
>Do 1,2,3 in a redirect router; follow that router with a manualroute
>router. The first router should use "address_data = ..." to cause
>$address_data to be set and the second router should use "condition =
>..." to check $address_data.
>
>There are other ways, but you're then either tying together stuff from
>the ACLs with variables to Routers in a different part of the config, or
>you're relying upon the router ordering and how careful you are to use
>no_more when needed (eg, redirect_router on the first to point to a
>router after the last one that can normally ever be invoked, instead of
>using $address_data).
>


lines deteted....