Re: [Exim] Address Re-writing

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Phil White
Dátum:  
Címzett: exim-users
Tárgy: Re: [Exim] Address Re-writing
Err, well actually I took into account the possibility that the headers would
not be rewritten in order! (I normally try to thrash out an answer before
posting my 'help me' requests!)

This is what I have so far managed to deduce (therefore eliminate from my
list of possible methods to achieve desired aim) :

* as the sender never has the address <username>@freeport.co.uk
    rewrite rule (1) below always fails.
* used in the rewite rule (2) below, $domain contains the SENDERS domain
    (amazing but true), therefore won't work.
    $original_domain contains nothing useful.
== presumably this is because I am rewriting using Ffrs ==
~~ therefore, I cannot achieve desired result using a rewrite rule :-(
    That leaves directors, transports & external methods.
* The obvious approach is to use headers_remove = From
    except that that doesnt remove the first line
      From data_medica@??? Sat Sep 15 21:24:25 200
    Can't even use body_only for the same reason.


So, AFAICS, Exim alone cannot achieve what I want.

QUESTION: Am I missing something obvious?
QUESTION: If I absloutely have to pass the message on to an external
helper, which method would seem to be the best, bearing in mind that after
the sender has been re-written, exim will then need to process the
message to route to the recipients. Do I write a shell or perl script, or do it
via filtering? (I have no experience of filtering yet...!)

==================
(1) *@freeport.co.uk    wibble@localhost Ffrs


(2) *@*     "${if eq {${domain}}{cadellin.itmagic.ltd.uk} \
        {wibble@localhost}\   # use this line for testing only!
        fail}" Ffrs


On 26 Jun 2001, at 8:46, Philip Hazel wrote:

> On Tue, 26 Jun 2001, Phil White wrote:
>
> > Hence, in my abortive attempt, I firstly (assuming that the headers are
> > rewritten in the order which they are specified, which I now don't think
> > they
> > are)
>
> Aha! That will be your problem. I guess I don't need to look at your
> debug output - but will save it. Let me know if I do need to look. Here
> is an extract from the specification which I think you must have
> overlooked. It comes from section 34.2: