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!hjuxa!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.mail Subject: Unreachable Machines Message-ID: <1942@peora.UUCP> Date: Wed, 29-Jan-86 09:31:03 EST Article-I.D.: peora.1942 Posted: Wed Jan 29 09:31:03 1986 Date-Received: Thu, 30-Jan-86 06:43:27 EST Organization: Concurrent Computer Corporation, Orlando, Fl Lines: 169 Keywords: @-precedence Some time ago, you may remember, we had some lengthy debates here about @-precedence -- whether the symbol "@" in strings in the UUCP routing language should be made a special token, but then that it should be mandated that strings in the language that contain an "@" not be used in UUCP addresses. At that time, I argued that such an approach made some sites unreachable. Others argued that it had already been decided that "@" should not be used, and that all-! strings were sufficient, since it was the responsibility of gateways (the RFC822 language on network-specific transformations (3.4.10) was occasionally cited as justification) to insure that addresses leaving the network conformed to the new network's addressing syntax. I argued in response that it was possible to construct hypothetical cases of access to secure networks in which sufficient knowledge to make such transformations at a gateway was unavailable. Unfortunately, no further progress was made, since those citing counterarguments would do nothing other than to repeat the original assertions. Reluctantly, since our mailer could generate either kind of string with no problem, I converted the routing specification files for our mailers here to use all-! syntax. Now I am receiving some flack from a user who cannot address a site on another network because of the all-! syntax. This again leads me to feel that the @-precedence is a problem in practice, simply due to the difficulty of forcing all sites on all networks to comply with it. Following is a message that is unable to reach its destination, seemingly by any means, at present. The user was told that he should address his message to ebw%xhmeia@cit-hamlet.ARPA xhmeia is apparently not on the Usenet; it appears to be on a local network at Caltech. In fact, knowing that xhmeia is probably the name of a machine requires reasoning outside the formal languages involved, since according to specifications, "ebw%xhmeia" is the "local-part" of the RFC822 address, and could well be a strange user name that just happens to contain a percent sign. Following the instructions the user was given, he typed this address, which was translated by the mailer into petsd!topaz!nike!miro.berkeley.edu!ucbvax!cit-hamlet.ARPA!ebw%xhmeia Here's what apparently happened: ucbvax took the '%', changed it into an '@', and tried to send the message to xhmeia, which failed: > From: MAILER-DAEMON@ucbvax.berkeley.edu > Return-Path: petsd!topaz!nike!MAILER-DAEMON@ucbvax.berkeley.edu > X-UUCP-Sent: uucp Mon Jan 27 15:53:08 1986 remote from petsd > X-UUCP-Sent: nike!MAILER-DAEMON@ucbvax.berkeley.edu Mon Jan 27 15:24:46 1986 remote from topaz > Received: by peora.UUCP (Xelos MH.5.5.7 III/DNS) with uucico; > ID AF5272; 27 Jan 86 18:43:41 EST (Mon) > Received: by topaz.rutgers.edu; Mon, 27 Jan 86 15:24:46 est > Received: by ames.ARPA (5.28/1.3) > id AA15380; Mon, 27 Jan 86 12:22:14 PST > Received: by ucbvax.berkeley.edu (5.44/1.8) > id AA19566; Mon, 27 Jan 86 12:20:21 PST > Date: Mon, 27 Jan 86 12:20:21 PST > From: topaz!nike!MAILER-DAEMON@ucbvax.berkeley.edu (Mail Delivery Subsystem) > Subject: Returned mail: Host unknown > Message-Id: <8601272020.AA19566@ucbvax.berkeley.edu> > To: > > ----- Transcript of session follows ----- > 550 xhmeia.tcpld... 550 Host unknown > 550 ... Host unknown > > ----- Unsent message follows ----- > Received: by ucbvax.berkeley.edu (5.44/1.8) > id AA19541; Mon, 27 Jan 86 12:20:21 PST > Received: from ames.ARPA by miro.ARPA (5.5/5.6) > id AA02854; Mon, 27 Jan 86 12:18:58 PST > Received: by ames.ARPA (5.28/1.3) > id AA15367; Mon, 27 Jan 86 12:18:34 PST > Received: by topaz.rutgers.edu; Mon, 27 Jan 86 13:57:32 est > Message-Id: <8601271857.AA22007@topaz.rutgers.edu> > To: "petsd!topaz!nike!miro.berkeley.edu!ucbvax!cit-hamlet.arpa!ebw%xhmeia" > Subject: Hello > Date: 27 Jan 86 08:59:42 EST (Mon) > From: Randy Hendry > X-From: Randy Hendry > > Subsequently I told him, "Well, try the suggestion the net.mail folks say to use, and write xhmeia!ebw@cit-hamlet.arpa and see if that works." The above address generated the following: petsd!topaz!nike!miro.berkeley.edu!ucbvax!cit-hamlet.arpa!xhmeia!ebw ...which, I would think, any "all-!" supporter would consider the "right" syntax to use. Here's what happened this time: it got through ucbvax successfully, but (I had wondered if this would occur) ucbvax just passed the message along to cit-hamlet with xhmeia!ebw in the . There's no way that ucbvax *could* have known that xhmeia!ebw needed to be transformed without knowing details of CalTech's mailers; and once it left ucbvax, it was outside the UUCP network, and making cit-hamlet comply with a strange address from the UUCP network would involve requiring people outside the UUCP network to comply with our idiosyncrasies. Not surprisingly, cit-hamlet had no idea what to do with such an address (you will recall the "nudet" example I gave several months ago, of trying to access a secure network in which compartmentalization requirements made only an address string, but nothing about the semantics of the string, available to people outside the network). Thus the message failed at cit-hamlet: > From: Mailer@Hamlet.Caltech.Edu > Return-Path: petsd!topaz!nike!Mailer@Hamlet.Caltech.Edu > X-UUCP-Sent: uucp Wed Jan 29 02:35:19 1986 remote from petsd > X-UUCP-Sent: nike!Mailer@Hamlet.Caltech.Edu Wed Jan 29 02:17:23 1986 remote from topaz > Received: by peora.UUCP (Xelos MH.5.5.7 III/DNS) with uucico; > ID AF80151; 29 Jan 86 02:56:58 EST (Wed) > Received: by topaz.rutgers.edu; Wed, 29 Jan 86 02:17:23 est > From: topaz!nike!Mailer@Hamlet.Caltech.Edu > Received: by ames.ARPA (5.28/1.3) > id AA19571; Tue, 28 Jan 86 23:16:16 PST > Message-Id: <8601290716.AA19571@ames.ARPA> > Date: Tue, 28 Jan 86 23:13:58 PST > Subject: Undeliverable Mail > To: topaz!petsd!peora!randy@ames.arpa > Comment: reason for return -- Invalid address[es] > Comment: the affected addresses follow ... > Comment: xhmeia!ebw > > Start of returned message > > Received: from ucbvax.berkeley.edu by Hamlet.Caltech.Edu with INTERNET ; Tue, 28 Jan 86 23:11:59 PST > Received: by ucbvax.berkeley.edu (5.44/1.9) > id AA14860; Tue, 28 Jan 86 23:11:47 PST > Received: from ames.ARPA by miro.ARPA (5.5/5.6) > id AA12258; Tue, 28 Jan 86 23:11:32 PST > Received: by ames.ARPA (5.28/1.3) > id AA19524; Tue, 28 Jan 86 23:11:12 PST > Received: by topaz.rutgers.edu; Wed, 29 Jan 86 01:54:11 est > Message-Id: <8601290654.AA12681@topaz.rutgers.edu> > To: "petsd!topaz!nike!miro.berkeley.edu!ucbvax!cit-hamlet.arpa!xhmeia!ebw" > Subject: Hello > Date: 28 Jan 86 08:33:02 EST (Tue) > From: Randy Hendry > X-From: Randy Hendry > > The frustrating thing is that the address the original user specified (which was certainly a valid address from his perspective, and was compliant with RFC822) would have worked, if "@" (and "%") hadn't been needlessly treated as special tokens in the UUCP routing language. In fact, it did formerly work, until very recently, since I have seen similar messages routed through ucbvax before. Thus the current trend in the UUCP network seems to be towards isolating UUCP from the rest of the world, not integrating it with it. I must reemphasize that I have no objections to the extensions to the "!" language that allow domains to be imbedded in a path. The only problem seems to be in having a token of higher precedence than "!" in the language. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCC.UUCP CCC DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642 LOTD(4)=s