At present exim applies the /etc/email-addresses rewriting mechanism
to all mail sent through the MTA. This causes interference with a
setup that permits both local exchange of mail among local users and
mail sent out to remote destinations either by the remote_smtp or
remote_smtp_smarthost transports.

Note that in the configuration captured in this report represents a
smarthost setup. Any mail not destined for a local user must be sent
out through the designated smarthost. I have another computer that can
make direct SMTP connections to non-local hosts and hence does not use
the smarthost setup, but it suffers the same problem reported here.

When I send a message out from my computer to a remote recipient, I
want any mention of my local user name and host replaced with my
externally-visible email address; I have this mapping defined as
expected in /etc/email-addresses. However, for local mail, I do not
want my From address to be rewritten. The local messages do get
delivered properly, but if the recipient replies without editing the
To address, the message goes out to my externally-visible address
unnecessarily. Also, the rewriting in this case changes the facts: The
local messages look like they came from a remote sender, despite being
sent from a local account.

Supporting this rewrite-only-for-non-local scheme requires that the
/etc/email-addresses rewrite rule be moved to the transport's
"headers_rewrite" entry, as suggested in the Exim FAQ (Q0803). I use
this technique in an older hand-crafted exim.conf on Cygwin and it
works as desired. I'm just surprised to see that the Debian
exim4-config package doesn't offer this choice.

There is an optional facility offered now to mask the local host name
with an alternate "visible" host name. When selected, this option adds
a headers_rewrite entry to the remote_smtp* transports. This option
does not support my scheme; my computer is not visible externally and
is not meant to receive non-local messages directly.

Though I can't provide a patch today for the debconf mechanism, I can
at least sketch some proposed changes.

  o For setups that permit non-local outbound mail, ask the user
    whether he wants per-user rewriting (via /etc/email/addresses),
    global rewriting (the current "visible host" option), or no
    rewriting.
  o If either of the first two rewriting options are chosen above,
    place an appropriate headers_rewrite entry in each of the
    remote_smtp* transports.
  o Remove the current global /etc/email-addresses rewrite rule.

I found mention of a similar proposal in Bug 229911, but the
submitter's proposal to limit the /etc/email-addresses rewriting was
not properly addressed in the discussion that followed.

tags #309792 confirmed
thanks

This might have been caused by the fact that the submitter didn't care
enough to participate in the discussion after dumping the bug report.

Your argumentation makes sense, and I have put this bug on the list of
things to be considered post-sarge.

Greetings
Marc

tags #309792 confirmed
thanks

This might have been caused by the fact that the submitter didn't care
enough to participate in the discussion after dumping the bug report.

Your argumentation makes sense, and I have put this bug on the list of
things to be considered post-sarge.

Greetings
Marc

Marc Haber <mh+debian-packages@zugschlus.de> writes:

Thank you for following up. Consider me available and interested in
the forthcoming discussion and testing.

user exim4@packages.debian.org
usertags #309792 pending-maintainer-discussion
thanks

Hi,

Steven E. Harris, le Mon 30 May 2005 19:43:49 -0700, a écrit :

How is this going ?  I've just lost a bunch of emails just because
my smarthost was broken and that all bounces where going to
root->samy->samuel.thibault@ens-lyon.org, hence lost too...

Samuel

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:

This is the first feedback I've heard since I wrote the message you
referenced back in May 2005, and Mr. Haber updated the tags in Januar
2006. I'll have to defer to one of the Exim maintainers to comment.

The problem is that we already use headers_rewrite and return_path on
transport level to hide the system mailname if the user desires so.
Integrating both features seems to be an, uh, "interesting endeavour".

Thus, this is one more example for an exim FAQ not being easily
integrateable into the packaging.

The scheme mentioned here was not implemented by myself, and since my
mail servers are usually on official IP addresses reachable from the
Internet, I do not have a use case for either scheme. I am therefore
somehow at a loss to define what's exim supposed to do in which case.

How is, for example, exim supposed to behave when a local account does
not have an entry in /etc/email-addresses? Is exim supposed to fall
back to the result of the "hide mailname" rewriting, if selected? I
guess that this is the behavior we currently have with the
/etc/email-addresses rewriting done in the rewriting section.

Spelling this behavior out in the transport is a major effort, my
current test setup has like 20 lines of .ifdef, ${if and various
lookups.

For starters, the old scheme is going to stay in, but can be disabled
by setting an exim macro from local configuration. The new scheme will
be disabled by default, and can be enabled by setting an exim macro
from local configuration. This way, we can be reasonably sure not to
break existing setups while we investigate whatever consequences the
new scheme has on existing setups.

In no way this is going to get its own debconf question. We are asking
too many questions already. Being easily enabled from local
configuration is the most you're gonna get. Sorry, but you'll have to
touch a text editor to get this scheme enabled.

Greetings
Marc

The problem is that we already use headers_rewrite and return_path on
transport level to hide the system mailname if the user desires so.
Integrating both features seems to be an, uh, "interesting endeavour".

Thus, this is one more example for an exim FAQ not being easily
integrateable into the packaging.

The scheme mentioned here was not implemented by myself, and since my
mail servers are usually on official IP addresses reachable from the
Internet, I do not have a use case for either scheme. I am therefore
somehow at a loss to define what's exim supposed to do in which case.

How is, for example, exim supposed to behave when a local account does
not have an entry in /etc/email-addresses? Is exim supposed to fall
back to the result of the "hide mailname" rewriting, if selected? I
guess that this is the behavior we currently have with the
/etc/email-addresses rewriting done in the rewriting section.

Spelling this behavior out in the transport is a major effort, my
current test setup has like 20 lines of .ifdef, ${if and various
lookups.

For starters, the old scheme is going to stay in, but can be disabled
by setting an exim macro from local configuration. The new scheme will
be disabled by default, and can be enabled by setting an exim macro
from local configuration. This way, we can be reasonably sure not to
break existing setups while we investigate whatever consequences the
new scheme has on existing setups.

In no way this is going to get its own debconf question. We are asking
too many questions already. Being easily enabled from local
configuration is the most you're gonna get. Sorry, but you'll have to
touch a text editor to get this scheme enabled.

Greetings
Marc

I am forwarding this to pkg-exim4-users to solicit the opinion of the
user base. Origimal bug report not snipped to give the others full
view of the request.

The rewrite rule rewrites also the recipient and the sender, which the
normal headers_rewrite approach does not. I am also reluctant to add
another headers_rewrite to both external transports.

The exim4-config package already has too many options.

I am reluctant to change the behavior of the package in a way that is
so hard to understand. Implementing this will cause confusion with a
lot of users.

pkg-exim4-users, what do you think?

Greetings
Marc

I am forwarding this to pkg-exim4-users to solicit the opinion of the
user base. Origimal bug report not snipped to give the others full
view of the request.

The rewrite rule rewrites also the recipient and the sender, which the
normal headers_rewrite approach does not. I am also reluctant to add
another headers_rewrite to both external transports.

The exim4-config package already has too many options.

I am reluctant to change the behavior of the package in a way that is
so hard to understand. Implementing this will cause confusion with a
lot of users.

pkg-exim4-users, what do you think?

Greetings
Marc

by default, so I could not send mails but the warnings about delivery
problems where sent do my external email address (from /etc/email-addresses)
and could not be delivered as well ...

My exim4 version: 4.69-9

Jens