Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.mail
Subject: Re: More thoughts on mail relays
Message-ID: <1761@peora.UUCP>
Date: Fri, 1-Nov-85 08:35:40 EST
Article-I.D.: peora.1761
Posted: Fri Nov  1 08:35:40 1985
Date-Received: Sun, 3-Nov-85 05:01:04 EST
References: <1813@umcp-cs.UUCP> <1746@peora.UUCP> <909@plus5.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 141

> JER, I'm sorry you spent 2 weeks making MH.5 run under SysV.  MH.6 requires
> almost no effort, and should be out very soon.

You've obviously never tried to order an outside piece of software from
within a large software organization!  It was no problem, really... much
of the time was spent in porting our router and nameserver.  I had promised
earlier to write an article on porting MH.5, but then Mr. Rose wrote and
told me that MH.6 was coming out soon, so I decided not to.

Anyway, to turn to the issues you raised...

I can certainly appreciate the arguments against using "@'s" in UUCP
routing strings.  I strongly disagree with calling them "hybrid addresses,"
however, because they are not addresses, they are routes, and they are
not hybrid, since "@" doesn't mean anything to any but a few modified Unix
sites.

> I wonder who else has tried to sway you toward our perception of reality.

No one.  The funny thing is, it seems to be a vocal minority who advocate
giving "@" special status in the routing language.  Thus the only people
who have tried to convince me (other than the folks at Seismo) are the
ones who have written in here.

>   Implementation #1: Permit hybrid routes, and make everybody parse them
>     the same way.
>   Problems: Doesn't work at gateways.

It does, too.  But we've been over this so many times, algorithms and all,
that I'm tired of reiterating it.

>   Requires smart mailers in lots of places, or requires users to know
>   how to specify the route.

No it doesn't... it doesn't require any more smartness to write in one
routing language than the other... what's the difference between (assuming
a site that only has Unix mail and no router) writing

	petsd!vax135!ucbvax!sam@slowvax.ARPA
or
	petsd!vax135!ucbvax!slowvax.ARPA!sam

It just involves permuting the last two name tokens, and replacing the last
@ with a !.

>     Falls apart when a site decides to become a gateway, because the
>     routing rules change for everybody who passed mail through that site.

No it doesn't... this site presently is not a gateway, however it is a
domain nameserver and a site many people route through here in Florida.
However, I wrote the router with the intent that someday it would become
a gateway, since we have machines here that are not on the UUCP network.
If we ever make that conversion, I will have to add the change to rmail
which the person at NCR in Torrey Pines recommended awhile back, whereby
the domain table also specifies the program to run to exit the UUCP network
(there's even an unused field in the domain table for that purpose... many
people have been trying to guess what it's for).  Presently it's much
simpler; since the original code didn't support the ..!slowvax.ARPA!...
syntax (although I agree that that is a good addition) it was not necessary
to give any special handling, so when the "!'s" ran out, I would route it
out of the network and into the inter-network delivery program.  The model
I presently use is that the local mail system is a separate network;
under this model, all sites are "gateways", and this is entirely reasonable,
very regular and orthogonal.  With the new syntax, when it does a domain
lookup it needs to also decide whether it's time to leave the UUCP network,
which there's a field but no code for yet.  But the syntax will not change.

>  Requires *everybody* who is accepting either ! or @ mail to make sure
>  they follow the "rules", and possibly change the way they parse.  This
>  last bit means work for the admin, and an overall education program for
>  lots of people.  It has not been demonstrated that this implementation
>  is even workable, due to the problems of routing *through* gateway sites.

In fact, this is exactly the problem with the no-@ approach.  Presently
everyone follows the "rules" automatically, except at a few sites; and
Gene Spafford just posted a Sendmail configuration file that makes the
sendmail sites work too.  However, now it is being proposed to distribute
a new program that imposes new rules (an excellent program, I understand,
and not one I am criticizing except on this one minor point).

There also should be no problem with routing through gateway sites.  The
problem you are alluding to, I think, is the one in which some gateway
sites route all their mail through Sendmail, and have sendmail always
give "@" precedence.

As for requiring additional education for people... people are now using
a particular syntax to reach the ARPAnet, for example.  Soon it won't work
any more, and they will have to be >reeducated<.

> Implementation #2: Permit hybrid routes, and make every site which accepts
> ! or @ make an "intelligent" choice about what the sender really wants.

But not an artificially intelligent choice, you understand... :-)

>   Problem:  Pathparse has't been released yet.  When it is released, it
>     will require an "appropriately" sized database, which must be maintained.
>     Maintenance is not a big issue.

I've stated repeatedly here that the *sender* should write RFC822 addresses,
which should be parsed with "@" precedence, and that sites along the way
should give "!" precedence.  Pathparse is a very good enhancement that
allows the user to have more flexibility in writing what he or she wants to
be the destination of the message, but I am making an argument on behalf
of sites that have no special software at all.

> Extra Protection: Keep the From: line in ! format in UUCP land.  This way,
>  sites which prepend their name will take b!a and produce c!b!a or b!a@c,
>  either of which is "correct".

I don't like this approach, and I wish we could discuss this, or some other
topic, instead of going over and over the @-precedence issue.  Presently the
many strange ways sendmail sites macerate the routing stamps on the fronts
of the messages cause a lot of problems generating replies.  If you are
going to argue in favor of RFC822 compliance (which I think you should),
then you shouldn't compromise on these issues.

> I have it on good authority that sendmail source can be put on any system
> licensed for SysV or 4.2 (or later) BSD.  These sources seemed to think
> that there is a 99% chance that sites with 32V, V7, or SysIII licenses
> would also be able to have sendmail.  4.1BSD was not mentioned, but I doubt
> there would be a problem.

I don't see the point to this.  Why would other sites want to install
Sendmail?  I recall what they told me when I first started working on the
mail system here... "Don't even think of installing Sendmail."  Why should
your average site install sendmail?  It was written for use at gateways.
I get all the advantages of Sendmail, even a nice "Received:" line on the
message, with much simpler software, since I don't need to make any of the
transformations that Sendmail makes in the headers.  If I was at a gateway,
and the other network(s) didn't take the RFC822 syntax, then I would probably
be interested in Sendmail.  (Though I wouldn't change the current transport
software for UUCP.)


Now let's talk about something new.
-- 
Shyy-Anzr:  J. Eric Roskos
UUCP: Ofc:  ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
     Home:  ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer
  US Mail:  MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642