jer@peora.UUCP (J. Eric Roskos) (01/29/86)
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: <topaz!petsd!peora!randy@ames.arpa> > > ----- Transcript of session follows ----- > 550 xhmeia.tcpld... 550 Host unknown > 550 <ucbvax!cit-hamlet.arpa!ebw@xhmeia>... 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" <ebw%xhmeia@cit-hamlet.arpa> > Subject: Hello > Date: 27 Jan 86 08:59:42 EST (Mon) > From: Randy Hendry <topaz!peora!randy@ames.ARPA> > X-From: Randy Hendry <randy@peora.UUCP> > > <message body followed> 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 <local-part>. 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" <xhmeia!ebw@cit-hamlet.arpa> > Subject: Hello > Date: 28 Jan 86 08:33:02 EST (Tue) > From: Randy Hendry <topaz!peora!randy@ames.arpa> > X-From: Randy Hendry <randy@peora.UUCP> > > <message body followed> 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
wls@astrovax.UUCP (William L. Sebok) (01/30/86)
In article <1942@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) discusses
difficulties in reaching the address ebw%xhmeia@cit-hamlet.ARPA .
I have had a similar problem with the address tc_vox%phobos@cit-hamlet.arpa,
a mailing list to which I forward the newsgroup net.astro.expert. I have been
completely unsuccessful in getting it through seismo --- I see no way to
translate it into a pure bang address that will pass successfully to its
destination.
Fortunately the mixed mode address think!tc_vox%phobos@cit-hamlet.arpa
still works (when last I tried it). In this case I have to use a
mixed mode address to get the mail delivered.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wlsspaf@gatech.CSNET (Gene Spafford) (01/30/86)
There is a solution, and I have been using it for many months here with
no problems. It was built into the sendmail package I posted to
mod.sources a few months ago. Basically, you can mix "!", "@", and "%"
together in addresses, but the precedence is determined by how the mail
got here.
For instance, if mail arrives at "gatech" via uucp with the address
a!b!y@z, then our mailer gives the "!" symbols higher precedence, and
the mail will be forwarded via uucp to site "a" for delivery to
"b!y@z"
On the other hand, if mail arrives via PMDF (CSNet) addressed to
a!b!y@z, then the "@" and "%" symbols have higher (and equal)
precedence and are scanned from right to left. Thus, the mail is sent
on to site "z" (by whatever mechanism is deemed "most efficient") for
delivery to "a!b!y".
The mixing of symbols is not ambiguous IN CONTEXT.
Giving credit where credit is due, this change was inspired by some
sendmail changes published to the net by topaz!hedrick
--
Gene "the end is in sight" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332-0280
CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ Relay.CS.NET
uucp: ...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spafhmm@unido.UUCP (01/31/86)
I think the gateway at ucbvax is the culprit in this case. The gateway should transform a route in the routing language of one network into the equivalent rout in the other's network routing language. That is, a route "...!uucphost1!uucphost2!arpa-gateway!arpahost1!arpahost2!arpahost3!user" should look like "@arpahost1,@arpahost2: user@arpahost3" after the gateway. This is a valid rfc822 address and preserves the exact meaning of the uucp route. The fact that most mailers consider "user%host2@host1" equivalent to "host1!host2!user" does not make it a standard. However, please keep in mind that all this stuff applies to the envelope only. Mail headers should be in rfc822 format wherever possible to minimize user irritation. The bangs are just a means to get my message transported over the uucp network, I don't want to see them in my mail... Avoid @'s in uucp routes ! Avoid !'s in arpa addresses ! Let the gateways do the dirty work ! If the gateway is broken, fix it !!! Hans-Martin Mosner <hmm@unido.uucp>, <hmm@unido.bitnet> One of the postmasters at unido University of Dortmund, Germany
dfk@unido.UUCP (02/01/86)
> /***** unido:net.mail / gatech!spaf / 6:19 pm Jan 30, 1986*/ > For instance, if mail arrives at "gatech" via uucp with the address > a!b!y@z, then our mailer gives the "!" symbols higher precedence, and > the mail will be forwarded via uucp to site "a" for delivery to > "b!y@z" > > On the other hand, if mail arrives via PMDF (CSNet) addressed to > a!b!y@z, then the "@" and "%" symbols have higher (and equal) precedence > and are scanned from right to left. Thus, the mail is sent on to site > "z" (by whatever mechanism is deemed "most efficient") for delivery to > "a!b!y". I most strongly agree! We have been doing it that way for some months now and it works very well. The problem is, that in standard sendmail you cannot determine where the mail came from. There are some sites around here with binary licenses. After one of the previous debates about that we did "compile" a /bin/rmail that converts addresses to an unabiguous form giving ! precedence. That way our sendmail.cf can give @ precedence as we need for Bitnet and local networks. This means address and header munging two times but you don't have to change sendmail. I would be happy to send the stuff to sites who can't/won't change sendmail. -Daniel