Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site plus5.UUCP
Path: utzoo!linus!decvax!decwrl!amd!dual!zehntel!ihnp4!plus5!hokey
From: hokey@plus5.UUCP (Hokey)
Newsgroups: net.mail
Subject: Re: parsing host1!user@host2 - a new idea
Message-ID: <501@plus5.UUCP>
Date: Tue, 16-Oct-84 23:47:42 EDT
Article-I.D.: plus5.501
Posted: Tue Oct 16 23:47:42 1984
Date-Received: Fri, 19-Oct-84 05:42:52 EDT
References: <691@sunybcs.UUCP> <1606@nsc.UUCP> <1608@nsc.UUCP>
Distribution: net
Organization: Plus Five Computer Services, St. Louis
Lines: 75

I was hoping I could stay out of this.  Where do you want to use
these headers?  In the transport address (the stuff sent to rmail)?
what about the addresses used in the From: and To: lines?

The uucp-mail project has addresses these issues in gory detail.  I will
tell you the decisions that have been reached.  I hope I don't get a lot
of mail on this issue because I need to get the new mail software out in
a hurry.  I believe the issues should be aired ASAP.  Many of the others
on the project would rather wait until the software is ready before mouths
are opened.  I am not always wasy to work with.  Many are concerned that
rehashing these issues will unnecessarily delay the project.  I hope I
am not the only one from the project addressing these issues, because I
have code to write.

First, all addresses sent *from* the new software across uucp will be in
strictly bang format.  Mail to user@dom.ain will be converted to dom.ain!user.
This works for almost all of the cases (the exception being explicitly
routed RFC822 addresses across gateways, near as I can tell).  Mail sent
*to* the new software will accept non-hybrid addresses only, because of
the parsing ambiguity.  This means mail to a!b@c.d will be rejected by
the new rmail.  This is necessary because the mail must go through, and
If, Someday, we all end up with RFC mailers, the parsing of addresses
will change and then we are all in trouble again.

Sendmail sites should leave the From: and To: lines *alone*.  There is
a difference between an address and a route.  Non-RFC mailers won't
look at these lines for replies, and they certainly won't update them
when the mail passes through their site!  These addresses should be
in RFC822 format *if you are using an RFC mailer*.  If a non-RFC
mail message passes through an RFC mailer, it *might* add a From:
line and an Apparently-to: line.  The >addresses< on these lines should
probably take the form  "a!b!c"@thissite  and thissite should be qualified
(site.UUCP) if the site is registered with the Uucp Site Registry
(lauren@vortex.UUCP).

This implies that the mailers invoked by sendmail should be able to
handle routing to non-neighbors, by using things like pathalias.  Note
that routing information is added, the addresses are not changed.  Rob
Warnock wrote a very clear discussion on the issue of route optimization
which clearly states the conditions under which paths may be rerouted.

Sites like ihnp4 optimize paths because many people do not have access
to RFC mailers or routing software, so when people reply to news articles
the mail goes along a path which is usually absurd.  My solution to
the problem of Path: replies to mail is for (at least) the first "smart"
registered site in the path to use its fully-qualified name.  This means
it is safe for any other "smart" mailer to optimize directly to the last
fully-rooted machine on the path.  This may be enough to prevent the
"optimization" of explicitly specified paths.  Chuqui can still send
out his looping paths to check path validity and the speed with which
the message travels, without worrying that the path will be "fixed"
for him.

This also means that these smartmailers will handle mail to other domains
as well as recognizing subdomains.  Just think, no more problems with
the duplicate named machines gang, vortex{.DEC,.UUCP}, rigel{.sun.UUCP,
.oddjob.UUCP}, regina{.DEC,.UUCP}, and a host (no pun...) of others!
Leaves you kind of breathless, huh?  This also means that you could
send mail to, say, ucbvax!site.CSNET!user and not have to worry about
the hilarious contortions with csnet-relay.  Specifically, you would
only have to address the mail to *any* convenient smarthost!do.ma.in!user
and it will get there (assuming the addressee exists!).

I have left out a lot of points in my discussion.  These ideas have been
gone over quite thoroughly by many people, and I have done a mediocre
job of covering the issue.  Many of the problems must be solved in
specific places.  The use of parentheses in an address will mess up
most sendmail sites in the universe.  We can leave most of the routing
software alone if we have user-interface mailers which do the job they
are supposed to do, specifically, produce an *appropriately* formatted
mail message with the help of the user.  This stuff must be easy to use,
and should not get in our way.  We are getting there.
-- 
Hokey           ..ihnp4!plus5!hokey
		  314-725-9492