paul@vixie.UUCP (06/12/87)
Okay, let's do it again.... sigh... In article <756@bsu-cs.UUCP> dhesi%bsu-cs@iuvax.UUCP (Rahul Dhesi) writes: >This is a good time to recapitulate. I originally posted an article >suggesting that one ought to be able to specify precedence within >a mail address, so [a!b]@c.EDU would be different from a![b@c.EDU] and >neither would be ambiguous. > >Here is a summary of the objections that were raised to my suggestion >and my response. And here are my objections to your responses. >Objection: We would have to add another special character to mail >addresses and there is no point in complicating things. > >Response: [...] All we need to do is allow the nesting of <>. For the various non-recursive finite-state parsers out there, nested <>'s would be a painful thing to support. What I want to point out, though, is that you are suggesting a change to the software of every (or nearly every) node on the internet. At least, those sites that wanted to reply to sites using your new syntax, would have to upgrade their software to understand the new syntax. This is not in itself a bad thing; at this point I only want to point out the scope of the change you are suggesting -- I need it below. >Objection: There is no such thing as a bang address. > >Response: Should we dignify this head-in-sand attitude by responding >to it? I don't think so. This is unprofessional in the extreme. All you do with this kind of a response is to convince the people who have the attitude you are making fun of, that YOU are a jerk and that your ideas are probably worthless. Try to be constructive, okay? Now the fact is that there IS NO SUCH THING as a bang address. Bangs are used in routes, not addresses. At-signs are used in addresses. There is such a thing as a 'route-addr', which uses colons and commas, but I really don't understand much of that (which is too bad, since my sendmail.cf does!) This is a question of terminology. A string consisting of "words" seperated with bangs is CALLED a route. A string with two "words" with an at-sign in between them is CALLED an address. According to the standards adopted by the Internet, "From:" and "To:" lines contain addresses, and addresses are of the form "lhs@rhs", and "rhs" has a syntax making it a domain, and "lhs" can be anything at all. An address (really: a From: or To: line's contents) that does not contain an at-sign is considered a "local" address, subject to whatever meaning the local mailer wants to give it. Usually, it is scanned for bangs and forwarded if appropriate -- but this is a defacto-standard, not an approved one. THIS WORKS. There is no need for precedence operators in a network where every site acts according to the standard. Maybe we need a standard that will transform the defacto handling of bangs in LHS into an approved thing; if this is what you want to to, write an RFC -- the net would canonize you. My point in this part of this article is that there is a standard, and that if all sites adhered to it, it would work well enough to do what you are trying to do with your additional precedence operator(s). Also, I urge you not to brush off this point, or I (and others, no doubt) will think that YOU have YOUR head in the sand. >Objection: There is no problem with precedence because @ always has >the highest precedence, and anything to the left of that is only >interpreted by the site named after the @. > >Response: This is pure chauvinism. Chauvinism = preference of one thing over another for non-objective reasons. There ARE good reasons for doing it this way -- because that's the approved standard, mostly; if you do it this way, you mail will get through, and mail forwarded through your system will get through. This is not chauvinism. >A user of the ! syntax, whose mailer does not understand @ syntax, treats all >addresses as made up of components separated by bangs. Even programs that >understand both types of addresses may arbitrarily choose one over the other. A user of the ! syntax can get SMAIL for free, and join the internet. A program that understands both bangs and at-signs can either do it the way the standards tell us to do it, or do it some other way. If the program adheres to the standard, everybody's mail will get through. Points: internet mail handlers can be had for free (SMAIL). there IS a standard way to handle addresses with both @ and !. >As far as I can tell from the documentation, smail gives precedence to the ! >over the @ when it sees both in the address field of an incoming message. Since SMAIL is advertised as a RFC-compliant mailer, this can't be right. Can a UUCP-Project member comment on this? >I have encountered messages whose address fields were badly mangled because >some sites gave precedence to @ and others gave precedence to !. So have I. And I curse and bitch and moan and send mail to the site admins of the offending systems, and they usually say "oh, sorry, didn't know, let me install smail". Really, that's the usual response. I've been amazed. >Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi You're done, so let me get to my conclusion. Since SMAIL is free, and since it adheres to the published standards, and since if everyone adhered to the published standards mail would be much more reliable, and since you are suggesting that everyone (even currently compliant sites) change their mail handlers to accept your (unneccessary) additions, it follows that you should instead advocate a wider acceptance of SMAIL: it does what you want done (get mail through faster and more reliably); it already exists (so there is no effort involved in designing and coding what you suggest); it is free (obvious benefits); and anyone already compliant with the published stand- ards doesn't have to do anything (fewer people have to upgrade their mailers). Can we let the precedence-character argument drop, now, and get on with the business of bringing the gospel of SMAIL to the heathens(*) :-) ?? (* = stolen from Cal Thixton's outgoing mail headers) -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013
lamy@utegc.UUCP (06/12/87)
>>As far as I can tell from the documentation, smail gives precedence to the ! >>over the @ when it sees both in the address field of an incoming message. > >Since SMAIL is advertised as a RFC-compliant mailer, this can't be right. Well, the documentation to smail 2.3 says so. "To preserve compatibility with rmail". But please enlighten me: why should there ever be a mixed address in UUCP land? There is also no need rewrite the envelope unless the destination CANNOT deal with it, so only gateways should have to do it, right? And a UUCP to RFC822 gateway can always produce a <> route, and a RFC822 to UUCP gateway can always produce a ! route, right? It is much more likely that we can get fixed gateways than asking all sites in the universe to perpetuate the confusion between a route and an address. What Rahul is asking is a new way to write routes, and we already have perfectly unambiguous ways to do that. Jean-Francois Lamy lamy@ai.toronto.edu AI Group, Dept Computer Science {seismo,watmath}!ai.toronto.edu!lamy University of Toronto, Canada M5S 1A4
kyle@xanth.UUCP (Kyle Jones) (06/12/87)
>>As far as I can tell from the documentation, smail gives precedence to the ! >>over the @ when it sees both in the address field of an incoming message. > Since SMAIL is advertised as a RFC-compliant mailer, this can't be right. > Can a UUCP-Project member comment on this? I'm not a UUCP-Project member, but I have and use SMAIL 2.3 (the latest version). SMAIL does give @ first precedence in accordance with RFC 822. I am certain of this. Not long ago I complained bitterly in this forum that SMAIL did not handle @ and ! precedences correctly, and was promptly corrected by Mark Horton. The problem was that I had an old version of SMAIL, which did have this bug. So if you are running SMAIL or installing it for the first time, make sure you have version 2.3. kyle jones <kyle@xanth.cs.odu.edu> old dominion university, norfolk, va
elg@killer.UUCP (* Airwick *) (06/13/87)
in article <654@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) says: > Xref: killer comp.mail.misc:348 comp.mail.uucp:616 > Now the fact is that there IS NO SUCH THING as a bang address. Bangs are > used in routes, not addresses. At-signs are used in addresses. There is > such a thing as a 'route-addr', which uses colons and commas, but I really > don't understand much of that (which is too bad, since my sendmail.cf does!) Gee, I'll have to tell that to the mailer here at machine "killer". It doesn't understand @ signs at ALL. Doesn't ihnp4!foo!bar mean the same thing as bar@foo, as far as differentiating the machine and ID of the reciever goes? The only difference is that ihnp4!foo!bar also includes a little routing info.... If we define an "address" as a "unique identifier identifying a) the machine of the recipient, and b), the ID of the recipient", then it's obvious that both "bang" paths and "at" addresses are, in fact, both addresses, even though one includes more information than the other. >>A user of the ! syntax, whose mailer does not understand @ syntax, treats all >>addresses as made up of components separated by bangs. Even programs that >>understand both types of addresses may arbitrarily choose one over the other. > > A user of the ! syntax can get SMAIL for free, and join the internet. A > program that understands both bangs and at-signs can either do it the way > the standards tell us to do it, or do it some other way. If the program > adheres to the standard, everybody's mail will get through. There's one problem with this. The vast majority of system operators out there are NOT mail gurus. Their machine comes with /bin/mail and /bin/mailx, their mailer is rmail (which talks to uux), and they're busy doing their JOB instead of trying to keep up with the latest "standards" to come out. Call it "head in the sand" if you will, but most of these people don't even KNOW that SMAIL exists. -- Eric Green elg%usl.CSNET CS student, University of SW Louisiana {cbosgd,ihnp4}!killer!elg Apprentice Haquer, Bayou Telecommunications Snail Mail P.O. Box 92191 BBS phone #: 318-984-3854 300/1200 baud Lafayette, LA 70509 I disclaim my existence, and yours, too.
jpn@teddy.UUCP (06/16/87)
>>Objection: There is no problem with precedence because @ always has >>the highest precedence, and anything to the left of that is only >>interpreted by the site named after the @. >> >>Response: This is pure chauvinism. > >There ARE good reasons for doing it this way -- because that's the approved >standard, mostly; if you do it this way, you mail will get through, and mail >forwarded through your system will get through. This is not chauvinism. I think it's chauvinism. Your internet standard/software may talk '@' addresses, but my software may not, and arbitrary sites between me and my desired destination may not. How about an example. I need to send '@' mail to a site (call it site3) three uucp hops away which is a gateway to an '@' network: There is one site in the middle (call it "site2") which doesn't understand '@' addresses (bear with me a moment!). The site immediately next to us (call it site1) interprets '@' addresses. My first guess at an address would be: site1!site2!site3!user@foo.NETWORK This won't work, because site1 interprets that '@', and tries to send relay mail to foo.NETWORK, with the username site2!site3!user. This fails. If I send an address like user@foo.NETWORK to site1, and assuming IT understands that it needs to relay to site2 (a big assumption, but nevermind), then site2 gets an address like user@foo.NETWORK, and dies. What is "smail" supposed to generate, if I give it an address like user@foo.NETWORK if we are not on that network? Would site3!user@foo.NETWORK@site2.UUCP@site1.UUCP work? Unlikely, or unreadable, at best. What if MY site ONLY talks bang. Will site!site3!user@foo.NETWORK@site2.UUCP work? I doubt it! Now, suppose that all of site1, site2, and site3 talk '@' addresses, but site1 and site2 only know UUCP domain, and site3 is still the NETWORK gateway. HOW do I send mail now? Does site1 HAVE to understand .NETWORK? I think this is unreasonable, especially when I already KNOW how to get mail to .NETWORK (I relay through site1, site2, and site3!). Can I say: user@foo.NETWORK@site3.UUCP@site2.UUCP@site1.UUCP? Does this work? It this really the approved way to send mail over non fully-connected networks (i.e. where some path components MUST be specified)? Maybe I'm just confused...
john@xanth.UUCP (06/16/87)
In article <4106@teddy.UUCP>, jpn@teddy.UUCP (John P. Nelson) writes: > How about an example. I need to send '@' mail to a site (call it > site3) three uucp hops away which is a gateway to an '@' network: > ... [and sites along the way handle @ differently] ... > site1!site2!site3!user@foo.NETWORK > user@foo.NETWORK, and dies. What is "smail" supposed to generate, if I > give it an address like user@foo.NETWORK if we are not on that > network? Would site3!user@foo.NETWORK@site2.UUCP@site1.UUCP work? > Unlikely, or unreadable, at best. What if MY site ONLY talks bang. > Will site!site3!user@foo.NETWORK@site2.UUCP work? I doubt it! > [etc.] First of all, you can *never* have more than one @-sign per address if you want to preserve any sanity at all. [Exception: route-addrs.] This is what RFC976 and smail take care of! A "class 3" UUCP site, including all sites running smail, will accept do.ma.in!user, not just user@domain. So in the first scenario above, your mail transport agent should generate the address site1!site2!site3!foo.NETWORK!user Now with an intelligent user agent, or even a not so intelligent user agent that just passes the address along to smail, you should just be able to say mail user@foo.NETWORK and have smail generate the above all-bang address for you. The RFC822 mail headers (To: line, etc.) should only have the user@foo.NETWORK address, and the rmail commands that get passed from uucico to uucico will only have bangs. I've been using ".NETWORK" since that's what you used in your examples, but you should be aware that what you're going to see on the right side of the @-sign is almost always a domain address, which might or might not imply any particular network. Addresses that explicitly indicate a network (".ARPA", ".UUCP", ".BITNET", etc.) are using "pseudo-domains", and are becoming increasingly more rare, in favor of network independent domain names (ending in ".COM", ".EDU", ".UK", or whatever). You (and anyone else interested) should read RFC976 (and maybe the "What is a Domain?" paper), included with the smail documentation. -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john
lyndon@ncc.UUCP (06/16/87)
You should be able to specify a route like site1!site2!host.domain!user as an alternate to site1!site2!user@host.domain Sites that gateway between @ and ! networks should be able to grok host.domain!user for this very reason (according to the RFC you love to hate :-) If you look at the paths generated by smail, they will use the host.domain!next_part convention in preference to user@... to enable these type of addresses to be routed through hosts that understand @ as well as ! without any confusion arising.
paul@vixie.UUCP (Paul Vixie Esq) (06/16/87)
In article <4106@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: >[...] >Now, suppose that all of site1, site2, and site3 talk '@' addresses, but >site1 and site2 only know UUCP domain, and site3 is still the NETWORK gateway. A gateway is allowed (maybe required, I'm not sure) to rewrite as neccessary when forwarding messages between networks. Therefore you could send to site1!site2!site3!foo.network!user and the dest addr will be rewritten to be user@foo.network when site3 forwards it. What to set the From: line to in that situation, I don't know. As I weary of this whole discussion, I begin to wish that the RFCs would recognize bangs as a low-precedence operator, since the route-addr form with all the colons and commas looks really really ugly. But there is a way to do even that -- routing in the ARPAnet. Something like :site3.network,:site2,:site1,you@home but don't quote me. Whatever form it takes, site3 as the gateway could rewrite from that to the bang-form. That will make replies to the message work okay; getting the original message through is the easy part, and that's all you asked about. >HOW do I send mail now? Does site1 HAVE to understand .NETWORK? I think >this is unreasonable, especially when I already KNOW how to get mail to >.NETWORK (I relay through site1, site2, and site3!). Can I say: >user@foo.NETWORK@site3.UUCP@site2.UUCP@site1.UUCP? Does this work? Nope, only one @ per address. But there IS a route-form, I promise! I just don't remember the syntax. Help? >Maybe I'm just confused... You and me and everybody else, too. -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013
paul@vixie.UUCP (Paul Vixie Esq) (06/16/87)
In article <995@killer.UUCP> elg@killer.UUCP (* Airwick *) writes: >in article <654@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) says: >> Now the fact is that there IS NO SUCH THING as a bang address. Bangs are >> used in routes, not addresses. At-signs are used in addresses. There is >> such a thing as a 'route-addr', which uses colons and commas, but I really >> don't understand much of that (which is too bad, since my sendmail.cf does!) > >Gee, I'll have to tell that to the mailer here at machine "killer". It doesn't >understand @ signs at ALL. Doesn't ihnp4!foo!bar mean the same thing as >bar@foo, as far as differentiating the machine and ID of the reciever goes? >The only difference is that ihnp4!foo!bar also includes a little routing >info.... As far as identifying the host and user of the recipient, both forms have that information, yes. The extra routing information is usually wrong, since the From: line is not supposed to be modified, and the UUCP From_ line is usually not used for replies (not by mailx, anyway, and if there's an option for this it ought to be the default, or at least prominently displayed in the documentation). >If we define an "address" as a "unique identifier identifying a) the machine >of the recipient, and b), the ID of the recipient", then it's obvious that >both "bang" paths and "at" addresses are, in fact, both addresses, even though >one includes more information than the other. If you define "address" that way, yes, both forms are an address. The point I've been making is that the Internet _doesn't_ define an address that way, and there's less work involved in using the existing meaning of "address" than in changing all the Internet sites to use a different definition. >>A user of the ! syntax can get SMAIL for free, and join the internet. A >>program that understands both bangs and at-signs can either do it the way >>the standards tell us to do it, or do it some other way. If the program >>adheres to the standard, everybody's mail will get through. > >There's one problem with this. The vast majority of system operators out there >are NOT mail gurus. Their machine comes with /bin/mail and /bin/mailx, their >mailer is rmail (which talks to uux), and they're busy doing their JOB instead >of trying to keep up with the latest "standards" to come out. Call it "head in >the sand" if you will, but most of these people don't even KNOW that SMAIL >exists. Yeah, I know. Whatever vendors ship to clients, becomes the unofficial standard. People support it because it exists, and often it's an accident, not intended for the wide support it eventually receives. I don't know how to solve this. I do consulting work, and I've set up SMAIL for money before -- it takes about 30 minutes once you know what to do. For the vast majority of people who will only use what their vendor supplies, I have no immediate answer. I think that X.400 will get wide support, since ISO standards are very popular with vendors; unfortunately, an X.400 mailer is a salable product, and will probably be an extra-cost option in future UNIX(tm) releases, which means that UNIX and e-mail will probably stop going hand-in-hand. Whether X.400 is a good thing technically or not, I can't comment -- I don't know. -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013
Karl.Kleinpaste@cbstr1.att.com (06/17/87)
In-reply-to: jpn@teddy.UUCP's message of 15 Jun 87 21:05:43 GMT jpn@teddy.UUCP writes: > >>Objection: There is no problem with precedence because @ always has > >>the highest precedence, and anything to the left of that is only > >>interpreted by the site named after the @. > >> > >>Response: This is pure chauvinism. > > > >There ARE good reasons for doing it this way -- because that's the approved > >standard, mostly; if you do it this way your mail will get through and mail > >forwarded through your system will get through. This is not chauvinism. > > I think it's chauvinism. > [long examples of hypothetical foul-ups...] > Maybe I'm just confused... Yes, you are confused. The means by which remote gateways are reached are very straightforward; smail handles it quite neatly. Consider not a hypothetical example, but a real, working arrangement: this site. This is cbstr1.att.com. We talk nothing but UUCP. We don't know anything about other networks aside from the info gleaned from pathalias and smail. You can run smail with the -d (debug) flag, in which case it makes routing decisions but doesn't attempt any delivery (uux is not called). I have found the command smail -d user@site.domain.spec < /dev/null to be so useful that I have an alias set up for it. Consider the output of this command on some sample properly domainified addresses: "mbj@spice.cs.cmu.edu," a very real address I type all the time. Note that cbosgd is the local gateway (as far as my system's understanding is concerned) to reach the .edu domain. I believe it, in turn, hands it off to seismo. But I don't know for sure, and I don't care - the mail gets there. This is as it should be: users care about addresses, and back-end, low-level software cares about routes. resolve: parse address 'mbj@spice.cs.cmu.edu' = 'mbj' @ 'spice.cs.cmu.edu' (DOMAIN) getpath: looking for '.spice.cs.cmu.edu' getpath: looking for 'spice.cs.cmu.edu' getpath: looking for '.cs.cmu.edu' getpath: looking for 'cs.cmu.edu' getpath: looking for '.cmu.edu' getpath: looking for 'cmu.edu' getpath: looking for '.edu' route: 'spice.cs.cmu.edu' (edu) = 'cbosgd!%s' (99) resolve: parse route 'cbosgd!spice.cs.cmu.edu!mbj' = 'spice.cs.cmu.edu!mbj' @ 'cbosgd' (UUCP) resolve 'mbj@spice.cs.cmu.edu' = 'spice.cs.cmu.edu!mbj' @ 'cbosgd' (UUCP) COMMAND: /usr/bin/uux - cbosgd!rmail '(spice.cs.cmu.edu!mbj)' From Karl.Kleinpaste Wed Jun 17 10:41:24 1987 remote from cbstr1 Received: by cbstr1.att.com (smail2.3) id AA05995; 17 Jun 87 10:41:24 EDT (Wed) Date: 17 Jun 87 10:41:24 EDT (Wed) From: Karl.Kleinpaste@cbstr1.att.com Message-Id: <8706171041.AA05995@cbstr1.att.com> To: mbj@spice.cs.cmu.edu "joe@random.commercial.site.com," a hypothetical, but syntactically correct address. Cbosgd is again the route taken. resolve: parse address 'joe@random.commercial.site.com' = 'joe' @ 'some.random.commercial.site.com' (DOMAIN) getpath: looking for '.random.commercial.site.com' getpath: looking for 'random.commercial.site.com' getpath: looking for '.commercial.site.com' getpath: looking for 'commercial.site.com' getpath: looking for '.site.com' getpath: looking for 'site.com' getpath: looking for '.com' route: 'random.commercial.site.com' (com) = 'cbosgd!%s' (99) resolve: parse route 'cbosgd!random.commercial.site.com!joe' = 'random.commercial.site.com!joe' @ 'cbosgd' (UUCP) resolve 'joe@random.commercial.site.com' = 'random.commercial.site.com!joe' @ 'cbosgd' (UUCP) COMMAND: /usr/bin/uux - cbosgd!rmail '(random.commercial.site.com!joe)' From Karl.Kleinpaste Wed Jun 17 10:51:18 1987 remote from cbstr1 Received: by cbstr1.att.com (smail2.3) id AA06242; 17 Jun 87 10:51:18 EDT (Wed) Date: 17 Jun 87 10:51:18 EDT (Wed) From: Karl.Kleinpaste@cbstr1.att.com Message-Id: <8706171051.AA06242@cbstr1.att.com> To: joe@random.commercial.site.com "romig@ohio-state.edu." Local pathalias info tells smail that ohio-state.edu is the same host as osu-eddie. So that is the route taken, but the user doesn't even have to know that; "ohio-state.edu" is quite sufficient. resolve: parse address 'romig@ohio-state.edu' = 'romig' @ 'ohio-state.edu' (DOMAIN) getpath: looking for '.ohio-state.edu' route: 'ohio-state.edu' (ohio-state.edu) = 'osu-eddie!%s' (99) resolve: parse route 'osu-eddie!romig' = 'romig' @ 'osu-eddie' (UUCP) resolve 'romig@ohio-state.edu' = 'romig' @ 'osu-eddie' (UUCP) COMMAND: /usr/bin/uux - osu-eddie!rmail '(romig)' From Karl.Kleinpaste Wed Jun 17 11:09:45 1987 remote from cbstr1 Received: by cbstr1.att.com (smail2.3) id AA06689; 17 Jun 87 11:09:45 EDT (Wed) Date: 17 Jun 87 11:09:45 EDT (Wed) From: Karl.Kleinpaste@cbstr1.att.com Message-Id: <8706171109.AA06689@cbstr1.att.com> To: romig@ohio-state.edu "person@relay.csnet." My CSNet gateway is Ohio State, an X.25 CSNet site. Ohio State acts like a proper domain host these days, so I could modify our local pathalias data to use it for all .com, .edu, and .gov addresses if I cared to, but methinks that would be asocial. resolve: parse address 'person@relay.csnet' = 'person' @ 'relay.csnet' (DOMAIN) getpath: looking for '.relay.csnet' getpath: looking for 'relay.csnet' getpath: looking for '.csnet' route: 'relay.csnet' (csnet) = 'osu-eddie!%s' (99) resolve: parse route 'osu-eddie!relay.csnet!person' = 'relay.csnet!person' @ 'osu-eddie' (UUCP) resolve 'person@relay.csnet' = 'relay.csnet!person' @ 'osu-eddie' (UUCP) COMMAND: /usr/bin/uux - osu-eddie!rmail '(relay.csnet!person)' From Karl.Kleinpaste Wed Jun 17 10:53:01 1987 remote from cbstr1 Received: by cbstr1.att.com (smail2.3) id AA06306; 17 Jun 87 10:53:01 EDT (Wed) Date: 17 Jun 87 10:53:01 EDT (Wed) From: Karl.Kleinpaste@cbstr1.att.com Message-Id: <8706171053.AA06306@cbstr1.att.com> To: person@relay.csnet In summary, smail does exactly what it should do. Other sites in this dept that don't have UUCP set up to talk to Ohio State can still reach osu-eddie as a CSNet gateway, by way of cbstr1 or cbrma. I don't care about the intervening hops - smail takes an ADDRESS and generates a ROUTE, just like a pure transport agent should. Do you realize that, if every UUCP site ran smail, no one would ever again ask, "How do I get mail from UUCP to BITNET?" in comp.mail.misc? Gee, I don't know how I get there, let's find out: "zsyjkaa@wyocdc1.bitnet," an acquaintance at the University of Wyoming: resolve: parse address 'zsyjkaa@wyocdc1.bitnet' = 'zsyjkaa' @ 'wyocdc1.bitnet' (DOMAIN) getpath: looking for '.wyocdc1.bitnet' getpath: looking for 'wyocdc1.bitnet' getpath: looking for '.bitnet' route: 'wyocdc1.bitnet' (bitnet) = 'cbosgd!%s' (99) resolve: parse route 'cbosgd!wyocdc1.bitnet!zsyjkaa' = 'wyocdc1.bitnet!zsyjkaa' @ 'cbosgd' (UUCP) resolve 'zsyjkaa@wyocdc1.bitnet' = 'wyocdc1.bitnet!zsyjkaa' @ 'cbosgd' (UUCP) COMMAND: /usr/bin/uux - cbosgd!rmail '(wyocdc1.bitnet!zsyjkaa)' From Karl.Kleinpaste Wed Jun 17 11:22:17 1987 remote from cbstr1 Received: by cbstr1.att.com (smail2.3) id AA06986; 17 Jun 87 11:22:17 EDT (Wed) Date: 17 Jun 87 11:22:17 EDT (Wed) From: Karl.Kleinpaste@cbstr1.att.com Message-Id: <8706171122.AA06986@cbstr1.att.com> To: zsyjkaa@wyocdc1.bitnet I've been told that Harvard gets involved in that route, but it's at some point down the line that I really don't care about. So get off smail's case, try installing it and running it for a couple of weeks with valid pathalias information, and see how long it is before you forget how to type a `!' in a mail destination string. Karl
diamant@hpfclp.HP.COM (John Diamant) (06/22/87)
> >>As far as I can tell from the documentation, smail gives precedence to the ! > >>over the @ when it sees both in the address field of an incoming message. > > > >Since SMAIL is advertised as a RFC-compliant mailer, this can't be right. > > Well, the documentation to smail 2.3 says so. "To preserve compatibility with > rmail". But please enlighten me: why should there ever be a mixed address > in UUCP land? Please find this quote (with context). I have taken a quick look through the smail documentation and don't find anything of the sort. I do find plenty of references claiming RFC-822, 920 and 976 compatibility (in fact, it is an implementation of RFC-976, so it better be compatible with it). All these standards explicitly require "@" precedence, and indeed, the whole point of smail was to make the UUCP world RFC compliant. > > There is also no need rewrite the envelope unless the destination CANNOT deal > with it, so only gateways should have to do it, right? And a UUCP to RFC822 > gateway can always produce a <> route, and a RFC822 to UUCP gateway can always > produce a ! route, right? I wish it were that simple. Obviously, this is what you would have in an ideal world (only gateways worry about address translation), but it isn't that simple, unfortunately. First of all, RFC-822 source routes can only be used if each element is a registered domain (there are subtle points in the wording of RFC-822 which mandate this). This means, unregistered UUCP hosts cannot be put in source routes. One more problem is how to handle "%." Since it isn't specified by any standard, it must remain untouched, which might work O.K. if the precedence everywhere were always "@", "!", any other characters (including "%"), but some sites don't know anything about "!" and so interpret "%" as higher precedence than "!." When you translate from "!" addresses to RFC style addresses, how do know whether to use a source route or a "%?" I think translating to "!" from "@" style doesn't present any problem except that you can't reverse it because of the ambiguity. If you could guarantee that "!" always has higher precedece than any other character but "@," then you could just leave "%" alone (which smail does) and translate source routes into "!" routes. > > It is much more likely that we can get fixed gateways than asking all sites in > the universe to perpetuate the confusion between a route and an address. What > Rahul is asking is a new way to write routes, and we already have perfectly > unambiguous ways to do that. It certainly would be easier if all we needed is to get only gateways fixed, but I don't know how to hide all this from the non-gateway machines. > > Jean-Francois Lamy lamy@ai.toronto.edu > AI Group, Dept Computer Science {seismo,watmath}!ai.toronto.edu!lamy > University of Toronto, Canada M5S 1A4 John Diamant TSBU UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO