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!cbosgd!ihnp4!houxm!vax135!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.mail
Subject: Re: Mail routing -- problems showing up
Message-ID: <1641@peora.UUCP>
Date: Mon, 16-Sep-85 10:13:44 EDT
Article-I.D.: peora.1641
Posted: Mon Sep 16 10:13:44 1985
Date-Received: Tue, 17-Sep-85 06:03:05 EDT
References: <1383@peora.UUCP> <9546@ucbvax.ARPA> <1478@cbosgd.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 153

Oh, no... "the truth will out," as they say...

> Let's suppose that next month hplabs installs smail or any other
> piece of software that conforms to RFC822, that is, gives @ priority
> over !.

RFC822 does not specify how routing is to be done.  RFC822 specifies the
format the mail message itself will take.  The transport mechanism used to
deliver the message should form an "envelope" around this message, such
that the routing information is outside the RFC822-conforming message:
to preserve a reasonable hierarchical model for the mail system, each level
should not be tampering with things on a lower level.

What I have been proposing all along here (and what I am about to give up
on, and go back to doing work they pay me for) is that you should preserve
a proper, hierarchical model of mail delivery.  There should be a transport
mechanism that effects routing in a reasonable manner, and a lower (or
higher depending on how you look at it) level piece of software that
handles the user interface, and the inter-network "gatewaying." Most of the
problems that exist today exist because people take their transport-level
traffic and dump it into the same piece of software (sendmail) that is
handling their gatewaying and user-level address parsing.  This is
ridiculous.  It's poor structuring of the mail architecture.

The mail architecture should not be this muddy.  There should be a
transport agent out on the periphery, which is sending mail by the sites
along the route without tampering with them, which is in effect just a
wire or conduit passing the messages along; and when a message is supposed
to be gatewayed, it comes off the conduit and into your sendmail or whatever,
and if it is supposed to be for a local user, it comes off the conduit and
goes into the local mailbox, but mail that doesn't have anything to do with
your site, that just happens to be passing through on the way to some other
place, shouldn't be going off into your sendmail and getting its headers,
which are not a part of the transport mechanism, macerated into
unintelligibility; nor should the transport mechanism be trying to
interpret the routing language in some way that paradoxically invokes the
RFC822 language.

> This method may happen to work today, with the particular path you
> mention, but it's extremely dangerous, because you're generating an
> address has a ! to the left of an @.

I.e., it works now, but it won't work soon, because although it works fine
now, soon it will be fixed so it is all better... the transport mechanism
conforms to the standard of RFC822, a standard for the format of message
text, and this is a tremendous improvement!  (I'm starting to sound like
RPF.)

> Let's suppose that next month hplabs installs smail or any other
> piece of software that conforms to RFC822, that is, gives @ priority
> over !.
	...
> So you say "why don't we just require hplabs to hack their mailer
> so that mail coming in from uucp will give ! priority?"  There are
> four problems with this:
>
> (1) This is anarchistic UUCP - you can't require hplabs to do anything.

But you are requiring everyone to omit "@" from their routing language:

> (2) RFC822 is a documented standard and ! routing is not.  The chances are
> excellent that AT&T will soon endorse @ having priority over !.

even though AT&T first provided the '!'-precedence routing language, which
had thereby become a standard for the UUCP mail.

> (3) What happens if you want to send mail to a remote UUCP host?  That is...

As I said, this is the big problem.  I don't deny that the all-! syntax has
a definite advantage here; I even said so in the posting you're commenting
on.  In fact, until I tried the all-! syntax awhile and found so few places
supported it, I even thought it was a good idea (aside from my doubts about
excessive rewriting).

The all-! makes a good deal of sense theoretically.  I'm just looking at it
from the viewpoint of someone who needs to get mail places with reasonable
reliability, without sudden interruptions as people switch to other syntaxes.
It's sort of like why all your telephone switching systems have to be able
to withstand 130 volt signals... whatever happened to that proposal for
electronic bells that was so popular awhile back?

> (4) What is hplabs supposed to do with the following address typed by a
> user on hplabs?
>         ucbvax!fred@F.ISI.ARPA
> It didn't come in via rmail, so you can't assume bang priority.  It didn't
> come in via SMTP, so you can't assume @ priority.  Is fred on ISI or ucbvax?

Fred is on ucbvax.  You send this message to F.ISI.ARPA, who sends it to
ucbvax, who sends it to fred.  This is because the address was TYPED by the
user, i.e., into the message header, meaning it is interpreted by the
user interface, which is RFC-conforming.  Here again you've chosen the
degenerate case, though, since there's no way to route it without getting
into an "is this better than all-!" argument.

> In general, you can do the same thing with standard conforming syntax
> such as
>         pesnta!hplabs!ucbvax!MIT-MULTICS.ARPA!foovax!sam_smith%unixsite.mailnet
> or better yet
>         pesnta!hplabs!ucbvax!unixsite.mailnet!foovax!sam_smith
> (These examples assume that ucbvax is properly configured as a gateway,
> which I'm not sure is true right now.  They would work using seismo as
> the gateway.)

"Standard-conforming"?  What's this?  You mean, UUCP is really an AT&T
network?

It won't work, which is why I decided I didn't like the all-! syntax.  I
tried mailing through it, and a week later everyone's mail started getting
returned.  This suggested a lot of changes had to be made, which is where
my opinion comes from.

> While smail is nearly ready (we're hoping for an October posting), I'd
> be interested to hear more about your nameserver.  What we have is not
> a nameserver - it's a table driven routing program that uses pathalias
> and sendmail.  A true nameserver might be a useful thing to have.

I have posted the basic nameservice routines to net.sources.  These use the
pathalias database to resolve site names into paths there.  This sounds a
lot like what you have.  It is not an RFC-style nameserver (which gives
name resolutions for arbitrary object names; note that the RFC on domains
(I forget its number) covers a lot more than names for mail sites) since I
can't figure out what that would be good for.  It simply yields routes
given names.  Since the pathalias database is automatically updated (when
you send out new maps, or when we update our domain maps), it does provide
an automated updating facility.


All the above has been independent work.  Unfortunately, typing this very
message is eating into time someone else is paying for (by a few minutes),
and this has to stop.  You can't whomp the competition while you are
arguing with one of them over how to route mail!  I don't get paid to do
any of this, and often wonder why I got involved in discussing it at all,
since the path taken by the UUCP mail in the long run appears resolved and
predetermined... I guess by the people who are paying someone to do it!
It only makes sense, though...

So in a few days, if I can get the time (I brought some sandwiches for lunch
so I would have some time) I will fix up the rmail to run "mail", which
is a fairly safe way of doing things, and put it in net.sources, where
other people can do whatever they want with it, and I will get back to doing
what I am supposed to, which is not mail.

I am not going to write any more in here, though.  I don't see much point
in it: when you convert to the all-! syntax, all I have to do is change
the translation file, and it will generate the !'s... so there is little
point in arguing further (for me), since PE isn't in the mail business ...
Reminds me of Chuqui's lament...
-- 
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