On Thu, 1 Dec 2005, Mike Pinna wrote:
>
> Many other addresses on the system are rewritten, but that shouldn't be
> relevant in this case. I don't think my rewriting setup is doing
> anything strange such as causing different originator addresses to be
> treated differently. My rules are as follows:
I'm generally very dubious of rewrite rules, because it is difficult to
control in which situations they are applied. In most cases you can get a
better effect using just routers, and perhaps using the headers_rewrite
option on the transport. (The other thing to investigate is the rewriting
done by the dnslookup router, but that's somewhat magic.)
Unlike web redirects, email address rewriting isn't very effective at
enforcing a branding policy. For example, if you have a colleague who is
sending email with the domain nexus.co.uk and your policy is to require
receiva.com, it's probably best to get them to fix their MUA configuration
rather than magically transform their messages without their knowledge. In
the other direction, it may be useful for your colleagues to know which
external contacts are using the deprecated domain name when sending email
to you.
> When I try and send a message to the address in question though, the
> address gets rewritten anyway, as follows:
I suggest doing this test using `exim -d+all-memory -bh 127.0.0.1`. This
will give you a trace which should be enlightening.
Your config file sounds complicated, so yes it would probably help if you
can publish it. A high-level description of what you are trying to acheive
would be useful too (e.g. policy requirements).
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
