On Tue, 9 Aug 2022, Olaf Hopp (SCC) via Exim-users wrote:
> Dear collegues,
> we moved some internal domains from "olddomain.org" to "newdomain.org"
> we have internal routing for the new and old domain
> Now we want to get rid of the routing for "olddomain.org"
> and I want to rewrite "olddomain.org" to "newdomain.org"
> so "foo@???" should become "foo@???"
> In my rewrite section of exim I use
>
> ^(.*)@(.*)\.olddomain\.org $1@$2.newdomain.org TS
>
> which seems to run fine:
>
> # exim -brw foo@???
> 2022-08-09 16:18:28 "foo@???" from smtp sender rewritten as
> "foo@???" by rule 1
> SMTP: foo@???
> sender: foo@???
> from: foo@???
> to: foo@???
> cc: foo@???
> bcc: foo@???
> reply-to: foo@???
> env-from: foo@???
> 2022-08-09 16:18:28 "foo@???" from env-to rewritten as
> "foo@???" by rule 1
> env-to: foo@???
>
> However, when I activate this, I see the following in my logs:
> 2022-08-09 15:59:22 Rewrite of <foo@???> yielded unparseable
> address: '>' missing at end of address in address <foo@???
> and my routing fails since I have removed the routing for "olddomain.org"
>
> So I modified my rewriting rule to
> ^(.*)@(.*)\.olddomain\.org $1@$2.newdomain.org> TS
> (note the '>') Now it works as expected !?
>
> Anyway with this, I'll get
> # exim -brw foo@???
> 2022-08-09 16:24:33 Rewrite of foo@??? yielded unparseable
> address: malformed address: > may not follow foo@??? in address
> foo@???>
> sender: foo@???
> from: foo@???
> to: foo@???
> cc: foo@???
> bcc: foo@???
> reply-to: foo@???
> env-from: foo@???
> 2022-08-09 16:24:33 Rewrite of foo@??? yielded unparseable
> address: malformed address: > may not follow foo@??? in address
> foo@???>
> env-to: foo@???
>
> What is going wrong here ?
> Exim version 4.94.2 under Debian 11 (Bullseye)
You have:
^(.*)@(.*)\.olddomain\.org $1@$2.newdomain.org TS
The examples suggest that:
*@*olddomain.org $1@$2.newdomain.org TS
would be sufficient.
In particular I doubt that you need the anchoring "^".
Perhaps the extending patterns are forcing $1 to include
the opening "<", so that the matching ">" is never removed ?
This does seem like a bug though.
--
Andrew C. Aitchison Kendal, UK
andrew@???
