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