Bug#229911: Should delay address rewriting until absolutely necessary
On 2004-04-10 Wouter Verhelst <email@example.com> wrote:
> However, what really should happen, is something where exim does the
> rewriting at the last possible moment; it should not do any rewriting up
> until the moment that it decides there's no other sane thing to do than
> to rewrite the address (when the mail gets sent to another system).
> That would end you up with two possible situations:
> * Either the mail is to be delivered locally, and no rewriting is done
> at all,
> * Or the mail is to be delivered remotely, and your return path and any
> source addresses are rewritten.
> This should be done by using the header_rewrite and/or return_path
> option(s) in the transport that sends the mail off to somewhere else; it
> cannot be done by using the rewriting block (as that will do rewriting
> before it's decided that mail might be delivered remotely).
> This way, mail which is to be delivered locally will still be delivered
> locally, whereas mail that is to be delivered remotely will be rewritten
I'll try to sum up what the problems are first.
Exim currently support these setups.
A computer that sends outgoing mail via smarthost but otherwise
behaves like a fully fledged internet-host (no rewriting by default).
No local delivery, anything is passed on to a central mailhub, after
#229911 is a feature request for "split horizon"
* deliver local_user@+local_domains locally.
* pass on anythingelse@+local_domains to smarthost
rewrite *@+local_domains to *@some_visible_name
*If* I wanted to implement this the only thing (exim.conf-wise, the real
sucker is integrating into the debconf questions) really necessary is
a router that is invoked after every other router and throws
undelivered stuff to the smarthost. (Similar to hub_user, but
unrestricted and invoked later). Whether doing rewriting at transport
time in this router is necessary depends on whether
"some_visible_name" is local or not. If it is local normal rewriting is
sufficient. And not making it local does not buy anything.
But I consider this szenario (Basically: I want to deliver
firstname.lastname@example.org locally because there are _lots_ of users on this box
and hotmail.com is unreliable) to be not important enough to be
The real problem is this, as perceived by Chris Cheney:
| Also the question for /etc/mailname isn't clear I think it should be the
| hostname of the box they are configuring, right? If you set it to the
| domain name of your mail provider then exim thinks all users are local.
| If you set it to your hostname then it doesn't do rewriting!
What is /etc/mailname's purpose? What should I set /etc/mailname to if
I have my own domain (downhill.at.eu.org) but it is hosted somewhere
else? What should I use if I have not got a domain but only a bunch of
e-mail addresses (@gmx.at, @debian.org and @work)?
#244095 documents another side of the issue.
My latest idea is to interpret /etc/mailname as "name visible in mail
leaving the machine" and implementation would look like this:
#1 Stop setting qualify_domain=mailname except for "internet" and
"local mail only" use the normal fqdn instead.
#2 Do not make mailname part of local_domains except for "internet"
and "local mail only".
#3 Rewrite *@+local_domains to $1@mailname in the remote_smtp
transport for smarthost/satellite.
 Perhaps by pushing it to the respective other_hostnames for
internet/local in debconf, but this would break badly when switching
profiles with dpkg-reconfigure.
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"