On 2008-06-24 at 19:14 +0100, Chris Edwards wrote:
> On Tue, 24 Jun 2008, Phil Pennock wrote:
>
> | > | max_rcpt = 1
> | > | headers_rewrite = *@*
> | > | ${lookup{$local_part@$domain}lsearch{/etc/mail/subaddress-maps/$1@$2}{$value}fail} f
> |
> | Plus the line you quoted in the mail further down:
> | In the header rewrite, use $1 as originally stated.
>
> But shurely $1 also is the local_part of the sender ?
> (as we're rewriting a sender address)
This is getting embarrassing. Re-reading what I wrote before, no, I did
mean $local_part but you found out I was wrong.
Spec 31.4 has the bit I forgot:
----------------------------8< cut here >8------------------------------
The variables $local_part and $domain can be used in the replacement string to
refer to the address that is being rewritten.
----------------------------8< cut here >8------------------------------
Setting up a test environment is more hassle than I want just now; I've
just checked and the rewrite code doesn't appear to adjust
$parent_local_part or $original_local_part. How useful those are depend
upon what redirection has already happened. If you're not already using
address_data, then one workaround is to preserve $local_part or
$local_part@$domain in the address_data option on the Routers and
pull it back out again via $address_data (or ${local_part:$address_data}
) in the Transport.
$parent_/$original_ have the downside of being potentially fragile
depending upon other Routers.
$address_data has the downside of needing to be set on every Router
using this transport and preventing you from using it otherwise.
> So it would seem to not matter whether I use $1 or $local_part. Neither
> correspond to the message recipient :-(
>
> Sorry if I'm being thick!
You weren't. I was being both thick and forgetful.
-Phil
