lear@turbo.bio.net (Eliot) (07/23/90)
Actually your summary raises a few more questions, Chip. Who pays the bills for the EMail that is passed? How can they control their costs, if necessary? What arguments can be used to encourage a potential provider to allow mail through, and what arguments can be used to discourage those same people, or existing providers? Do these same people have the right to control the route your mail takes, given that you are using their resources? -- Eliot Lear [lear@turbo.bio.net]
chip@tct.uucp (Chip Salzenberg) (07/27/90)
According to lear@turbo.bio.net (Eliot): >Who pays the bills for the EMail that is passed? Money is an utterly separate issue from mail headers. That said... >Do these same people have the right to control the route your mail >takes, given that you are using their resources? Sure. And they have the right to drop my mail on the floor, too. I, of course, have the right to consider them EVIL and RUDE for exercising their rights in such uncooperative and antisocial ways. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
lear@turbo.bio.net (Eliot) (07/29/90)
Money has everything to do with it. I consider it evil and rude for you to take a suboptimal route by making a machine place any unnecessary call that will cost money; and if you don't believe that happens, you should see just how many people still use news paths to get their replies through; you should see just how many weird UUCP addresses get left in mailing list files and forgotten. I consider it evil and rude for you to even complain that any site from which you derive a FREE service sends your mail by a faster and or cheaper path. YOU are not paying the bill. Even in the case of UUNET customers, they only pay a small fraction of the cost of the delivery of their mail. -- Eliot Lear [lear@turbo.bio.net]
perand@admin.kth.se (Per Andersson) (07/29/90)
In article <Jul.28.10.54.12.1990.2245@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: >Money has everything to do with it. I consider it evil and rude for >you to take a suboptimal route by making a machine place any ........ Very true. There seems to be very many people in the US the thinks it is a duty of the Internet to transport their mail just because they happen to have a UUCP connection to a local university. They could at least be grateful and get registered to help administration, or why can't the unregistered UUCP network at least try to do something about it. Email is NEVER free. Probably somebody else are paying for your mail, and occupying megs and megs of disk to keep in touch with you. In sweden there are no .UUCP nodes ( to my knowledge ), and registration is 1000Skr/year for membership in the Europeean Unix users group, which includes the ability to register domains. Just putting some wood on the fire. -- --- Per Andersson Royal Institute of Technology, Stockholm, Sweden perand@admin.kth.se, @nada.kth.se
lmb@vicom.com (Larry Blair) (07/29/90)
In article <Jul.28.10.54.12.1990.2245@turbo.bio.net> lear@turbo.bio.net (Eliot) writes:
=Money has everything to do with it. I consider it evil and rude for
=you to take a suboptimal route by making a machine place any
=unnecessary call that will cost money;
Not half as rude as sending mail off to oblivion.
Yes Eliot, I'm still here. I just get tired of pointing out the obvious
after the umptenth time. Down boy, or I'll sic Paul on you.
Do I really need the smiley?
--
Larry Blair ames!vsi1!lmb lmb@vicom.comlear@turbo.bio.net (Eliot) (07/30/90)
In article <1990Jul29.073316.16433@vicom.com> lmb@vicom.com (Larry Blair) writes: > [Eliot calls freeloaders who complain ``rude''.] > Not half as rude as sending mail off to oblivion. When you use someone else's resources gratis, your only POLITE dissent is to stop using them. Go ask Miss Manners. > Yes Eliot, I'm still here. I just get tired of pointing out the obvious > after the umptenth time. Down boy, or I'll sic Paul on you. Only in the U.S. UUCP community do people forget who pays the bills. > Do I really need the smiley? If I tried to argue your side, I'd use lots of them. -- Eliot Lear [lear@turbo.bio.net]
peter@ficc.ferranti.com (Peter da Silva) (07/30/90)
In article <Jul.28.10.54.12.1990.2245@turbo.bio.net> lear@turbo.bio.net (Eliot) considers it... > evil and rude for you to even complain that any site from which you > derive a FREE service sends your mail by a faster and or cheaper path. If your faster or cheaper path ends up breaking the mail delivery, you then find yourself fielding a bounced message, and a couple of repeats. Spoiling the ship for a ha'porth of tar is the expression for this sort of thing. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/30/90)
In article <Jul.29.14.31.02.1990.4335@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: > > In article <1990Jul29.073316.16433@vicom.com> lmb@vicom.com (Larry Blair) writes: > > [Eliot calls freeloaders who complain ``rude''.] > > Not half as rude as sending mail off to oblivion. > > When you use someone else's resources gratis, your only POLITE dissent > is to stop using them. Go ask Miss Manners. That is interesting. I guessed Miss Manners would say that it is rude to impose upon others, and even more impolite to complain if their performance in your service is incompetent. However, my obviously flawed upbringing says that if you cannot or will not accede to a request, then you must politely refuse (e.g. by bouncing a mail message). I would have have guessed Miss Manners would say you cannot accept a task and do anything except do your best to complete it, exactly as the requester intended. I thought the rudeness of the original request is irrelevant. I also would have guessed that a public and unsolicited offer to do a service (e.g. publishing a map entry listing out-going connections) would not make those who occassionally avail themselves of such invitations "freeloaders." I would have guessed that those served would only to be obliged to be polite. In some circumstances, I would have thought it necessary to find a polite excuse to refuse the invitation. It even seemed to me, until now, that if the invitation turn out to be other than as advertised, a polite and perhaps public note to that effect would not be rude. Would it be rude to ask that those who choose to not honor the routes in passing mail to not advertise their connections? Am I wrong in thinking that the UUCP maps are not a way to brag of the number of UUCP links you maintain, but are an offer to do a service, without expectation of payment or even reciprocity? Vernon Schryver vjs@sgi.com
emv@math.lsa.umich.edu (Edward Vielmetti) (07/30/90)
In article <65517@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
Would it be rude to ask that those who choose to not honor the routes in
passing mail to not advertise their connections? Am I wrong in thinking
that the UUCP maps are not a way to brag of the number of UUCP links you
maintain, but are an offer to do a service, without expectation of payment
or even reciprocity?
There is a construct in the UUCP maps that allows sites to advertise limited
connectivity to links, and to specify a different weight for pass-through
and terminal connections. If you do not want just anyone to use a link, a
sane thing to do is publish a map with higher costs and/or terminal links,
then use a real map with real costs when you run pathalias.
If your intent is to do a service to the community, and you are on the
internet, then advertising connectivity via UUCP maps is not much of
a service. Much better would be to register your UUCP neighbors in the
proper domain and provide MX services to them.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>tneff@bfmny0.BFM.COM (Tom Neff) (07/30/90)
In article <65517@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Would it be rude to ask that those who choose to not honor the routes in >passing mail to not advertise their connections? Am I wrong in thinking >that the UUCP maps are not a way to brag of the number of UUCP links you >maintain, but are an offer to do a service, without expectation of payment >or even reciprocity? Well, I think part of the problem here is that link COST isn't always factored in. Sure, I can advertise links to 7 neighbors in the maps, but I may COST a number of them very high, and others cheaply. Now, 'pathalias' will look at this and try to do the right thing with routing. But if an inattentive user assembles a path by hand, without reference to the cost field, he may pick expensive LD links when a local call would have done. And that is rude, no doubt about it. Advertising a link is not the same as advertising a CHEAP link. When a site makes public an expensive LD link, it is implicitly relying on the courtesy of the net (and the brains of pathalias) not to misuse the facility. I sympathize with sites who reroute to minimize their costs, and I consider it good for the net as a whole because it lets more sites pass more messages per dollar. It might be interesting to try a Reroute: {No|Yes|Rightmost} header field. Let the sender indicate how free he's willing to let intermediate sites be with routing. If he cannot abide any rerouting of a message, but an intermediate site insists, bounce the message. -- War is like love; it always \%\%\% Tom Neff finds a way. -- Bertold Brecht %\%\%\ tneff@bfmny0.BFM.COM
" Maynard) (07/30/90)
In article <Jul.28.10.54.12.1990.2245@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: >I consider it >evil and rude for you to even complain that any site from which you >derive a FREE service sends your mail by a faster and or cheaper path. Do you consider it evil and rude for someone to complain that a site rerouted mail in such a fashion that it didn't get where it was supposed to go when the original path would have gotten it there? No flame - I'm genuinely curious. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. "It's a hardware bug!" "It's a +---------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
tp@mccall.com (07/30/90)
[This article is not directed at Eliot, per se, but to anyone who reroutes all mail based on the tail end of the path (such people are referred to as "you" below). This is not directed at people who reroute mail if it is otherwise undeliverable. I didn't receive the beginning of this thread, so I apologize if this is off the subject.] In article <Jul.28.10.54.12.1990.2245@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: > I consider it > evil and rude for you to even complain that any site from which you > derive a FREE service sends your mail by a faster and or cheaper path. Why not route the message to the first element of the path rather than the last? Since the first element of the path is a site your host presumably knows about (since you advertised that you did), there is little chance you will get it wrong. If you route to the end of the path, you will sometimes get it wrong. You have no guaranteed knowlege about anything in the path past the first link. It will often consist exclusively of uucp sites in the maps, but if it is anything else, you will likely break it. When the mail goes off into left field, it is either lost or bounced. Either way, you are unlikely to hear about it. It may happen more often than you think. Lord knows I'm not going to send mail to rutgers (the site nearest me that reroutes every piece of mail by the end links on the path) every time they derail one of my mail messages. I, and I expect many others, am more likely to try to find a useable route and try again. Note that this often means I must abandon pathalias and do explicit source routing by hand. You may be willing to address the problem, but many site admins aren't, and most people have better things to do than figure out that it was your site that blew it, and then contact you to explain it to you, just to get one lousy piece of mail delivered. It is usually possible to explicitly route around a system one way or another. Unfortunately, at this site I'll have to do it, as nobody else at this site knows how... > YOU are not paying the bill. If you are unwilling to let the link be used, why publish it? I don't deny your right to do whatever you want with the mail, but it is certainly impolite to advertise a link and then refuse to allow the useage of that link. Doing so may very well trick pathalias into sending a message to you that would otherwise have gone via a different route entirely. Does it cost you any more to use the minimal solution, rerouting to the first system on the path? My understanding of the maps, which appears to be different from yours, is that your map entry specifies that you will deliver mail to certain specific systems. Costs are given to indicate your degree of willingness to do this. Your understanding seems to be that the map entry is for describing physical connectivity only, with no implication of how routing through your system should be done. Correct me if I'm wrong. If that IS how you feel, I would submit that since the map entry is specifically intended to be input for pathalias, that routing information IS implied and your conclusion is incorrect. By the way, I don't care how you get mail to the next system in the path (one that you have advertised a link to), though it would be nice if the time delay in doing so corresponded in some way to the published cost. Pathalias will use whatever you give it. If you cost things appropriately, it should generate routes that accord with your local policies. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
lmb@vicom.com (Larry Blair) (07/30/90)
In article <Jul.29.14.31.02.1990.4335@turbo.bio.net> lear@turbo.bio.net (Eliot) writes:
=
=When you use someone else's resources gratis, your only POLITE dissent
=is to stop using them. Go ask Miss Manners.
No one is saying that if I ask your system to send my mail to x that you
have to call x. You can pick whatever route you want to send it to x.
Just don't look any further down my path.
--
Larry Blair ames!vsi1!lmb lmb@vicom.comlear@turbo.bio.net (Eliot) (07/31/90)
You are most certainly correct that a UUCP map entry is an offer to do a service without expectation of payment or reciprocity. We differ in belief as to what that service is. By declaring links in a map, I offer a mail service to specific sites. I make no claims what I will do with a header, other than that I will conform to RFC 1123, and that I *will* optimize UUCP paths. My neighbors understand this. You might also argue that the service is incompetant, but such a statement requires backing. I would argue that my rabid rerouter is far more compentant than the users who send mail through me. My rerouter's information reflects a dynamic topology, of which many changes go unnoticed. I handle several hundred pieces of UUCP mail per week, and reroute each one of them. In the two years that I've been rerouting, I've received two complaints associated with the optimization. Both problems were promptly resolved. A public note might be a reasoble recourse if the sytem administrator failed to respond, if your mail is getting where it needs to go, you have no basis for complaint. By the way, the rudeness of the original request is the point we are arguing, so it would not be irrelevant. Technically, when handling oneself, my understanding is that the rudeness of others is always irrelevant, be it the requesting or the requested. -- Eliot Lear [lear@turbo.bio.net] -- Eliot Lear [lear@turbo.bio.net]
fitz@wang.com (Tom Fitzgerald) (07/31/90)
lear@turbo.bio.net (Eliot) writes: > I consider it evil and rude for > you to take a suboptimal route by making a machine place any > unnecessary call that will cost money; > I consider it > evil and rude for you to even complain that any site from which you > derive a FREE service sends your mail by a faster and or cheaper path. You advertise, in your UUCP map entry, connections to a dozen other sites. Is it evil or rude, for someone to build a UUCP path that passes through your machine to one of those sites? If you don't want this mail passing through your system, why are you advertising the links, with those costs? If you're getting UUCP paths that have ...!bionet!something!... where 'something' isn't one of your neighbors, this is broken and I assume you bounce the mail. > YOU are not paying the bill. Even in the case of UUNET customers, > they only pay a small fraction of the cost of the delivery of their > mail. And we pay a part of the cost of delivering other peoples' mail, too. If we didn't think it was worth it, we wouldn't publish the links. One thing we _don't_ do is advertise a link then refuse to pass mail through it. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
lear@turbo.bio.net (Eliot) (07/31/90)
I claim that I will be wrong fewer times than the users passing mail through me. In addition I'll be respecting the wishes of those who use the map data to control just how much volume will pass through their sites. Given the following path: bionet!uwm.edu!wuarchive!uunet!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!tp compared to bionet!deimos.cis.ksu.edu!mccall!tp, which would you think more expensive? I make several checks to do all but eliminate the chances that the mccall at the end will be any other mccall but your mccall. The possibility for an incorrect path if you are registered with the UUCP maps is nonexistant. -- Eliot Lear [lear@turbo.bio.net]
tp@mccall.com (07/31/90)
In article <Jul.30.17.57.18.1990.9079@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: > I claim that I will be wrong fewer times than the users passing mail > through me. In addition I'll be respecting the wishes of those who > use the map data to control just how much volume will pass through > their sites. > > Given the following path: > > bionet!uwm.edu!wuarchive!uunet!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!tp Are there still news systems that use the Path: line for replies? That is the only way someone could generate the above garbage. My From: address is tp@mccall.com, and any mail to that address will generate an optimal path according to pathalias. Any news system that does that is broken (always was). Lean on the sender to fix it. Few people actually generate paths by hand all the way to the destination. Other than broken news systems, who's paths are you trying to fix? > compared to bionet!deimos.cis.ksu.edu!mccall!tp, which would you think > more expensive? If you generate this path, your system is wrong. Mail should never reach me through deimos.cis.ksu.edu (which is dedicated to being a news server). Your path is no more correct than the original. In this particular case yours is shorter and faster and both will work, but that isn't always true. Some news links don't pass mail. > I make several checks to do all but eliminate the chances that the > mccall at the end will be any other mccall but your mccall. The > possibility for an incorrect path if you are registered with the UUCP > maps is nonexistant. And conversely if a site is not in the maps, I take it the chance of error is 100%? It certainly is if an unmapped site has the same name as one that is in the maps. (I really would be curious as to what checks can be made to verify a path.) Once upon a time, my email address was <tp%mccall.claremont.edu@cunyvm.cuny.edu>. Expressed as a bang-path, this would be "...!cunyvm.cuny.edu!mccall.claremont.edu!tp". How would your system route this? As "bionet!mccall.claremont.edu!tp"? If so, and if you aren't on bitnet, you just lost my mail. Neither "mccall.claremont.edu" nor "claremont.edu" was at that time a registered domain on the internet. They only existed on bitnet. That's a real-world example. I don't know if it applies to bitnet anymore, but nobody can state definitively that it doesn't apply anywhere. Yes it is an ugly address, but there is no reason to drop the mail because of it. In the case you stated, does it cost you any more to send to uwm.edu than to send to deimos.cis.ksu.edu? Granted I'll get my mail sooner via your route, but some people won't get it at all by going through your machine. As I said, rutgers does the same thing you do. I can't generally reach sites in weird places like milnet (which generally require one or more "%" in their address) through rutgers, and have to manually reroute. Maybe your system is smarter, I don't know. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
tp@mccall.com (07/31/90)
Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 82 In article <EMV.90Jul31131351@urania.math.lsa.umich.edu>, emv@math.lsa.umich.edu (Edward Vielmetti) writes: > In article <3275.26b54aab@mccall.com> tp@mccall.com writes: > > Once upon a time, my email address was > <tp%mccall.claremont.edu@cunyvm.cuny.edu>. ... > > If you use a domain name that doesn't belong to you, you deserve to > lose. That simple enough? cf *.austin.ibm.com. It did belong to me. It was assigned to me by the administrator of the higher level domain (claremont.edu), over which I had absolutely no control. I wasn't even aware that it was unregistered until I was informed that mail to me bounced. In article <Jul.31.10.33.49.1990.675@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: > There are an absurdly large number of sites that use the news reply > path, and for me to bang on each one of them would be a waste of my > time. Much easier is it to just reroute their mail. OK, I can see your justification for rerouting. I'd been away from the net for a while, and thought that problem had pretty much cleared up. I think I like the suggestion someone else posted: if you send news over a link that you don't want carrying mail, throw a monkey-wrench into the path line so that it will bounce. It is your right to control how the link is used, and it might get people to upgrade their software so as to not use the Path: line improperly. > Actually, I lied. In that particular case, I would have routed to > uunet.uu.net, because I do neighbor checking, and uunet doesn't > register a neighbor named maverick.ksu.ksu.edu. So even if there are > ghost sites in the maps, it would take a particularly weird UUCP setup > to throw me off (even with your unregistered domain). I'm glad to hear it. I don't think most rerouters go to that much trouble (and all my complaints still apply to the rest of them). I assume that by neighbor checking, you mean that you check each hop of the path to see if the maps list a connection between those sites. I further assume that if you find a hop that isn't listed in the maps, you route to the site before it (i.e to the last site to which the path was verified). If my assumptions are correct, I can't think of a case you can't handle properly. MOST sites that I have been aware of from time to time that did aggressive rerouting used the algorithm supplied by smail, which is to route to the rightmost host in the bang path that can be found in the maps. This is extremely bad, and subject to all the gripes I've mentioned. To all rerouters: Please, if you MUST reroute, do it the way Eliot does (or the way I assume he does it), or route only to the first hop on the path. DO NOT do it the way smail does it. I think it is smail -R that does this (haven't been on unix for a few years, so I'm not sure), and the docs recommend you don't use it! > To have a domain and not register it would be silly. It happens all > the time, but it never lasts long; it's simply too easy to Do The > Right Thing(tm) and get it registered. Still, why bounce it if you don't have to? Again, neighbor checking seems to handle it, but most rerouters don't. > There are several issues that rabid rerouters have to take into > account, and one of them is that ghost sites exist. Another is that > the pathalias databases must be consistant accross the network. A > potential for failure could be rutgers using new maps but not > distributing them. Another would be rutgers distributing them, and a > rabid rerouter not not using them. This has not happened, to the best > of my knowledge. I have no specific knowlege as to how rutgers reroutes mail. I simply know that I frequently route around them. I tend to doubt that the problem comes from maps being out of sync, but I don't know that either. At a previous site, several years ago, I was eventually forced to declare them dead to pathalias. This was back when VERY few sites were registered, and the potential for error was much greater. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
emv@math.lsa.umich.edu (Edward Vielmetti) (08/01/90)
In article <3275.26b54aab@mccall.com> tp@mccall.com writes:
Once upon a time, my email address was
<tp%mccall.claremont.edu@cunyvm.cuny.edu>. Expressed as a bang-path, this
would be "...!cunyvm.cuny.edu!mccall.claremont.edu!tp". How would your
system route this? As "bionet!mccall.claremont.edu!tp"? If so, and if you
aren't on bitnet, you just lost my mail. Neither "mccall.claremont.edu" nor
"claremont.edu" was at that time a registered domain on the internet. They
only existed on bitnet.
If you use a domain name that doesn't belong to you, you deserve to
lose. That simple enough? cf *.austin.ibm.com.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>lear@turbo.bio.net (Eliot) (08/01/90)
There are an absurdly large number of sites that use the news reply path, and for me to bang on each one of them would be a waste of my time. Much easier is it to just reroute their mail. Actually, I lied. In that particular case, I would have routed to uunet.uu.net, because I do neighbor checking, and uunet doesn't register a neighbor named maverick.ksu.ksu.edu. So even if there are ghost sites in the maps, it would take a particularly weird UUCP setup to throw me off (even with your unregistered domain). To have a domain and not register it would be silly. It happens all the time, but it never lasts long; it's simply too easy to Do The Right Thing(tm) and get it registered. There are several issues that rabid rerouters have to take into account, and one of them is that ghost sites exist. Another is that the pathalias databases must be consistant accross the network. A potential for failure could be rutgers using new maps but not distributing them. Another would be rutgers distributing them, and a rabid rerouter not not using them. This has not happened, to the best of my knowledge. -- Eliot Lear [lear@turbo.bio.net]
del@thrush.mlb.semi.harris.com (Don Lewis) (08/01/90)
In article <3275.26b54aab@mccall.com> tp@mccall.com writes: >In article <Jul.30.17.57.18.1990.9079@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: >> I claim that I will be wrong fewer times than the users passing mail >> through me. In addition I'll be respecting the wishes of those who >> use the map data to control just how much volume will pass through >> their sites. >> >> Given the following path: >> >> bionet!uwm.edu!wuarchive!uunet!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!tp > >Are there still news systems that use the Path: line for replies? That is >the only way someone could generate the above garbage. My From: address is >tp@mccall.com, and any mail to that address will generate an optimal path >according to pathalias. Any news system that does that is broken (always >was). Lean on the sender to fix it. Few people actually generate paths by >hand all the way to the destination. Other than broken news systems, who's >paths are you trying to fix? When building rn, if you #define INTERNET, when replying to an article, rn uses %t for the To: address. If you do not #define INTERNET, rn uses %T for the To: address. Quoting from the man page: %t "To:" line derived from the "From:" and "Reply-To:" lines of the current article. This always returns an Internet format address. %T "To:" line derived from the "Path:" line of the current article to produce a uucp path. If something better was implemented for the non-Internet case, it might cut down on the number of monstrous paths seen in mail addresses. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
bob@MorningStar.Com (Bob Sutterfield) (08/01/90)
In article <EMV.90Jul31131351@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: If you use a domain name that doesn't belong to you, you deserve to lose. That simple enough? cf *.austin.ibm.com. Right. And one case of a domain name that doesn't belong to you is one that doesn't exist. In article <Jul.31.10.33.49.1990.675@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: There are an absurdly large number of sites that use the news reply path, and for me to bang on each one of them would be a waste of my time. Much easier is it to just reroute their mail. Such broken (RFC1036, section 2.1.6, fourth paragraph, first sentence) sites shouldn't be coddled. Their mail should simply be bounced. In this example I find myself in the remarkable position of being more rabid even than Karl :-) To have a domain and not register it would be silly. It happens all the time, but it never lasts long; it's simply too easy to Do The Right Thing(tm) and get it registered. This makes no sense at all, which may be why you referred to it as silly. To have a domain implies by definition that it is registered. Until a DNS query of NS.NIC.DDN.MIL returns the correct sort of information, "foo.com" is just a string of characters, not a domain. And yes, people construct silly strings of characters all the time - just read news.groups :-)
cyrill@scicom.AlphaCDC.COM (Cyro Lord) (08/01/90)
I'm not going to quote anyone but seem to me that the person at ohio U is
more correct than anyone so far. The net is buildt on COOPERATION and good
will, not someone trying to tell site operators how to operate and that means
delivery of the mail also. Pathalias output is a tools which is not fixed in
iron. Only I and the sites around me know the daily/weekly/monthly conditions
of the mail/news paths or the wishes of the other site operators around here.
So, if my mail is rerouted, big deal, if it's that important, call direct and
deliver your mail direct. Stop bad mouthing siteadmin persons that want to
reroute as this is the way they need/want to operate and the name of
that tune is "I never made you any promises(, so stop holding my leg!)".
--
Cyro Lord Alpha Comm. Dev. Corp. - DOMAIN cyrill@scicom.alphacdc.com
UUCP {ncar,nbires,boulder,isis}!scicom!cyrill
Endeavor to Persevere - Chief Dan Georgevjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/01/90)
In article <Jul.30.17.57.18.1990.9079@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: > [...the usual rationalization for doing other than what his > map entry promises...] As has been said many times, not all machines are permitted in the maps. The machine "apple.sgi.com" exists, and answers to "apple" as well as "apple.sgi.com". For good reasons I am sure you know, that machine will never be permitted in maps by the N.Calif. map coordinators. If I had anything to say about it, the machine would not be named "apple.sgi.com", or even "apple.corp.sgi.com" simply because it would be too similar to the other machine named "apple". However, I don't have any say, and even if I did, the arguement that Domains Save All would still be valid. (I suppose it's too much to hope that no one will suggest that the users of machines on the same ethernet as apple.sgi.com be forced to type "user@apple.sgi.com" instead of "user@apple".) If you reduce the UUCP path "bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user" into "bionet!apple!user" or "user@apple.com" then you have just gratuitously bounced someone's mail. Please notice that bionet, oracle, decwrl, sgi, *.sgi.com, apple.com, and apple are all in the maps. This is not a case of update induced instability. The maps do not, are not, cannot, and never will be a complete list of all hostnames everywhere. I think it is not only rude but deceitful to advertise an HOURLY link to oracle and then not let someone use it, as would be the case if you rewrite as I've inferred. Please do not be too offended (a little might be productive) when I observe that the need to control too much of too many things is a common disease among those who have inherited a mantle of "Postmaster" or "System Administrator," and are trying to do the best job possible. It is hard to realize that it is often better to do less. Vernon Schryver vjs@sgi.com
eps@toaster.SFSU.EDU (Eric P. Scott) (08/01/90)
While netnews is commonly thought of as "usenet software," by now you should be aware that it is often used in other ways: for example, to distribute "alternative" hierarchies in parallel with the seven sisters. Now imagine, if you will, an organization with an isolated, internal network, that likes the functionality and available user interfaces we enjoy, and wants to deploy it for their own use. It may make sense for them to choose the non- INTERNET configuration. What the documentation should clearly state for sites that are using netnews for ->usenet<- traffic, that INTERNET should ALWAYS be #defined (even for sites not "on" the Internet, and even for sites not running pathalias). Path: lines DO NOT WORK FOR REPLY. Maybe for intra-Eunet traffic, but not in general. It doesn't make sense in North America. The "INTERNET" conditional may be misnamed, but it's a bit late to change it. -=EPS=-
steve@thelake.mn.org (Steve Yelvington) (08/01/90)
[In article <BOB.90Jul31180637@volitans.MorningStar.Com>,
bob@MorningStar.Com (Bob Sutterfield) writes ... ]
> ... To have a domain implies by definition that it is registered.
> Until a DNS query of NS.NIC.DDN.MIL returns the correct sort of
> information, "foo.com" is just a string of characters, not a domain.
> And yes, people construct silly strings of characters all the time -
> just read news.groups :-)
This leads to something I've been wondering about: What about third- and
greater-level domains, as in "bozo.foo.com"? Is there a need for them to
be registered?
The reason I ask is that I have one such site, within the registered
.mn.org domain, but not individually listed in the nic.ddn.mil database.
(I've looked.)
I have seen that mail to thelake.mn.org from Internet sites sometimes
fails with error messages indicating that there is no such domain. But I
thought that one of the big advantages of having a qualified, registered
domain was that multiple sites could be served with a single listing.
--
Steve Yelvington at the (rain-replenished) lake in Minnesota
steve@thelake.mn.orgemv@math.lsa.umich.edu (Edward Vielmetti) (08/01/90)
In article <65793@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
If you reduce the UUCP path
"bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user"
into
"bionet!apple!user" or "user@apple.com"
then you have just gratuitously bounced someone's mail.
If you use fully qualified domain names whenever there is ambiguity, then
your own mail will not be bounced.
If (random, internal) hosts put their fully qualified domain names in
Path: headers, then this path would look like
"bionet!oracle!decwrl!sgi!oni.sgi.com!apple.oni.sgi.com!user"
et voila, no ambiguity, no bounced.
And besides, if someone actually is posting news from this apple machine
internal to sgi, that news will never make it to the "real" apple, if
it puts "apple!" into the Path header and it's in the maps.
Posting from "urania" but you'd never know it,
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>lear@turbo.bio.net (Eliot) (08/01/90)
Again, I do neighbor checking. Thus, your example path bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user would be routed to apple!user@oni.sgi.com. -- Eliot Lear [lear@turbo.bio.net]
amanda@mermaid.intercon.com (Amanda Walker) (08/01/90)
In article <65793@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > If you reduce the UUCP path > "bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user" > into > "bionet!apple!user" or "user@apple.com" > then you have just gratuitously bounced someone's mail. What's wrong with bionet!oracle!decwrl!sgi!apple.sgi.com!user ..? If 'sgi' knows about oni.sgi.com, why wouldn't it know about any other machine in its domain? From the start of Usenet, UUCP host names have always supposed to be unique. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
lmb@vicom.com (Larry Blair) (08/02/90)
In article <EMV.90Aug1123831@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: =In article <65793@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: = = = If you reduce the UUCP path = "bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user" = into = "bionet!apple!user" or "user@apple.com" = then you have just gratuitously bounced someone's mail. = =If you use fully qualified domain names whenever there is ambiguity, then =your own mail will not be bounced. = =If (random, internal) hosts put their fully qualified domain names in =Path: headers, then this path would look like = "bionet!oracle!decwrl!sgi!oni.sgi.com!apple.oni.sgi.com!user" =et voila, no ambiguity, no bounced. Why do I end up allways getting into these discussions? What `apple' means to sgi.com is no one's business but sgi.com. Just leave it alone! =And besides, if someone actually is posting news from this apple machine =internal to sgi, that news will never make it to the "real" apple, if =it puts "apple!" into the Path header and it's in the maps. How about apple.com? You know, I know that you rabid rerouters mean well. You're just trying to cure a genuine problem that comes from reverse-routitis. But I have found a far more effective solution. Every once in a while, when things are slack, I'll identify a site or two that are generating a lot of these garbage paths and send the postmaster some mail about it. This has, on several occasions, been effective. -- Larry Blair ames!vsi1!lmb lmb@vicom.com
lear@turbo.bio.net (Eliot) (08/02/90)
First, Larry, when you catch up on your reading, you will find that I do the right thing in those instances. And it is a rare event indeed when my mailer reroutes a message to the bit bucket. Next, In article <1990Aug1.183347.11916@vicom.com> lmb@vicom.com (Larry Blair) writes: > Every once in a while, when things are slack, > I'll identify a site or two that are generating a lot of these garbage paths > and send the postmaster some mail about it. This has, on several occasions, > been effective. My solution is 100% effective, all the time, without my spending time on the issue (except now). -- Eliot Lear [lear@turbo.bio.net]
I.G.Batten@fulcrum.bt.co.uk (Ian G Batten) (08/02/90)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > As has been said many times, not all machines are permitted in the maps. > > If you reduce the UUCP path > "bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user" > into > "bionet!apple!user" or "user@apple.com" > then you have just gratuitously bounced someone's mail. The UK news backbone attempts to ensure that all names stamped into Path: headers are either fqdn or real uucp map entries. When my news installation consisted of cat.fulcrum.bt.co.uk (== fulcrum, registered) cross-feeding with masalla.fulcrum.bt.co.uk (== masalla, not registered) they ``re-educated'' me to stamp the fqdn for the stuff that wasn't registered. In fact, I see no reason not to use fqdn in Path: for all machines entitled to one. Which is what I do now. ian
karl_kleinpaste@cis.ohio-state.edu (08/02/90)
steve@thelake.mn.org writes:
This leads to something I've been wondering about: What about third- and
greater-level domains, as in "bozo.foo.com"? Is there a need for them to
be registered?
Subdomains must be known within the context of their containing
domain. E.g., cis.ohio-state.edu is a proper domain name because the
nameservers for ohio-state.edu know about it. You can't ask the root
servers directly about cis.ohio-state.edu; they'll just tell you who's
responsible for ohio-state.edu. bletch.ohio-state.edu is an improper
domain name for the same reason, that the nameservers for
ohio-state.edu know of no such subdomain.
I have seen that mail to thelake.mn.org from Internet sites sometimes
fails with error messages indicating that there is no such domain. But I
thought that one of the big advantages of having a qualified, registered
domain was that multiple sites could be served with a single listing.
It shouldn't happen, but nameserver implementations aren't perfect,
either. I have a nameserver go bananas on me every few weeks.
Nothing major, really -- restart and it's fine. I just checked on
thelake.mn.org and got reasonable answers about your MX being
nic.mr.net.vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/04/90)
In article <Jul.31.10.33.49.1990.675@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: > > There are an absurdly large number of sites that use the news reply > path, and for me to bang on each one of them would be a waste of my > time. Much easier is it to just reroute their mail. By rerouting and by advertising links you do not let others use in circumstances that are not easily predicted, you are inconveniencing more than just those who insist on using Path: return addresses. Why "bang on" everyone? Why not hurt only those who use Path: to abuse your links? You could zap the Path: abusers by hacking your inews to stick a clinker like "somewhere!" in Path:'s as articles are relayed by your system. That would harm exactly those you say you want to "bang," and not the rest of the universe. It would take far less time than maintaining what sounds like an interesting set of heuristics. You could even take the existence of "!somewhere" in an path as permission to re-route. You would have an automatically generated "loose source route" flag. (Again, "somewhere" is a favorite dropping of rmail. Any real machine named "somewhere" and all of its neighbors will be in lots of trouble.) Is there any chance that the fact rerouting is an interesting technical challenge has convinced you that it is also acceptible in polite society? I know that is part of the temptation I wrestle with each time I see a bounce with a 200 character route. (I am helped by having spent years in grad. school learning that most technically interesting things are emphatically unacceptible in polite society.) What would you do with this route? ...!bionet!oracle!decwrl!sgi!apple!user Will you miss-reroute that one to user@apple.com? An article arriving for apple!user at sgi.sgi.com will be assumed to be for user@apple.sgi.com. If you think that is wrong, then I appologize. There are people in this vicinity that would complain if apple!user meant user@apple.com. Again, I did not choose the fruit name. Feel free to call me an idiot for still having not knowing which paths you will or will not destroy. I can guess what you mean by "neighbor checking," but even if I guess right, I have no confidence you will not find good reason to change your rules. I think there are many like me (tho that's what all idiots say). Vernon Schryver vjs@sgi.com
peter@ficc.ferranti.com (Peter da Silva) (08/04/90)
In article <1990Jul28.220425.20038@kth.se> perand@admin.kth.se (Per Andersson) writes: > Very true. There seems to be very many people in the US the thinks it > is a duty of the Internet to transport their mail... I see, in Europe, each site is considered a resource drain. In the U.S. each site is considered a potential resource. We pay for Email access to the internet, and would consider it rude were UUNET to tell us we couldn't mail to some site simply because they hadn't jumped through all the hoops yet. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/04/90)
In article <26B70994.578B@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > What's wrong with > > bionet!oracle!decwrl!sgi!apple.sgi.com!user > > ..? If 'sgi' knows about oni.sgi.com, why wouldn't it know about any > other machine in its domain? > > From the start of Usenet, UUCP host names have always supposed to be unique. > -- > Amanda Walker <amanda@intercon.com> > InterCon Systems Corporation Well, I've only been watching this stuff since 1982. That was long after it was well established; I know I am a newcomer. During that time, I had the distinct impression that UUCP host names only had to be LOCALLY unique. That is, UUCP does not work unless your immediate neighbors have unique names. It has been true since the start of the wonderful mapping project that all of the UUCP names in the UUCP maps must be globally unique. This is one of the least important of the several good reasons that apple.sgi.com will never appear in the UUCP maps, and so will never be reachable via a pathalias probe of "apple." Also among the unimportant reasons are the fact that even within the sgi.com domain, there hostnames that are not unique unless qualified. Among the important reasons is the fact that there are thousands of machines in the sgi.com domain. Please note that "apple.sgi.com" thinks its domain is "sgi.com". It and all other machines internal to sgi.com do not answer ping's from the Internet for reasons not relevant to this discussion. The related MX hassles are also irrelevant. What would you suggest machines in the sgi.com domain do when presented with the UUCP route "apple!user"? I see two alternatives, neither perfect, but one that will generate fewer local complaints. Please note that "apple.sgi.com" has existed for about three year. This has never caused routing problems because sgi (a.k.a sgi.com and sgi.sgi.com) has never had a direct UUCP link to apple.com, so that there has never existed valid pathalias output of the form "...!sgi!apple!...". It is also true that sgi has been routing (not rerouting) UUCP mail with pathalias for 3 or 4 years. Again, please refrain from even thinking of suggesting that people using machines within the sgi.com domain be forced to type FQDN's on internal mail. I would hope that most people would know to mail to "user@apple.sgi.com", and forget the whole ! business. That is not relevant to someone who is trying to route around a black hole, has used pathalias or the raw maps to get a route to user@apple.sgi.com that avoids the hole, and has typed ...!bionet!oracle!decwrl!sgi!apple!user. I have personally had occassion to do this sort of thing when BARRNet and CSNET links have been down or suspected to be down, and I did not want to or could not get someone out of bed. Vernon Schryver vjs@sgi.comj
peter@ficc.ferranti.com (Peter da Silva) (08/04/90)
One comment: Anything you put in a PATH line had better be globally unique. The usenet flooding algorithm depends on it. It looks like any article posted from apple.sgi.com will go unseen at apple.com. This is not to sanction rabid rerouting. The assumption that Path lines are the only source of hat you think is non-optimal routing is a poor one. Better to go ahead and stick a !somehere! in the path. That way when you see "somewhere!..." you know it's OK to reroute. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
lear@turbo.bio.net (Eliot) (08/05/90)
First of all, I have no problem with people using my links to get mail from here to there. I merely wish their mail to follow the path that the system administrators want it to use. In a polite society, guests of others should use their hosts' resources prudently. What I mean by neighbor checking, is that I will not reroute past a host that is not declared a neighbor of the previous host in the maps. [with the exception that I will shortcut to FQDNs]. So in response to your question, ``Where would you send mail for sgi!apple!user'', I would send it to apple!user@sgi.com. I certainly won't deny that getting rerouting right is an interesting technical challenge. And it is extremely easy to do the job poorly. -- Eliot Lear [lear@turbo.bio.net]
pmiach@uluru7.ecr.mu.oz (Paul Anthony MIACH) (08/05/90)
By passing mail mail to a 'cheaper' site are not you just passing the bill to another site? It seem that you'll be saving money by making someone else pay for it. Paul Miach. pmiach@ecr.mu.oz.au (I don't know my UUCP address, working on it...)
pcg@cs.aber.ac.uk (Piercarlo Grandi) (08/05/90)
In article <EMV.90Jul31131351@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: emv> If you use a domain name that doesn't belong to you, you deserve to emv> lose. That simple enough? cf *.austin.ibm.com. "bob" == Bob Sutterfield writes: bob> Right. And one case of a domain name that doesn't belong to you is bob> one that doesn't exist. Ohhh ENOUGH! How many times should I remind everybody that not every name that has dots in it is an absolute domain name in the Internet? It could be a name in the Janet, or BITNET, or DECnet Internets, or in some other Internet that uses RFC/BSD syntax but is not on the Internet. It could even be a totally different different sort of name that just happens to have one at-sign and some dots in it. Lear Eliot has written that he always checks for neighbour information, so that "sgi.com!apple!user" is not rewritten to "user@apple.com", but to "apple!user@sgi.com". Now, Eliot is a very competent (if misguided! not all neighbours are in the maps) mail administrator. Most others are not. So please, please, please please, never encourage rewriting addressed beyond the first hop. Even the "I pay the bill" argument holds; you only pay the bill up to the next hop, so reroute only to it. What about people that reply to "Paths:"? Well, bounce their mail. Acknowledged bouncing is far less dangerous than random rerouting. Having absolute names on the Internet is a wonderful thing, but among Internets whose internal structure is unknown to each other you *must* use _relative_ naming, which is not source routing, but somehow implies it. Asking UUCP sites to register in the Internet is asking that the problem be not solved, but it be made disappear, by putting everybody in the Internet scheme of things. This will *never* *ever* happen. There is not just the UUCP Internet, there are also the BITNET, X.400, Janet, DECnet, and many other Internets. It will be *impossible* to have complete information on all Internets from any Internet. It would be nice if everybody had DARPA/NSF Internet absolute names, but since this is not going to happen, we should study ways to address other Internet's people reliably, formalizing some syntax for specifying _relative_ (to a naming or routing gateway) names, without using the unreliable way of using the local part of an RFC 822 address for it, which causes all sorts of problems with quoting characters that are meaningful for both Internets (hence the % hack). Some horrid examples can be concocted of dual use X.400/RFC822 addresses, for example. Just use dots and on at-sign in any component of an X.400 address, e.g. C=banana.republic,ADMD=national.post.office, and an at-sign somewhere else, e.g. ORG=SomeOrg@CapitalCity for an address like /ORG=SomeOrg@CapitalCity /ADMD=national.post.office/C=banana.republic which parser for non strict RFC822 would decompose as /ORG=SomeOrg @ CapitalCity/ADMD=national . post . office/C=banana . republic I am fairly sure that human nature being what it is, we will soon start seeing such addresses around fairly soon (just notice that @ in ASCII comes earlier in sorting order than letters...) Please, Please, PLEASE, PLEEEEAAASEEEE, do not do early name resolution, even on addresses that look like RFC822 addresses (they may not be), and do not do early route resolution, even when you are damned sure that the tail of the route contains RFC822 addresses for Internet hosts (the Internet may not be the cheapest/quickest route). Remember: you only know about directly connected, in a naming or routing sense, neighbours (which may be the entire DARPA Internet), and you only pay for transmission to them. You can do what you want to mail originating from your site (your users will be mad at you, and you are accountable to them), but only name-resolve/transport-route the first component in the name/route of in transit mail. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
lear@turbo.bio.net (Eliot) (08/06/90)
Paul Anthony MIACH writes: > By passing mail mail to a 'cheaper' site are not you just passing the > bill to another site? It seem that you'll be saving money by making someone > else pay for it. That may be true, but I am sending it to a site that declared itself to be more interested in passing the mail than the sender's choice (if the choices do, in fact, differ). What's more, there will be less phone calls altogether. Consider a path, bionet!oracle!decwrl!sgi!adobe!apple!user. It would get shrunk to apple!user. There I've just saved at least four phone calls. Finally, if a particularly popular site doesn't the cost of phone calls it is making, the site administrator need merely add weight to certain links, and those links will get less mail sent through. -- Eliot Lear [lear@turbo.bio.net]
lear@turbo.bio.net (Eliot) (08/06/90)
Peter, you pay a mere fraction of the cost of delivery for mail sent through UUNET. And even though you pay for a service, UUNET has every right to muck with your headers (that's how this conversation got started, remember?). So long as they provide reliable service, you really have no basis for complaint. -- Eliot Lear [lear@turbo.bio.net]
lear@turbo.bio.net (Eliot) (08/06/90)
> It looks like any article posted from apple.sgi.com will go unseen at > apple.com. Nor will it get to apple's downstream (single feed) sites. -- Eliot Lear [lear@turbo.bio.net]
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/06/90)
> > It looks like any article posted from apple.sgi.com will go unseen at > > apple.com. > > Nor will it get to apple's downstream (single feed) sites. Several people have said that news posted from apple.sgi.com will not be propagated, and that apple.sgi.com is an invalid name because apple is not unique. The first statement probably not true. What matters is what would actually appear in the Path: line in articles posted from apple.sgi.com. It is likely that it will work fine, regardless of which of the several available combinations of news archive machines, versions of inews, protocols (direct, NNTP, or home-grown news/mail), and inews versions (B or C) would actually be used by someone posting from apple.sgi.com. The second statement is true only to the extent that people or computers use the unqualified "apple" in contexts where it could be confused with apple.com. However, both are irrelevant. Please excuse me for pointing out that this discussion concerns rewriting headers in electronic mail using UUCP as a lowest level transport mechanism. It is taking place in a news group named "comp.mail.uucp." This discussion has nothing to do with "USENET" or "net news" except that some common tools associated with net news can be used to generate email messages, use addresses or routes obtained from news articles, and these computer generated routes inflame many people into committing what others call rudeness. Netnews is not mail via UUCP. Mail has nothing to do with the news flooding algorithm. ---- I must admit that the rewriting Mr. Lear's describes seems unlikely to cause much harm. The only harm obvious to me would be to those of us trying to figure out what is broken. For example, I have often sent mail messages to myself through distant and ciruitous routes. I have been inconvenienced by systems that presumed to know more about what I wanted than I did. Still, I oppose Mr. Lear's rerouting first because it would makes it harder for me to debug mail routes, and second because I doubt that most people will do it as well as he. Most people will do no better the <explitive deleted> that the unnamed wright at AT&T committed in /bin/mail. (Stock SVR3.2 /bin/mail presumes to reroute, based purely on text comparisons. For that matter, 4.[23] BSD Mail likes to trash complicated and apparently redundant routes.) Rerouting violates my esthetic of keeping things stupidly simple more than silly routes violate my dislike for giving Mother Bell money. Vernon Schryver vjs@sgi.com
david@twg.com (David S. Herron) (08/06/90)
In article <3275.26b54aab@mccall.com> tp@mccall.com writes: >In article <Jul.30.17.57.18.1990.9079@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: >> bionet!uwm.edu!wuarchive!uunet!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!tp > >Are there still news systems that use the Path: line for replies? My experience back when I ran ms.uky.edu (a.k.a. `ukma') was that we saw lots and lots of mail using Path: lines attempting to pass through us. That was over a year ago ... >And conversely if a site is not in the maps, I take it the chance of error >is 100%? It certainly is if an unmapped site has the same name as one that >is in the maps. (I really would be curious as to what checks can be made to >verify a path.) > >Once upon a time, my email address was ><tp%mccall.claremont.edu@cunyvm.cuny.edu>. Expressed as a bang-path, this >would be "...!cunyvm.cuny.edu!mccall.claremont.edu!tp". How would your >system route this? As "bionet!mccall.claremont.edu!tp"? If so, and if you >aren't on bitnet, you just lost my mail. Neither "mccall.claremont.edu" nor >"claremont.edu" was at that time a registered domain on the internet. They >only existed on bitnet. Terry, you were oh so very very very very very much in the wrong to do that. This is *exactly* as bad as advertising mail addresses of user@host.uucp where `host' isn't registered in the UUCP Mapping Project maps. They are both the same violation -- claiming to be in some domain (naming authority) when you really aren't. One of the duties of a postmaster is to advertise connectivity to their systems to all the networks to which their systems connect. In both cases you're claiming the connectivity (that is, by making your headers read `host.dom.ain.edu' or `host.uucp', you're claiming to be in the naming authority for either `.edu' or `.uucp') but *NOT* *ADVERTISING* the connectivity. -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
amanda@mermaid.intercon.com (Amanda Walker) (08/06/90)
In article <66101@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > Again, please refrain from even thinking of suggesting that people > using machines within the sgi.com domain be forced to type FQDN's on > internal mail. I agree that they shouldn't have to, but I don't think it unreasonable if their machines append their domain to any unqualified hostnames before the messages leave their machine... Karl's machines (well, OSU CIS's machines :-)) do this, and it works quite well unless someone gives their *unqualified* address to a colleague across the country and their mail ends up in Finland... This, however, is pilot error. "Be liberal in what you accept, and conservative in what you generate." -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
tp@mccall.com (08/06/90)
Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 43 In article <7700@gollum.twg.com>, david@twg.com (David S. Herron) writes: > In article <3275.26b54aab@mccall.com> tp@mccall.com writes: >>Once upon a time, ... > Terry, you were oh so very very very very very much in the wrong to do that. Well, someone was. I got my domain from the administrator of claremont.edu, so I didn't do it. He got that from the folks that run Bitnet, so he didn't do it. I guess they did. I didn't know about the problem for a while, and I'm not sure if the administrator of claremont.edu did either. My point is, if nobody rerouted the message, it would get to me. Why break a valid path? As it turns out, Eliot would get it right, but almost nobody else would. My conclusion: if your rerouter isn't as smart as Eliot Lear's, DON'T reroute, except to the first host in the path (i.e. next hop). You are always free to do that, of course, and I think few people would complain about it. > This is *exactly* as bad as advertising mail addresses of user@host.uucp > where `host' isn't registered in the UUCP Mapping Project maps. > > They are both the same violation -- claiming to be in some domain (naming > authority) when you really aren't. I know. So bounce my mail, if you must. A rerouter would probably send it off to a black hole. But, why break it? As someone else pointed out, a path to a gateway could have ANYTHING on the other side. Why gratuitously break addresses that happen to be routed to weird networks? I'd understand if there were a reason to do it. There isn't. In this discussion, I've been convinced that rerouting is necessary for big sites that handle lots of news and don't want to send mail over their news links (and some other situations). I've also been convinced that it can be done safely (Eliot Lear is an existance proof). I know from experience that almost nobody actually does it safely. Maybe Eliot can share his rerouting software with those who feel they must reroute. Without neighbor checking rerouting to anything other than the first site in the path DOES NOT WORK RELIABLY and SHOULD NOT BE DONE. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
david@twg.com (David S. Herron) (08/07/90)
In article <65793@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <Jul.30.17.57.18.1990.9079@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: >As has been said many times, not all machines are permitted in the maps. >The machine "apple.sgi.com" exists, and answers to "apple" as well as >"apple.sgi.com". For good reasons I am sure you know, that machine will >never be permitted in maps by the N.Calif. map coordinators. If I had >anything to say about it, the machine would not be named "apple.sgi.com", >or even "apple.corp.sgi.com" simply because it would be too similar to the >other machine named "apple". However, I don't have any say, and even if I >did, the arguement that Domains Save All would still be valid. Exactly.. you can have your domain name and use it too. Or something like that.. One of the things you have to do is make sure that stuff you're advertising in e-mail headers & Path: lines are `correct'. In your case, since your apple isn't the other apple, then you should make sure your apple claims to be it's FQDN (Fully Qualified Domain Name) (at least) in headers & Path: lines. Anything less and you WILL run into the confusion you suggest. >(I suppose it's too much to hope that no one will suggest that the users of >machines on the same ethernet as apple.sgi.com be forced to type >"user@apple.sgi.com" instead of "user@apple".) No.. The current BIND resolver (for instance) allows defaulting of unqualified domain names to live within a list of possible hierarchies. By default the hierarchies are super-sets of your FQDN, and is user-settable. MMDF automagically allows that same defaulting and I assume that sendmail.cf's can be configured to do the same defaulting. >If you reduce the UUCP path > "bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user" >into > "bionet!apple!user" or "user@apple.com" >then you have just gratuitously bounced someone's mail. So when putting that UUCP path out there make ABSOLUTELY DAMN sure it doesn't say "apple", but the appropriate FQDN. On the other hand.. you're right.. people shouldn't be looking beyond the first site in the list because they really don't have the right to interpret the rest of the path. IF you put FQDN's into your path then there would be no chance for confusion. Everybody would know it was your apple and, if they were Rabidly Rerouting, would act accordingly. If they were Rationally Rerouting (my definition of Rational == not looking beyond the first hop) they would still work since you put out `sgi'. If they route on the first FQDN, again, it will work since you'd be putting out two FQDN's.. (given your example) -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
peter@ficc.ferranti.com (Peter da Silva) (08/07/90)
In article <Aug.4.10.58.40.1990.3199@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: > What I mean by neighbor checking, is that I will not reroute past a > host that is not declared a neighbor of the previous host in the maps. That sounds like *exactly* the right thing to do. Could you post the code to do that? I'd find it very very useful... > [with the exception that I will shortcut to FQDNs]. Not so good. Now you're spending other people's money by second-guessing the maps. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (08/07/90)
In article <Aug.5.10.38.44.1990.4516@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: > Peter, you pay a mere fraction of the cost of delivery for mail sent > through UUNET. I pay as great a fraction as anyone else, on a per message basis. Otherwise UUNET would be losing money. > So long as they provide reliable service, you > really have no basis for complaint. Ah, but I wasn't complaining about UUNET. I was noting that postmasters at two separate locations (osu and uunet) were both showing with impeccable logic that they should munge the headers in exactly the opposite way to each other. I don't know which one is right, or if either are. I *am* pointing out a paradox. One or the other is doing the wrong thing. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
steve@qe2.paloalto.ibm.com (Steve DeJarnett) (08/07/90)
In article <7704@gollum.twg.com> david@twg.com (David S. Herron) writes: >In article <65793@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >>In article <Jul.30.17.57.18.1990.9079@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: >>If you reduce the UUCP path >> "bionet!oracle!decwrl!sgi!oni.sgi.com!apple!user" >>into >> "bionet!apple!user" or "user@apple.com" >>then you have just gratuitously bounced someone's mail. > >So when putting that UUCP path out there make ABSOLUTELY DAMN sure >it doesn't say "apple", but the appropriate FQDN. Of course, then we get to the following problem. apple.sgi.com is a FQDN. Great. Now the Rabid Rerouters pop up, and say "great, a FQDN very near the end of the path (actually, at the end). Let's short-circuit to that." BOING! If apple.sgi.com isn't Internet-connected, and doesn't have anyone MX-ing for it, the mail bounces. Now, this is a worst-case analogy, but it does happen. I used to be a proponent of Rabid Rerouting (when I was the one modifying the sendmail.cf files on an Internet-connected machine). Now that I sit with an address that looks like it's Internet-connected, but is only connected to a corporate internal network (soon to be rectified with at least an MX record, but that's beside the point), I see things in a different light. I would love for Rabid Rerouting to work. However, until every workstation is IP-reachable (or at least has a host MX-ing for it), this isn't going to work (IMHO). >On the other hand.. you're right.. people shouldn't be looking >beyond the first site in the list because they really don't have >the right to interpret the rest of the path. And if they don't, then SGI's apple will never be seen by anyone who doesn't know how to deal with it, qe2.paloalto.ibm.com will never be seen by anyone who doesn't know how to deal with it, and the world will be a better place to live (well, maybe 2 out of 3 are true :-). >IF you put FQDN's into your path then there would be no chance >for confusion. Everybody would know it was your apple and, if >they were Rabidly Rerouting, would act accordingly. If they >were Rationally Rerouting (my definition of Rational == not looking >beyond the first hop) they would still work since you put out `sgi'. >If they route on the first FQDN, again, it will work since you'd >be putting out two FQDN's.. (given your example) Rational Rerouting should work. Rabid (at least for qe2's case) would fail (for the time being). Partially our fault, but partially yours also. Ain't this fun... ><- David Herron, an MMDF weenie, <david@twg.com> Steve DeJarnett Internet: ibmsupt!steve@uunet.uu.net IBM AWD Palo Alto UUCP: uunet!ibmsupt!steve (415) 855-3510 VNET: dejarnet at ausvmq These opinions are my own. I doubt IBM wants them.......
chip@tct.uucp (Chip Salzenberg) (08/07/90)
According to lear@turbo.bio.net (Eliot): >You might also argue that the service is incompetant, but such a >statement requires backing. I would argue that my rabid rerouter is >far more compentant than the users who send mail through me. No rerouter can be more competent than I am at deciding which sites I wish to *avoid*. For example: I avoid apple because they mung headers. Starting today I avoid texbell, because it's going away. I avoid rutgers and Eliot's site because they reroute rabidly. [*] Rabid rerouters defeat all my careful attempts at black hole avoidance. In this respect they are EVIL and RUDE. [*] Don't argue that because I try to avoid RR sites, the RR issue doesn't concern me. I'll never know where all of them are. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
amanda@mermaid.intercon.com (Amanda Walker) (08/08/90)
In article <XR05SB7@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > I was noting that postmasters at > two separate locations (osu and uunet) were both showing with impeccable > logic that they should munge the headers in exactly the opposite way to > each other. There is a difference, though. Most of uunet's connections are to machines whose mailers only understand UUCP addresses. Most of osu's connections (if not all) are to machines whose mailers understand RFC 822 addresses. In their own contexts, each strategy makes sense, and serves to help mail get through. If you tell uunet "hey, we can grok RFC 822," they'll start rewriting things in pretty much the same way OSU does... The major difference is that uunet doesn't require you to run a modern mailer in order to be a customer :-). -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
ggw@wolves.uucp (Gregory G. Woodbury) (08/09/90)
In <1990Aug6.230109.4220@ibmpa> steve@qe2.paloalto.ibm.com (Steve DeJarnett) writes: > > Of course, then we get to the following problem. apple.sgi.com is a >FQDN. Great. Now the Rabid Rerouters pop up, and say "great, a FQDN very near >the end of the path (actually, at the end). Let's short-circuit to that." >BOING! If apple.sgi.com isn't Internet-connected, and doesn't have anyone >MX-ing for it, the mail bounces. Wrong, if it isn't directly connected, and does not have a valid MX record at the appropriate hosts, IT IS NOT A FQDN! The DNS is a fully controlled system, the fact that some people abuse it and use domains without insuring MX'ing is in place, that is THEIR error and problem. Personally, I think a machine handling mail has the right to reroute IF it can GUARANTEE proper delivery. If there is a valid FQDN further to the right, call the resolver and find its mailbox that is directly connected and drop it there for handling. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>
mju@mudos.ann-arbor.mi.us (Marc Unangst) (08/09/90)
amanda@mermaid.intercon.com (Amanda Walker) writes: > There is a difference, though. Most of uunet's connections are to machines > whose mailers only understand UUCP addresses. Most of osu's connections > (if not all) are to machines whose mailers understand RFC 822 addresses. > In their own contexts, each strategy makes sense, and serves to help mail > get through. Let's make something clear right off the bat. The From:, To:, Date:, etc. headers are all RFC822 headers. Therefore, if you implement them, it can be assumed that you also impliment the other parts of RFC822, such as "@"-style addressing. If you are running a UUCP system without a mailer that implements RFC822, then you have no business trying to interpret the From: header, or the To: header, or any other RFC822 header. Period. They should be considered part of the message body. The only thing other than the envelope you're allowed to touch is the From_ line. IF YOUR MAILER MUCKS WITH RFC822 HEADERS WHEN IT DOESN'T UNDERSTAND RFC822, YOUR MAILER IS BROKEN. Period. And you should expect mail to bounce. Period. If the next site down the line doesn't understand RFC822, then rewrite the envelope address in bang-path form. And make sure you muck the From_ line correctly. But never, ever muck with an RFC822 header to make the contents non-RFC822-conformant. Again, if your site doesn't understand "@"-style addresses but insists on doing things with the From: or To: headers, then get a different mailer. But don't complain when other people refuse to break more things so you can continue to run a broken mailer. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | Angular momentum makes the world go 'round. ...!umich!leebai!mudos!mju |
les@chinet.chi.il.us (Leslie Mikesell) (08/10/90)
In article <66099@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Why "bang on" everyone? Why not hurt only those who use Path: to abuse >your links? >You could zap the Path: abusers by hacking your inews to stick a clinker >like "somewhere!" in Path:'s as articles are relayed by your system. >That would harm exactly those you say you want to "bang," and not the >rest of the universe. It would take far less time than maintaining >what sounds like an interesting set of heuristics. >You could even take the existence of "!somewhere" in an path as >permission to re-route. You would have an automatically generated >"loose source route" flag. This is a great idea! Probably 90% of the mail that everyone is complaining about is generated from news Path: lines or replies to those messages. The crux of the problem is that there is no way to distinguish mail where the user would prefer optimal re-rerouting (as long as it works) from mail where the user really wants the specified route. Some time ago I suggested that sites that wanted to optimize mail routes should just re-write the news Path: line and eliminate everything else but themselves and the sending site. Of course I was informed that such a change would result in the messages being propagated back to the excised sites. However, there should be no such problem from agreeing on a non-existing site name to be used as a "token". Re-routing sites would just move the token to the front of the Path: line before adding their own name or insert it if no one else has. Then, when a mailer sees this token as the next-hop, it should re-route to the right-most destination that it can identify. No one could question the ethics of this form of re-routing, and a few dozen sites running this way could have a major impact on mail traffic (as opposed to waiting for every leaf node to either start running routing software or identify the most convienent nearby site willing to act as a smart-host). Smail 2.5 should automatically re-route when the next hop doesn't exist. The other smart mailers can probably be coaxed to do so as well. Les Mikesell les@chinet.chi.il.us
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/10/90)
> Wrong, if it isn't directly connected, and does not have a > valid MX record at the appropriate hosts, IT IS NOT A FQDN! The DNS is > a fully controlled system, the fact that some people abuse it and use > domains without insuring MX'ing is in place, that is THEIR error and > problem. Consider "foo.bar.bozo". Is it a FQDN? I bet you'll say no because "bozo" is not in 1066 or where ever the current list of top-levels is kept. Now consider "foo.uunet.net". Is it a domain name? I bet you'll say yes, since you can productively ask the root servers about "uunet.net" Finally take "...!trash!foo.bar.bozo!user" and "...!trash!foo.uunet.net!user" Are either "foo.bar.bozo" or "foo.uunet.net" FQDNs in that context? It is sadly likely that many people will presume to answer for the owners of trash. What if trash is a novel Bitnet/CSNET/JANET/EBCDIC device that considers "." an ordinary character? (Please do not instruct me on any of those accronyms. I already know far more about them than I want to know.) There is no Law of UUCP carved in stone by Chesson that makes "." an illegal hostname or username character in a UUCP route. There is no rule saying strings separated by "." in a UUCP host name must be known by nic.ddn.mil, unlike that other universe, which would be discussed not here in comp.mail.uucp but in comp.mail.sendmail or comp.protocols.tcp-ip.domain. UUCP (tm) is UUCP, different from the Internet (tm). Then there are Bitnet, Fido, X.400, and other things not dreamed of in our philosophies. This debate is about whether any person can reliably know everything others know, want, and do. Some people believe the answer is yes. The rest of us are amazed. Enough. Vernon Schryver vjs@sgi.com
sean@utoday.UUCP (Sean Fulton) (08/10/90)
In article <Aug.5.10.38.44.1990.4516@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: >Peter, you pay a mere fraction of the cost of delivery for mail sent >through UUNET. And even though you pay for a service, UUNET has every >right to muck with your headers (that's how this conversation got >started, remember?). So long as they provide reliable service, you >really have no basis for complaint. That would be like complaining which streets the postman drove down with your letter, right? -- Sean Fulton uunet!utoday!sean Unix Today! (516) 562-5430 **To subscribe, mail your request to: uunet!utoday!circ**
bob@MorningStar.Com (Bob Sutterfield) (08/10/90)
In article <66582@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: In article <1990Aug8.214750.1614@wolves.uucp> ggw@wolves.uucp (Gregory G. Woodbury) writes: Wrong, if it isn't directly connected, and does not have a valid MX record at the appropriate hosts, IT IS NOT A FQDN! (Amen, brother!) Consider "foo.bar.bozo". Is it a FQDN? I bet you'll say no because "bozo" is not in 1066 or where ever the current list of top-levels is kept. The list is kept in the various root servers, and since .bozo isn't a top-level domain, foo.bar.bozo isn't a FQDN. You're right - score one point. Now consider "foo.uunet.net". Is it a domain name? I bet you'll say yes, since you can productively ask the root servers about "uunet.net" (I'll assume you meant to ask about "foo.uu.net" and "uu.net".) No, foo.uu.net isn't a FQDN because there's no *.uu.net. uunet.uu.net stopped providing that transition service late this spring because too many people were abusing it by assuming that they now had a name that they could use permanently rather than registering their own. Sorry - you lose one point. Finally take "...!trash!foo.bar.bozo!user" and "...!trash!foo.uunet.net!user" Are either "foo.bar.bozo" or "foo.uunet.net" FQDNs in that context? It is sadly likely that many people will presume to answer for the owners of trash. What if trash is a novel Bitnet/CSNET/JANET/EBCDIC device that considers "." an ordinary character? Then the "." shouldn't appear in a context where it is taken for a FQDN. RFC1036 (section 2.1.6, paragraph two, last sentence) says that "letters, digits, periods and hyphens are considered part of host names." If traffic moves between addressing schemes, it's the responsibility of the gateway to ensure that the traffic conformant with each set of standards - whichever side the traffic happens to be on at the moment. If some addressing scheme on FooNet considers dots and dashes to be ordinary characters in hostnames, the gateway must arrive at some functional, bidirectional mapping before introducing such traffic into the realm of the Domain Name System. There is no Law of UUCP carved in stone by Chesson that makes "." an illegal hostname or username character in a UUCP route. There is no rule saying strings separated by "." in a UUCP host name must be known by nic.ddn.mil... The Network Information Center is the authority over the domain name system. The only naming authority that exists to arbitrate between UUCP sites is the UUCP Mapping Project, which registers names to (among other things) guarantee uniqueness. They won't accept a hostname containing dots unless it's a FQDN because of the immense confusion that would result. UUCP (tm) is UUCP, different from the Internet (tm). Then there are Bitnet, Fido, X.400, and other things not dreamed of in our philosophies. And when the twain meet, they must learn to speak each others' languages.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/11/90)
In article <BOB.90Aug10125912@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes: > ... The only naming authority that exists to arbitrate between > UUCP sites is the UUCP Mapping Project, which registers names to > (among other things) guarantee uniqueness. They won't accept a > hostname containing dots unless it's a FQDN because of the immense > confusion that would result. The word "authority" is rather strong with respect to UUCP. UUCP is more of an anarchy than USENET every imagined. The machines connected via UUCP must include anything that a chain of !'s can reach, including lab prototypes suffering initial UNIX ports. At best, the Mapping Project is authoritative about the validity of the left-most hostname of a UUCP route, when such routes are examined by hundreds of thousands of machines which have agreed to accept the Project's authority. Everyone agrees that the UUCP Mapping Project is the authority for the second host name in "decwrl!sgi.com!vjs" but "the NIC" is. Similarly, the UUCP Mapping Project is not the authority for anything after the first ! in "psuvax1!bar.bitnet!user" or "trash!foo.bar.com!user". The Mapping Project is great, but it is no more authorative for all UUCP routes than the U.S. Postal Services is the authority for all mail addresses, even in the U.S. You can make up any sort of "suite," "mail stop," or other "local" convention you wish, provided only that the USPS can understand the street address, city, state, and zip-code. I believe anything to the right of the first "!" in a UUCP route must be considered a "local part" analogous to anything left of the "@" in a simple, non-SR RFC-822 address. The fact that ...!trash!bozo.foo.bar!user looks like it contains a FQDN is a illusion. It is just as wrong to complain that "bozo.foo.bar" is a bad domainname in that UUCP context as it is to complain that "user%bozo.foo.bar@trash.com" or "v.schryver@SGI.COM" contain invalid FQDNs in their local parts. Such complaints presumes to know what is on the otherside of the "trash", "trash.com", or "sgi.com" gateways or mail handlers. RFC-822 is wonderful. RFC-822 is perfect. Nothing could be better than RFC-822. RFC-822 is not the entire universe. RFC-822 is not UUCP. UUCP is not RFC-822. Vernon Schryver vjs@sgi.com
ggw@wolves.uucp (Gregory G. Woodbury) (08/11/90)
Vernon Schryver writes: > >I wrote: >> Wrong, if it isn't directly connected, and does not have a >> valid MX record at the appropriate hosts, IT IS NOT A FQDN! The DNS is >> a fully controlled system, the fact that some people abuse it and use >> domains without insuring MX'ing is in place, that is THEIR error and >> problem. > > >Consider "foo.bar.bozo". Is it a FQDN? I bet you'll say no because "bozo" >is not in 1066 or where ever the current list of top-levels is kept. I don't particularly care if it is "officially" a FQDN in terms of properly registered or whatever else particular quibbling you want to use. If I can submit a name into BIND or other DNS methodology and get an address that is going to provide delivery of the item, I will use that address. >Now consider "foo.uunet.net". Is it a domain name? I bet you'll say yes, >since you can productively ask the root servers about "uunet.net" Again, if ANY server can give me a valid address for the delivery of the item, it is a FQDN and can be used. >Finally take "...!trash!foo.bar.bozo!user" and "...!trash!foo.uunet.net!user" >Are either "foo.bar.bozo" or "foo.uunet.net" FQDNs in that context? It is >sadly likely that many people will presume to answer for the owners of trash. >What if trash is a novel Bitnet/CSNET/JANET/EBCDIC device that considers >"." an ordinary character? (Please do not instruct me on any of those >accronyms. I already know far more about them than I want to know.) Too true! > >There is no Law of UUCP carved in stone by Chesson that makes "." an >illegal hostname or username character in a UUCP route. There is no rule >saying strings separated by "." in a UUCP host name must be known by >nic.ddn.mil, unlike that other universe, which would be discussed not here >in comp.mail.uucp but in comp.mail.sendmail or comp.protocols.tcp-ip.domain. Actually, the rules for uucp hostnames are fairly limited. The original 6 character rule has been relaxed a little, but the conventions do prohibit '.' and other special characters from appearing in the name. >UUCP (tm) is UUCP, different from the Internet (tm). Then there are Bitnet, >Fido, X.400, and other things not dreamed of in our philosophies. > >This debate is about whether any person can reliably know everything others >know, want, and do. Some people believe the answer is yes. >The rest of us are amazed. I am simply quibbling over whether something is a FQDN. In general, I do not want the paths that I generate for pure uucp routing to be munged. In certain cases I may be debugging a route remotely and don't want it re-routed. In such cases the ! path should consist only of the simple hostnames. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>
mju@mudos.ann-arbor.mi.us (Marc Unangst) (08/11/90)
sean@utoday.UUCP (Sean Fulton) writes: > In article <Aug.5.10.38.44.1990.4516@turbo.bio.net> lear@turbo.bio.net (Eliot > >started, remember?). So long as they provide reliable service, you > >really have no basis for complaint. > > That would be like complaining which streets the postman drove down > with your letter, right? Ah, finally, a good analogy. Let's say that your postman usually takes Main to Fourth, turns left, takes Fourth to Elm, and then turns right to get to your house, which is 822 Elm St. This path could be expressed as "post-office!main!fourth!elm!822.elm!Sean-Fulton". Now, let's say that today, I know that they're ripping up Elm between Fourth and your house, so I want the postman to go around the construction by taking Main to Fifth, taking Fifth to Elm, and then turning left. So I manually route the mail "post-office!main!fifth! elm!822.elm!Sean-Fulton". If the post office is not a DARR, my mail will get where it's going. If the post office *is* a DARR, then they will reroute the mail to take Fourth, and it will bouce because the postman can't turn right onto Elm from Fourth; the street is all torn up. In this case, the DARR breaks a working path when it reroutes the mail. Sure, driving all the way to Fifth and then driving back parallel to Main on Elm may not be the optimal route, but in this case, it's the only way the mail will get there. A good idea would be to include a "Reroute:" header in mail. Setting it to "Yes" would be the default value and allow rerouting to the next host in the path, but not past there. Setting it to "No" would mean that the host is to follow the path exactly as you have it laid down; if the host isn't directly connected to the next hop, the mail bounces. Setting it to "Rabid" would let the host do what it pleases with the path, including short-circuiting to the last host in the path, or the last FQDN, or whatever. (Perhaps "Rabid" should be the default instead of "Yes".) -- Marc Unangst | mju@mudos.ann-arbor.mi.us | Angular momentum makes the world go 'round. ...!umich!leebai!mudos!mju |
pcg@cs.aber.ac.uk (Piercarlo Grandi) (08/13/90)
On 10 Aug 90 16:59:19 GMT, bob@MorningStar.Com (Bob Sutterfield) said:
bob> In article <66582@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon
bob> Schryver) writes:
vjs> Finally take "...!trash!foo.bar.bozo!user" and
vjs> "...!trash!foo.uunet.net!user" Are either "foo.bar.bozo" or
vjs> "foo.uunet.net" FQDNs in that context? It is sadly likely that
vjs> many people will presume to answer for the owners of trash. What
vjs> if trash is a novel Bitnet/CSNET/JANET/EBCDIC device that considers
vjs> "." an ordinary character?
bob> If traffic moves between addressing schemes, it's the responsibility
bob> of the gateway to ensure that the traffic conformant with each set of
bob> standards - whichever side the traffic happens to be on at the moment.
Not, it is not. It may be *impossible* to translate between the two
schemes; for example between UUCP and Internet schemes. UUCP uses non
centrally registered relative addresses, and Internet centrally
registered absolute ones, and they cannot in general be translated one
to another. The drive to get UUCP names sanitized is really a drive to
change the nature of the UUCP addressing scheme so that it becomes
semantically equivalent to the Internet one.
Whether this is desirable or not is irrelevant when confronted with the
idea that it cannot be done for all UUCP sites, not to mention for all
the non UUCP addressing schemes. Even the argument "tough, we'll ignore
anything tht does not adapt to the rules of the Internet because we are
bigger" fails, as there are more "important" networks than the Internet
already.
vjs> UUCP (tm) is UUCP, different from the Internet (tm). Then there
vjs> are Bitnet, Fido, X.400, and other things not dreamed of in our
vjs> philosophies.
bob> And when the twain meet, they must learn to speak each others'
bob> languages.
Again, this is an *impossible* requirement. It assumes that all naming
schemes are equivalent bar the syntax, and that gateways know
*everything* about the addressing schemes they interface.
I am a bit sickened by the tunnel vision of Internet centered people.
Many do not know that name resolution is not the same as routing;
naming schemes are not equivalent; when two gateways interface, neither
should know about how the other does its business, beyond using an
agreed interchange format.
Given that our problem is how to live with multiple naming schemes, It
would be helpful if there were *in each scheme* some way to escape from
it. This is the solution to the apple.com vs. sgi.apple.com problems.
Currently we have the unsatisfactory use of the local part of an RFC822
address for this use, and the resulting % hack to quote @ in it. There
are other possible solutions, something like encapsulation, e.g. either
in the header or in the body of the message. I'd prefer it in the
envelope part of the header, incidentally, for the RFC side mailers.
I mean, something like 'To:' addressing the gateway, and
'Then-To:' the address beyond that gateway.
Now, a (disingenuous) question for all the smart Internet people out
there: which RFC defines a way to pass mail thru a foreign address
gateway and express addresses beyond that gateway? Which is the RFC
sanctioned way to qualify an address with the gateway that can
understand it?
Note: in the UUCP world, ! serves three purposes: for routing
(a!b!c says "forward to a, then b, then c"), for name definition
(x!y!z says "host z is a neighbour of y, a neighbour of x"), and
as a naming resolution operator (g!h!i says "g knows how to
interpret the meaning of 'h!i'"). It is so bad that most people
ignore this, and the obvious advantages (except that it is maybe
a bit too much overloaded, even if unambiguosly).
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uklear@turbo.bio.net (Eliot) (08/14/90)
Piercarlo Grandi writes: > Now, a (disingenuous) question for all the smart Internet people out > there: which RFC defines a way to pass mail thru a foreign address > gateway and express addresses beyond that gateway? Which is the RFC > sanctioned way to qualify an address with the gateway that can > understand it? Good Question! The key word you used was FOREIGN. The most appropriate definition I could find in my el cheapo American Heritage Second College Edition was the legal one: "subject to the jurisdiction of another political unit." If ever, the RFCs rarely refer to that which is outside the realm of TCP/IP. Of course they give great lattitude to that which may appear in the LOCAL part of an address. -- Eliot Lear [lear@turbo.bio.net]
dan@sci.ccny.cuny.edu (Dan Schlitt) (08/22/90)
In article <26BCD60E.1D9@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >In article <66101@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) >writes: >> Again, please refrain from even thinking of suggesting that people >> using machines within the sgi.com domain be forced to type FQDN's on >> internal mail. >I agree that they shouldn't have to, but I don't think it unreasonable if >their machines append their domain to any unqualified hostnames before the >messages leave their machine... YES, YES, YES!!!! Please do that!!! My mailbox is filled with bounced uucp mail from sites that don't do that. The mail is bounced by the AT&T host named physics (old and in the maps for ages). It seems that there are lots of machines out there named physics or even rainbow.physics or wrath.physics or .... and their misconfigured software sends that mail off on its way via uucp to good old AT&Ts physics and it get bounced back to me. (The headers are certainly going to have only unreplyable things in them.) The only solution for this problem is for the sites to use RFQDNs internally. >Karl's machines (well, OSU CIS's machines :-)) do this, and it works quite >well unless someone gives their *unqualified* address to a colleague across >the country and their mail ends up in Finland... This, however, is pilot >error. As has been pointed out many times, the use of short names is a user agent problem. If you want to hide the domain stuff from the user then fix the user agent. The MTA should use the FQDN. PLEASE. > >"Be liberal in what you accept, and conservative in what you generate." -- Dan Schlitt Manager, Science Division Computer Facility dan@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)650-7885