Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site plus5.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!decvax!harpo!whuxlm!whuxl!houxm!mhuxt!mhuxr!mhuxn!ihnp4!plus5!hokey
From: hokey@plus5.UUCP (Hokey)
Newsgroups: net.mail.headers
Subject: From: and To: in UUCP land
Message-ID: <835@plus5.UUCP>
Date: Thu, 15-Aug-85 00:02:56 EDT
Article-I.D.: plus5.835
Posted: Thu Aug 15 00:02:56 1985
Date-Received: Tue, 20-Aug-85 01:22:51 EDT
Organization: Plus Five Computer Services, St. Louis
Lines: 108
Keywords: RFC822, reality, anarchy, 42, UUCP

It is starting again.  Plus Five is seeing bizzare headers, and I would really
like to get the beasts to be consistent.

For starters, we have suddenly started geting hybrid routes in >From lines.
Additionally, different sites are changing their behavior on From: line
munging.

I have several proposals.  I would greatly appreciate constructive feedback.
These all pertain to UUCP land only, and are significant because many UUCP
sites use sendmail.

1)  No @ in UUCP transport layers.  I would hope that Arpa gateways would
convert the arpa path to ! format relative to their site.  I am even
advocating the gateway change user%site.csnet@csnet-relay to site.csnet!user.
Likewise for Bitnet.

2) No prepending the local site name to the From: line.  This is wrong for
several reasons.  One of the reasons is that not all sites along the route
may be able to do this, and a reply along that path may therefore fail.
Another reason is that many sites keep this field in @ format, in which case
the prepending will result in an erroneous route.  Additionally, the From:
line must clearly be parsed with @ having higher precedence over !.  I
suspect a quoting mechanism could be used to avoid this problem, or sites
could use 822 source routing, but that seems kinda dull.

3) No @ in From: or To: lines, either.  This might be viewed as a radical
proposal.  I submit it is necessary because many sites violate 2), and even
if they don't, Somebody's mailer will do a reply to the recipients and will
end up with a hybrid route which has an excellent chance of being mis-parsed.

4) Please don't automatically qualify uucp sites with .uucp, and then either
leave this qualification in place, or strip it off.  If the mail arrived
with a .uucp on an address, leave it there.  If it did not arrive with a .uucp,
then don't put one there.  This request may not apply to gateways.  If you
want to qualify unqualified uucp sites, please do it with .luucp or .uux,
and then *strip it off*.  This will still permit you to isolate uucp mail
in your .cf file, but it will *not* get out to mess up others.

There are several problems for which I have no immediate solution:

1) name qualification.  Someday I will try to understand sendmail's C mailer
flag.  I am told it hardcodes @ format.  In sites with one host, it can be
pleasant when local users remain unqualified.  However, these user names
*should* be fully qualified when they leave the local site.  At sites with
multiple hosts, it can be useful to qualify names to the "gateway" machine,
so routing to local users can be performed by the gateway machine.  This
is also useful if people access several hosts, or if host names change
frequently.

2) Binmail explicitly source-routes everything.  822 mailers like to route
implicitly.  This has ramifications from 1) above.  Sites which only use
binmail don't need to qualify local recipients, because the explicit source
routing of replies will always deliver the mail correctly, although subsequent
replies will cause the path to grow and grow...

Please note that by qualifying the sender and recipient that explicit source
routing will still work.  It just means that the generated return path can
be optimized a bit.

Binmail will generate To: lines if there is more than one recipient.  It
does not generate a From: line.  It is possible that this information could
be used to properly qualify unqualified addresses when the message hits a
sendmail site.

And now for some general points.  The domain ! format can be very useful
in keeping paths short, and permits sites to route to the best of their
ability.  The decision to hack the >From line to supply additional routing
information can be handled at both the sendING (not the sendER) site or
the receiving site.  An example will be useful.

Let's say user@site.EDU wants to send me mail, and for some reason the route to
me goes through seismo to wucs to plus5.  If seismo know that wucs is "smart",
seismo can use ">From site.EDU!user" instead of "From seismo!site.EDU!user".
Similarly, if wucs is smart, and it "knows" seismo is a gateway, wucs can
take ">From seismo!site.EDU!user" and remove the "seismo!" portion.  Then,
wucs can either prepend its name to the >From line or not, based on policy
or knowledge.  Therefore, if I am a dumb site, a reply from plus5 will route
tha mail to wucs.  If plus5 is smart and it strips "wucs!" from the route,
then a reply will go to site.EDU via the best path from plus5, which happens
to be direct to seismo, not via wucs.  Note that this scheme will correctly
process multiple recipients on different hosts.

Since both approaches seem to be equivalent, I suspect the least amount of
work will be done if each site prepends its name to the >From line, and
smart neighbors decide when to strip off the relay.

Note that I am a middle-of-the-road extremist here.  I "know" that routes
to users on"internal" machines (princeton!down!honey or sun!grodish!guy)
have "famous" sites at the head of the chain.  In the interests of keeping
a minimum number of sites along each address, I maintain these "root" (or
bridge/gateway) machines should use a domain name in order to explicitly
root the address of the user (even down.fun!honey would be swell).  Again,
if sites along the route take care to strip relays, paths will stay short.
This means, for example, that by the time Mark's mail leaves ihnp4 on its
way to me, it won't say "ihnp4!cbosgd!cbpavo.ATT.UUCP!mark", it will say
either "cbpavo.ATT.UUCP!mark" or, at worst, "ihnp4!cbpavo.ATT.UUCP!mark".

I would like to make two final points.  First, I have *no* desire to pick
on any of the people or sites I have listed in this article.  I am not
throwing stones at anybody;  I am trying to make (and understand) several
issues surrounding mail.  Second, I do not believe that implementing my
proposals will solve all the problems we face.  I do believe that by
implementing these proposals we will learn enough to make the effort
worthwhile.

-- 
Hokey           ..ihnp4!plus5!hokey
		  314-725-9492