I have
dc_eximconfig_configtype=''smarthost''
# temporarily (?) allow use of unqualified iron
dc_other_hostnames=''iron''
dc_readhost=''biostat.ucsf.edu''
dc_relay_domains=''''
dc_minimaldns=''false''
dc_relay_nets=''''
dc_smarthost=''biostat.ucsf.edu''
dc_local_interfaces=''127.0.0.1.25:127.0.0.1.26''
CFILEMODE=''644''
dc_use_split_config=''true''
dc_hide_mailname=''true''
dc_mailname_in_oh=''true''
This produced these rewrites on the smarthost transport:
headers_rewrite = *@+local_domains $1@DCreadhost frs : *@iron.psg.net
$1@DCreadhost frs
return_path = ${if
match_domain{$sender_address_domain}{+local_domains}{${sender_address_local_part}@DCreadhost}{${if
match_domain{$sender_address_domain}{iron.psg.net}{${sender_address_local_part}@DCreadhost}fail}}}
Which is good, but I really want to get all the headers, including cc or
bcc. Otherwise, when someone hits reply all there may be trouble. I''m
not claiming this is universally desirable behavior, but it seems right
for me.
Oh... maybe dc_mailname_in_oh true = mailname appears in other headers;
if false they get rewritten too?
What''s the best way to achieve this effect? I can''t do it
with standard
rewrites, because before transport my addresses look like
foo@iron.psg.net. I''m not wed to that scheme, but it seemed safer than
rewriting everything immediately to foo@biostat.ucsf.edu, which would
essentially make it as if my machine were masquerading as a different
one.
Also, I''m not sure why the rewrite rules with iron.psg.net are present;
I would expect that to be one of the local_domains.
--
Ross Boylan wk: (415) 514-8146
185 Berry St #5700 ross@biostat.ucsf.edu
Dept of Epidemiology and Biostatistics fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm: (415) 550-1062
On Fri, Oct 07, 2005 at 12:01:06PM -0700, Ross Boylan wrote:> This produced these rewrites on the smarthost transport: > headers_rewrite = *@+local_domains $1@DCreadhost frs : *@iron.psg.net > $1@DCreadhost frs > return_path = ${if > match_domain{$sender_address_domain}{+local_domains}{${sender_address_local_part}@DCreadhost}{${if match_domain{$sender_address_domain}{iron.psg.net}{${sender_address_local_part}@DCreadhost}fail}}} > > Which is good, but I really want to get all the headers, including cc or > bcc. > Otherwise, when someone hits reply all there may be trouble. I''m > not claiming this is universally desirable behavior, but it seems right > for me.I think that we shouldn''t go too far with rewriting. What we _need_ to do is take care that the message goes out with a correct sender (mostly to take care about bounces being sent to the correct recipient), but I don''t think that we should interfere with message recipients as well. The "trouble" would be a bounce, as if our local user had written a differently broken address into Cc:. Rewriting Bcc is not an option anyway since Bcc gets removed anyway before the message is sent.> Oh... maybe dc_mailname_in_oh true = mailname appears in other headers; > if false they get rewritten too?Please explain what you mean, I do not understand.> What''s the best way to achieve this effect? I can''t do it with standard > rewrites, because before transport my addresses look like > foo@iron.psg.net. I''m not wed to that scheme, but it seemed safer than > rewriting everything immediately to foo@biostat.ucsf.edu, which would > essentially make it as if my machine were masquerading as a different > one. > > Also, I''m not sure why the rewrite rules with iron.psg.net are present; > I would expect that to be one of the local_domains.Please elaborate. I am missing much of your context here. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don''t trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
On Sun, 2005-12-18 at 19:16 +0100, Marc Haber wrote:> On Fri, Oct 07, 2005 at 12:01:06PM -0700, Ross Boylan wrote: > > This produced these rewrites on the smarthost transport: > > headers_rewrite = *@+local_domains $1@DCreadhost frs : *@iron.psg.net > > $1@DCreadhost frs > > return_path = ${if > > match_domain{$sender_address_domain}{+local_domains}{${sender_address_local_part}@DCreadhost}{${if match_domain{$sender_address_domain}{iron.psg.net}{${sender_address_local_part}@DCreadhost}fail}}} > > > > Which is good, but I really want to get all the headers, including cc or > > bcc. > Otherwise, when someone hits reply all there may be trouble. I''m > > not claiming this is universally desirable behavior, but it seems right > > for me. > > I think that we shouldn''t go too far with rewriting. What we _need_ > to do is take care that the message goes out with a correct sender > (mostly to take care about bounces being sent to the correct > recipient), but I don''t think that we should interfere with message > recipients as well. > > The "trouble" would be a bounce, as if our local user had written a > differently broken address into Cc:.The trouble I was thinking of is that some people won''t get the reply.> > Rewriting Bcc is not an option anyway since Bcc gets removed anyway > before the message is sent.exim does have an option to rewrite the bcc fields. bcc does seem less important, since nobody should see the bcc field, so they can''t be misled by it.> > > Oh... maybe dc_mailname_in_oh true = mailname appears in other headers; > > if false they get rewritten too? > > Please explain what you mean, I do not understand.I was guessing at what cd_mailname_in_oh does: that it controls whether the mailname appears in other headers. I further guessed that if it were false the rewriting might be more extensive. The second guess is not too plausible, given the first. More generally, I was wondering if there are some Debian supplied buttons to tweak that control which mail headers get rewritten.> > > What''s the best way to achieve this effect? I can''t do it with standard > > rewrites, because before transport my addresses look like > > foo@iron.psg.net. I''m not wed to that scheme, but it seemed safer than > > rewriting everything immediately to foo@biostat.ucsf.edu, which would > > essentially make it as if my machine were masquerading as a different > > one. > > > > Also, I''m not sure why the rewrite rules with iron.psg.net are present; > > I would expect that to be one of the local_domains. > > Please elaborate. I am missing much of your context here.Some of this we discussed in December''s "order of file concatenation" thread. However, this thread focuses on the Debian configuration settings as a possible way to solve the same problem. The general problem is that my system is now in a domain that doesn''t exist in the public internet (psg.net). External mail needs to go to the publicly known biostat.ucsf.edu domain. So I, and potentially other users on this machine, and potentially other addresses in this private domain, need to be rewritten for stuff that goes out to the general internet. I''ve cobbled together something that works, but I''ve done that mostly behind the back of the debian configuration settings. I was wondering if there was a way to achieve the same effect with those settings. For those whose memories don''t extend back to my original post in October (!), here is my configuration: dc_eximconfig_configtype=''smarthost'' # temporarily (?) allow use of unqualified iron dc_other_hostnames=''iron'' dc_readhost=''biostat.ucsf.edu'' dc_relay_domains='''' dc_minimaldns=''false'' dc_relay_nets='''' dc_smarthost=''biostat.ucsf.edu'' dc_local_interfaces=''127.0.0.1.25:127.0.0.1.26'' CFILEMODE=''644'' dc_use_split_config=''true'' dc_hide_mailname=''true'' dc_mailname_in_oh=''true''
On Tue, 2006-01-03 at 13:14 -0800, Ross Boylan wrote:> On Sun, 2005-12-18 at 19:16 +0100, Marc Haber wrote: > > On Fri, Oct 07, 2005 at 12:01:06PM -0700, Ross Boylan wrote:....> > > > > Oh... maybe dc_mailname_in_oh true = mailname appears in other headers; > > > if false they get rewritten too? > > > > Please explain what you mean, I do not understand. > I was guessing at what cd_mailname_in_oh does: that it controls whether > the mailname appears in other headers. I further guessed that if it > were false the rewriting might be more extensive. The second guess is > not too plausible, given the first.I''ve belatedly remembered that some of these issues are now, or soon will be, addressed in the documentation. See also bug 332520, which answers some of these questions. dc_mailname_in_oh is for internal use only, and doesn''t have the functions I speculated about. There don''t seem to be any options that would extend rewriting beyond the headers selected by headers_rewrite. That variable only matters if you have selected smarthosting. Rewritten headers are frs (from, reply to and sender in the message headers--not cc) and the envelope sender. Ross