Philip Hazel <ph10@???> probably said:
> On Mon, 15 Dec 1997, Peter Radcliffe wrote:
> > rewrite From: line
> > rewrite envelope from, using $header_from:
> *How* do you have that? The order of rewriting is undefined (as I said).
> There is no guarantee that it will rewrite the From line before it
> rewrites the envelope from line, and in fact in the present
> implementation it does the envelope rewriting before the headers
> rewriting.
Ahh, you meant order of which headers get rewritten, not which order
the rules are applied for each header (which is specified in the spec).
One working example, from my partly working experiment:
My test message has:
From: uucp test <pir!rond>
The two rules are:
user@domain \
"${if match{$header_from:}{<([^@]*)>}{$1}fail}@${qualify_recipient}" Fw
^(?i)([^!.@]+)!([^@]*)@qualify.domain$ \
$2@${lookup{$1}dbm{/usr/local/etc/exim/dbm/uucpdomDBEXT}{$value}fail} hFq
It rewrites the envelope from as pir!rond@??? and then
gets looked up in the db file and rewritten as rond@???.
The From line also gets looked up and rewritten as rond@???.
This is non-optimal and as envelope rewrites are done first I can't make
it optimal :/
> Ah. I think I see the misconception, and I guess it's my fault for not
> making it clear in the documentation. The order of the rewriting rules
> does not imply that rewriting takes place in the order that might be
> implied by looking at the flags (if indeed it is possible to define a
> unique order that way). For each rewriting instance, those rules that
> apply are applied in order, but that is all.
I wasn't implying the order of rewrites based on the flag order (although
it would be a nice wish :) but I was assuming that every combination
of possible rewrites would happen - bad assumption now I think about it,
but a definition in the spec might help prevent other people making that
bad assumption.
> > If either $header_from: was changed after the rewrite or $header_from:
> > was qualified (but then this may not be the origional header),
> Both of these happen as a result of the rewrite, but it happens after
> the envelope rewrite.
Oh ... *censored*.
> > or there was
> > a flag to qualify unqualified addresses that result from rewrites
> That could be done. I have put the suggestion on the wish list.
Thanks.
> > Is there any way to get access to the qualified version of $header_from:
> > or a way to automaticly qualify an unqualified address in a rewrite rule ?
> Unfortunately at the moment, no, except by complicating the rewriting
> string. For example if your original rule was
This is what I've been playing with so far.
> which will look horrendous, since your X is pretty complicated. The
I've got some very similar looking regexps, but the $2 based qualification
is a nice idea - I'll play with that, thanks.
Yep, the regexp rapidly become horrendous, but they are slightly nicer
if you do it in two stages (since the second stage is being done anyway
onthe from line).
I've been dealing with the qualified case by using the w flag:
user@domain \
"${if match{$header_from:} {^(.*@.*)\\$} {$1} fail}" Fw
since that strips out the extranious things for me. It was all the
unqualified cases I was having problems with (hence wanting the ability
to qualify the resultant domain if it is unqualified, since I could
combine it with the w flag and do it all in rewer rewrite).
1997-12-15 10:38:54 0xhcbe-0002Jr-00 Expansion of ${if match{$header_from:}
{^(.*@.*)\\$}{$1}fail} failed while rewriting: $ not followed by letter,
digit, or {
> > Yes, but then there is an extra shell instance floating around for each
> > mail that is sent. Not a great hardship, but not optimal.
> Not if you end the script with "exec".
I wasn't very clear - the shell instance isn't there for very long, but
it still has to be executed. When the machine gets _really_ loaded even
that small extra exec link in the chain is one I could do without.
I'll be hacking uucp to make it execute exim with the correct options
rather than rmail, I think :/
I'll have to do this anyway to make it use -oMt <nodename> to make logs/
received headers tracable to the uucp node that sent the mail (unless
anyone else dealing with uucp has a better idea).
Thanks,
Peter.
--
Peter Radcliffe | pir@??? | Shore.net systems administrator.
--
*** Exim information can be found at
http://www.exim.org/ ***
