Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!nike!ucbcad!ucbvax!decvax!tektronix!uw-beaver!ubc-vision!alberta!ncc!lyndon
From: lyndon@ncc.UUCP
Newsgroups: net.mail,net.mail.headers
Subject: Re: Do you rewrite "From:" lines?
Message-ID: <736@ncc.UUCP>
Date: Tue, 30-Sep-86 16:57:47 EDT
Article-I.D.: ncc.736
Posted: Tue Sep 30 16:57:47 1986
Date-Received: Sat, 4-Oct-86 11:05:20 EDT
References: <358@tc-jeff.fluke.UUCP>
Distribution: net
Organization: Nexus Computing Corp.,  Edmonton, AB
Lines: 78
Xref: watmath net.mail:1999 net.mail.headers:814

In article <358@tc-jeff.fluke.UUCP>, jeff@fluke.UUCP (Jeff Stearns) writes:
> Now that I've installed smail, a nasty question comes up.  Should our sendmail
> modify "From:" lines?
> 
> Background:
>     We're a uucp site with a dozen or so neighbors.  We're running Berkeley
>     UNIX with sendmail.  We just installed smail.
> 
>     Our standard sendmail rewrites "From" and "From:" lines.  Specifically,
>     it prepends our sitename to the address.  This is standard practice here
>     in uucp-land.  All of our uucp neighbors do it, too.
> 

NOT true! (see comments later)

> The problem:
>     I've just installed smail.  We're getting domain-ized.  We're trying to
>     make a separation between domain addresses and uucp routes.
> 
>     What to do with the "From:" line?
> 
>     I believe that the theoretically correct answer is this:
> 	Don't touch the "From:" line at all.  Do your playing with the
> 	"From" line, so that "From" can indicate a valid UUCP path,
> 	leaving the sender's domain address in "From:".
> 	(That last part is a quote from the smail manual page.)
> 
> 	And this is what smail does.
> 
> But all of our neighbors tack their sitename onto the "From:" line as well!
> There's gonna be lots of unreplyable(?) mail if we start playing by The Right
> Rules while everybody else is Doing What The Majority Does.  (Recall that
> 4.2BSD /usr/ucb/mail sends replies to the "From:" address, not the "From"
> address.)
> 
> What's a mother to do?
> -- 
> 	Jeff Stearns       (206) 356-5064
> 	John Fluke Mfg. Co.
> 	P.O. Box C9090  Everett WA  98043  
> 	{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff

Our configuration is a Convergent MiniFrame running SYS_V with NO sendmail
(yes people, there are a *lot* of machines that don't have the foggiest
idea about sendmail :-).

None of our mailers understands RFC822. All interaction takes place on the
"From " headers; The "From:" lines are passed untouched. Strange things
begin to happen when I receive mail from site 'a' (4.2BSD) destined for
site 'b' (also 4.2BSD). When 'b' receives the mail, the "From " line
contains a path of "ncc!a!...", but the "From:" line has "a!...".
When b!user tries to reply to the message, it generates a return address
from the "From:" line of "a!..." which is obviously incorrect as the mail
has to go through "ncc" to get to "a".

What to do? There are two options that come to mind. First, "b" can ignore
"From:" info, and construct return paths from "From " lines. This maintains
compatibility with the dumb *dumb* DUMB Sys_V mailers. It also allows me to
continue acting as a mail gateway between 4.2BSD systems. The second option
is to use smail/pathalias. When "b" tries to reply directly to "a", the
pathalias database will be invoked to find a path to "a". Unfortunately,
the default configuration only forces a lookup if the address is of the
form "a!b". If the reply was really destined for "a!c!d", the lookup is
bypassed. To start messing with the compile time options in smail *will* fix
this problem, but strange things start happening as nearly everything
gets re-routed.

I have thought about building RFC822 into smail (and aliases, and intelligent
network gateways, ...). It's about time Sys_V caught up with the rest of
the world with respect to mailers. The only problem here is that I keep
hearing that "it's coming in the next release on **IX". Arrgh!

I would like to hear from other SA's who have run into this problem. The
*must* be a reasonable method for dealing with this...
-- 

Lyndon Nerenberg (VE6BBM) 	  {ihnp4,ubc-vision,watmath}!alberta!ncc!lyndon
Systems Group - A Div. of Nexus Computing Corp.  		Envoy_100: Unix