Path: utzoo!attcan!uunet!lll-winken!ames!haven!aplcen!jhunix!ecf_hap
From: ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling)
Newsgroups: comp.mail.sendmail
Subject: Re: Rewriting aliased adresses for uucp delivery
Summary: just say no to the "C" flag
Keywords: C flag
Message-ID: <1180@jhunix.HCF.JHU.EDU>
Date: 20 Mar 89 18:27:53 GMT
Expires: 19 Apr 89 23:00:00 GMT
References: <2137@marconi.sw.mcc.com>
Reply-To: andy@gollum.hcf.jhu.edu (Andy Poling)
Followup-To: comp.mail.sendmail
Organization: The Johns Hopkins University - HCF
Lines: 39

In article <2137@marconi.sw.mcc.com> knutson@marconi.sw.mcc.com (Jim Knutson) writes:
>I'm having a problem with rewriting the To: field when using an
>alias that includes delivery to a uucp neighbor.
[...]

>From: peyote.cactus.org!knutson (Jim Knutson)
>To: members-at-large
>
>When the message was finally delivered on milano, the message header
>looked like:
>
>From knutson@peyote.cactus.org Fri Mar 17 15:46:38 1989
>From: knutson@peyote.cactus.org (Jim Knutson)
>To: members-at-large@milano.sw.mcc.com
>
[...]

>3. Will the C flag on someones uucp mailer definition solve this and if so
>   who needs the change (milano, right?)?


It looks to me like milano is probably doing this in either their sender
ruleset or ruleset 4.  Milano probably sees this unqualified address going
out and tacks on it's (milano's) name assuming that it's (members-at-large)
a local name.  That's what my machine would do - is this wrong?

On the subject of the "C" flag: why is it applied (apparently) after all of
the rulesets?  In my config, this results in all "To:" addresses on the
local machine, which have been stripped of our hostname, getting the
sender's host.domain appended to them.  For that matter, when would this
flag actually be helpful?



Andy

andy@gollum.hcf.jhu.edu
ecf_hap@jhunix.UUCP
ecf_hap@jhuvms.BITNET