chris@cbosgd.UUCP (Christopher Seiwald) (06/03/85)
The return address "cbosgd!cbosgd.ATT.UUCP!chris" satisfies two needs: 1) It incorporates the sender's full domain-style address (chris@cbsogd.ATT.UUCP). So what? a: you may need it to reply reply from another host, where "x!y!z!cbosgd!chris" doesn't work and "chris@cbosgd.ATT.UUCP" does (if you buy domains). b: cbosgd, the last UUCP hop, will need it if the mail orginated off of UUCP. Think of "seismo!ucbcad.BERKELEY.ARPA!bob". 2) It insulates "chris@cbosgd.ATT.UUCP" from hostile hosts by disguising it as "cbosgd.ATT.UUCP!chris". Only hosts that can handle these addresses generate them, so other hosts needn't worry about them. ---- cbosgd!cbosgd.ATT.UUCP!chris is ugly, not stupid or wrong. If anyone has pretty ideas, I'd like to hear them. Thank You. Christopher Seiwald chris@cbosgd.ATT.UUCP
honey@down.FUN (Peter Honeyman) (06/03/85)
cbosgd!cbosgd.ATT.UUCP!chris is ugly, stupid, and wrong. it's ugly. res ipso loquitor. it's stupid. if you want to use a domain address, put it in the "From:" line, where arpa-style headers belong. the "From " line contains the uucp address of the sender; changing it disrupts uucp mail service. furthermore, it is patently stupid to equate a domain with a transport medium. get with the program, brutha. it's wrong. neither ATT nor UUCP is a domain. i suspect ATT will someday be a domain, subordinate to COM, not UUCP. UUCP is not a domain, and it never will be. ask your NIC. the whole point of dotted addresses in uucp style "From " lines is to obviate mixed associativity in routing operators, a problem that arises when mail crosses a gateway between less- than-compatible mail universes, e.g., uucp <--> arpa. if a host has trouble with x!y!z!cbosgd!chris, how does x!y!z!cbosgd!cbosgd.ATT.UUCP!chris help? why are you trashing perfectly valid, unambiguous addresses? and why are you going to such great effort to help cbosgd find itself? is it lost? cbosgd!cbosgd.ATT.UUCP!chris does more than simply disguise chris@cbosgd.ATT.UUCP: it disguises the uucp path traversed by the message. seismo!ucbcad.BERKELEY.ARPA!bob is ugly, and i would argue that it's stupid (use seismo!ucbcad!bob -- it's simple, consistent, and it works), and it will be wrong very soon (july 15? sure ...), but at least it attempts to address a substantive issue, not one made of whole cloth. pep/honey
hokey@plus5.UUCP (Hokey) (06/06/85)
Peter, this is the address vs. routing issue again. I suspect we might both agree that pure bang routes are unambiguous, at least with respect to syntactic parsing precedence. The use of domain names in bang paths also provides an advantage with respect to the syntactic determination of unambiguous routes in an environment in which there are duplicate host names. This ambiguity can be resolved semantically with an edge database, or syntactically with domain names. You like edge databases and semantic disambiguation. I like domain names. I am not aware of any sites which cannot handle the cbosgd!cbosgd.ATT.UUCP!... stuff. Of course, one of the main problems with mail in general is the lack of a decent user interface. Some deficiencies in the user interface are simply coming to the surface in the issue of addresses vs. routes. -- Hokey ..ihnp4!plus5!hokey 314-725-9492
avolio@decuac.UUCP (Frederick M. Avolio) (06/06/85)
In article <515@down.FUN>, honey@down.FUN (Peter Honeyman) writes: > cbosgd!cbosgd.ATT.UUCP!chris is ugly, stupid, and wrong. > it's stupid. if you want to use a domain address, put it in the > "From:" line, where arpa-style headers belong. the "From " line > contains the uucp address of the sender; changing it disrupts > uucp mail service. Well, probably nothing in the above (see Subject) line will disrupt uucp mail service. The real problem with the example is that cbosgd appears in two places. Let us pretend that the address looked like cbosgd!atthost123.ATT.UUCP!someone. Now it isn't as bad. Still ugly? Sure. But what does this say. I have something for a system (atthost123 is its name) in "domain" ATT.UUCP. Well, why not just say cbosgd!atthost123!someone? Because you are making assumptions about the transport mechanism in the latter. In the case of cbosgd!atthost123.ATT.UUCP!someone, a mailer said "I have something for a host in 'domain' [I know! More in a bit...] ATT.UUCP. I know that cbosgd is the 'closest' host which handles ATT.UUCP so I'll send it to them." > it's wrong. neither ATT nor UUCP is a domain. i suspect ATT > will someday be a domain, subordinate to COM, not UUCP. UUCP > is not a domain, and it never will be. ask your NIC. UUCP isn't a real live network either, is it? But it is useful to treat it as such a times, right? The idea of domains in the UUCP world to break down that world into managable parts doesn't have to strictly line up with the ARPA Internet Domain scheme, and I am not sure that it should. (Needless to say it can't.) (And anyone whose domain-base address is u@h.FUN is suspect anyway.... Kidding! Only kidding! See? :-) ) > seismo!ucbcad.BERKELEY.ARPA!bob is ugly, and i would argue that > it's stupid Don't sugar coat it. Speak your mind :-). Yes, but Ugly UUCP lines will be with us as long us people have systems which can only use the From_ line. One last example. If the above example had been a From_ line looking like "decuac!hostx.ATT.UUCP!user" the mail would get through. But this is not the same as "decuac!hostx!user" since decuac does not talk to "hostx." But we do know what to do with mail for hosts in "domain" ATT.UUCP. Why should a neighbor of ours know the full path to every site in the world when they can pass it off to a "smarter" neighbor? Ugly lines? Sure. Don't look at them. They get the job done and can allow hosts to handle mail they could not previously handle. -- Fred Avolio {decvax,seismo}!decuac!avolio 301/731-4100 x4227
gregbo@houxm.UUCP (Greg Skinner) (06/08/85)
> From: hokey@plus5.UUCP (Hokey) > I am not aware of any sites which cannot handle the cbosgd!cbosgd.ATT.UUCP!... > stuff. I don't think what we're arguing here is the unacceptability of cbosgd!cbosgd.ATT.UUCP by other sites, but the redundancy of the cbosgd. Reply- ing to a message which has the header >From cbosgd.ATT.UUCP!chris remote from cbosgd will cause the above to happen, which is handleable, but an eyesore as well. I did some checking into mail.c (Sys V) and picked out what is supposed to go into the From (not From:) line of a mail message. From <my_name> <date> remote from <thissys> where my_name is obtained from the user's LOGNAME, or the password file if LOGNAME isn't set, and thissys is obtained from a uname(2) call. Now in 4.2, I imagine these fields are obtained by doing similar things (uname replaced by a whoami or something similar) but a name like cbosgd.ATT.UUCP!chris was clearly not obtained by either of the means of obtaining my_name. Now I know that there are no rules as far as how the syntax of UUCP addresses should be, but perhaps we should at least stick to existing standards -- those that have already been set in software. Otherwise, poor dumb mailers will generate bad addresses unknowingly, and poor users who don't know any better will panic when they can't reply to messages. -- It's like a jungle sometimes, it makes we wonder how I keep from goin' under. Greg Skinner (gregbo) {allegra,cbosgd,ihnp4}!houxm!gregbo gregbo%houxm.uucp@harvard.arpa
david@ukma.UUCP (David Herron, NPR Lover) (06/11/85)
In article <1269@houxm.UUCP> gregbo@houxm.UUCP (Greg Skinner) writes: >> From: hokey@plus5.UUCP (Hokey) > >> I am not aware of any sites which cannot handle the cbosgd!cbosgd.ATT.UUCP!... >> stuff. > >I don't think what we're arguing here is the unacceptability of >cbosgd!cbosgd.ATT.UUCP by other sites, but the redundancy of the cbosgd. Reply- >ing to a message which has the header > >>From cbosgd.ATT.UUCP!chris remote from cbosgd > >will cause the above to happen, which is handleable, but an eyesore as well. > >I did some checking into mail.c (Sys V) and picked out what is supposed to go >into the From (not From:) line of a mail message. > >From <my_name> <date> remote from <thissys> > .... That mailer was written in the old days of a small network. One where it was possible to know (without referring to any tables) the complete connectivity of the network. That's not possible anymore. We need to have mailers which will route mail around without people having to know complete paths. Paths change. Are hard to discover. Sometimes are hidden. Might be broken due to hardware failures. A lot of things. But if you do something like the domain style addressing then there's a whole host of improvements that can be made. Now. I agree that cbosgd!cbosgd.ATT.UUCP!chris has redundant information. But I send mail to cbosgd (and recieve mail and reply to it) all the time. A month or two ago (when Mark installed his fancy sendmail.cf) I was having trouble replying to his messages because my sendmail.cf isn't smart enough to parse a two domain address (cbosgd.ATT.UUCP). It'd look up "cbosgd.ATT" as a system name. And I'd get mail back from the routing process that it couldn't find cbosgd.ATT. Now I can respond to him because he's got that cbosgd in the front. Basically it put off some hacking I'd have to do to Big Mail. Redundancy is sometimes usefull. Right? > >Now I know that there are no rules as far as how the syntax of UUCP addresses >should be, but perhaps we should at least stick to existing standards -- those >that have already been set in software. Otherwise, poor dumb mailers will >generate bad addresses unknowingly, and poor users who don't know any better >will panic when they can't reply to messages. If we keep using "poor dumb mailers" that's all we'll ever have. -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> --- or david%ukma.uucp@anl-mcs.arpa --- Or even anlams!ukma!david@ucbvax.arpa --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david "It's *Super*User* to the rescue!"
jer@peora.UUCP (J. Eric Roskos) (06/12/85)
> We need to have mailers which will route mail around without people > having to know complete paths. Paths change. Are hard to discover. > Sometimes are hidden. Might be broken due to hardware failures. > A lot of things. But if you do something like the domain style addressing > then there's a whole host of improvements that can be made. I keep seeing statements like this. Are we saying that using domains to qualify site names is going to help this problem, or just that automatically generating the routing without the user having to specify it is going to do this? -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Gnyx gb gur fhayvtug, pnyyre..."
jordan@ucbvax.ARPA (Jordan Hayes) (06/13/85)
In article <1055@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >> We need to have mailers which will route mail around without people >> having to know complete paths. Paths change. Are hard to discover. >> Sometimes are hidden. Might be broken due to hardware failures. >> A lot of things. But if you do something like the domain style addressing >> then there's a whole host of improvements that can be made. > > I keep seeing statements like this. Are we saying that using domains to > qualify site names is going to help this problem, or just that automatically > generating the routing without the user having to specify it is going to > do this? >-- >Full-Name: J. Eric Roskos Domains will localize the problems of knowing exactly how to get from a to z via b,c,d... in advance. Essentially it will allow sites to be "local_experts" who can change actual routing to "local_sites" or to <--> from the next domain, but joe_blow@a doesn't have to know the entire topology of the net to get his message to jane_snow@z. Certainly nothing can help the problem of sites going down or changing who they trust enough to call, but joe just wants to put his mail in a mail box and have jane get it sometime soon. Hopefully the domains will be flexible enough so that changes in the local routing won't be disasterous to performance. routing != addressing (at least with domains). UUCP is too big for that anymore. users should not have to be concerned about local site politics that govern routing. Also, it becomes the responsibility of each individual host administrator to make sure that the routing it does is as efficient as possible. Those decisions can only be made by someone who knows what's going on at his site. Not by poor joe who doesn't even know what ihnp4 *stands* for ;~) Enough discussion. When are we going to see some *action* ??! /jordan ------- ARPA: jordan@ucb-vax.BERKELEY.EDU UUCP: jordan@ucbvax.UUCP
hokey@plus5.UUCP (Hokey) (06/20/85)
The primary issue is sending mail. It is desireable to minimize typing. It is desireable to unambiguously specify the *address* of the recipient. If cbosgd is sending mail to a "dumb" site, sufficient *routing* information must be added to permit replies to be delivered (via dumb mailers). As more and more machines hit the net, we have a problem with name collisions. One solution to this problem is domains. The domain form is "rooted", which makes it possible to have duplicate machine names without fear of causing mailers to choke. The bang-format names can only be used to provide duplicate names under specific semantic circumstances. The domain scheme provides these conditions syntactically. It just so happens that the domain name of cbosgd happens to be cbosgd.att.uucp. People can look at this, and "know" that site names exist below the att.uucp, but this is a *semantic* decision! The initial cbosgd! gets prepended specifically to provide backward-compatability with dumb mailers. If your mailer does not need this information, there are two solutions: tell cbosgd not to automatically do this for you, or tell your sendmail to strip it off. Both capabilities are useful. In either of the latter two cases, make sure your mailer really is smart enough to handle the consequences! -- Hokey ..ihnp4!plus5!hokey 314-725-9492