On 2007-12-18 at 13:41 -0500, Matthew Soccio wrote:
> I am testing a new server, which has the same user and auth data as the
> production server. I need a way to make sure that mail for my beta
> testers stays on the beta server, while everything else goes over to the
> production server. Since I am currently the only user, this rewrite
> rule has done the trick:
Exim doesn't route email by rewriting addresses; instead, it has rules
describing candidates for handling a particular address, those rules
being called Routers. Trying to handle this in Rewriting will create an
unmanageable mess.
Exim's documentation, The Exim Specification, is the best of any
software product I've used. It's available online in HTML (look on
www.exim.org) or as "spec.txt" in the distribution. Look at section 3,
which explains how Exim goes about its work; Exim is not Sendmail and
using sendmail-style rewriting to accomplish routing decisions will just
cause you grief.
Have cse.psu.edu listed in the domain list conventionally called
"local_domains", either don't have psuvax1.cse.psu.edu handled locally,
or perhaps have it in the "relay_domains" address list, as appropriate.
Then, in the Routers section, the ordered list of Routers to try, have
something like this (untested) before the Router which handles local
delivery:
psuvax:
driver = redirect
domains = +local_domains OR cse.psu.edu explicitly
local_parts = !/etc/exim/betausers
local_part_suffix = +*
local_part_suffix_optional
data = ${quote_local_part:$local_part}@???
Note that psuvax1.cse.psu.edu can go to a macro at the start of the
config file; the local_part_suffix options allow you to use +suffix
addressing and can be ignored if you don't use that.
/etc/exim/betausers should have one item per line and can be any type of
Exim list item. You can use "soccio" to match the LHS of soccio (or,
soccio+foo, with the optional suffix), ^soccio to match any LHS
_starting_ soccio, etc.
So, "if it's for a local domain and the LHS is not in this list, then
route it to this new address"; that new address will then be routed
normally and probably hit your !+local_domains remote SMTP Router; if
you're using a smarthost setup, you'll need to explicitly handle the
psuvax1.cse.psu.edu domain directly, otherwise, being routed normally,
the mails will go to the smarthost which would then be expected to
handle psuvax1.cse.psu.edu.
If the user is in betausers, the Router's preconditions will decline to
accept the address and the next (and subsequent) Routers will be tried.
Regards,
-Phil
