reid@decwrl.dec.com (Brian Reid) (07/16/88)
In article <121@carpet.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >Then I ask, humbly, why I can not get mail through decwrl to the Colorado >Springs Digital office, further, why I can not reach a non-Digital site that >is listed in decwrl's map? Please try, from decwrl, pete@tsc.DEC.COM, I am >quite sure that it's among the 32,000 nodes on the Digital network. If it >works, please explain how to address from outside the Digital network and I'll >shut up. I'm not trying to be a nuisance, but I am trying to get clear >on this. If it's "mailer bugs", so be it. decwrl is at the confluence of a large number of mail networks. As a participant in the uucp network, it passes all relay uucp mail. For example, if somebody at pyramid sends to decwrl!hplabs!person, we will relay the message to hplabs. You all know this. This is what uucp means. As a participant in the Internet, decwrl will pass internet mail that is sent to it, so that if somebody sends mail to decwrl!sri-nic.arpa!feinler, we will relay the mail to feinler@sri-nic.arpa via the Internet. As a participant in CSnet, decwrl will pass CSnet mail, as above. As a participant in Digital's own internal network, decwrl will relay mail addressed to a computer inside digital, e.g. tsc.dec.com. If we receive a message addressed to decwrl!tsc.dec.com!pete, we will relay it to TSC::PETE, which is the internal address for that person on that machine. However, if you send mail to "pete@tsc.dec.com", it is up to your mailer to obey the internet protocols correctly and determine that decwrl is the relay. The name servers for .dec.com tell you to send all .dec.com mail to us; we will in turn send it to its correct destination. If your mailer has access to Internet name servers, then all this will work automatically. If your mailer uses host tables, you will find that tsc.dec.com is not in the host tables, and you cannot use the form "pete@tsc.dec.com". You must instead use the form "pete%tsc.enet@decwrl.dec.com". If your mailer is not an Internet mailer, but uses uucp or smail or something like that, then the name .dec.com will be resolved by pathalias in ways that we cannot control. I absolutely guarantee you that if you can cause your mailer to get a piece of mail shipped to decwrl, with an address of person@node.dec.com, person@node.dec, or person@node.enet, that we will relay it to that destination for you. Since I know nothing about your mailer, I recommend that you use the maximally conservative address decwrl!tsc.dec.com!pete Brian
bill@carpet.WLK.COM (Bill Kennedy) (07/16/88)
In article <606@bacchus.DEC.COM> reid@decwrl.UUCP (Brian Reid) writes: >In article <121@carpet.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >> [ my stuff deleted ] Before I get into following up what Brian says, I must report that I got an email note from the Colorado Springs Digital office I was groaning about. The problem is *not* at decwrl, the problem is withing the way that the network addressing works out (as Brian points out below). I was also told (and on a re-read of my posting, I agree) that I suggested that decwrl doesn't do a thorough job of routing. This needs emphasis, I did *NOT* mean to suggest or imply that. Nor did I mean to suggest or imply that Digital is not 100% behind usenet. The fact that the decwrl machine is a dedicated vax, no other duties other than mail and news is certainly sufficient evidence of Digital's comittment to usenet and I salute them for it. When I used the term "humbly" it was exactly what I meant, no sarcasm. If anyone else got that notion, you wren't reading what I wrote, I meant humbly, 'nuff said. [ Brian points out that decwrl will field and forward not only uucp traffic, but also Internet traffic. He's right, I've seen it, it's awesome. ] >As a participant in Digital's own internal network, decwrl will relay mail >addressed to a computer inside digital, e.g. tsc.dec.com. If we receive a >message addressed to decwrl!tsc.dec.com!pete, we will relay it to TSC::PETE, >which is the internal address for that person on that machine. This is where I tripped. The combinations and permutations of addresses that I had tried had all resolved to an internal address that was not acceptable within Digital's network. Further, the other two sites that tried the same address tried the same combinations. I ASSumed that since three sites all tried the same technique that decwrl was broken, the technique was broken. Had we used something acceptable to the Digital network it probably would have gone through just fine (I'm going to try it :-) [ explanation of "address it wrong" "I send it back" deleted ] >and you cannot use the form "pete@tsc.dec.com". You must instead use the form >"pete%tsc.enet@decwrl.dec.com". If your mailer is not an Internet mailer, but This was spelled out for me, just this way, and I'll bet it will work. Also, I didn't point out that the site that I was complaining about, a non-Digital site that appeared in decwrl's map, no longer appears in their map so I can't grouse about that bouncing either. >resolved by pathalias in ways that we cannot control. I absolutely guarantee >you that if you can cause your mailer to get a piece of mail shipped to >decwrl, with an address of person@node.dec.com, person@node.dec, or >person@node.enet, that we will relay it to that destination for you. I believe it (but I'll have to stick my finger in the wound :-), I will try it and I have as much confidence as Brian does that it will work. >Since I know nothing about your mailer, I recommend that you use the >maximally conservative address decwrl!tsc.dec.com!pete Alas! I can assure you that ^^^^^^^^^^^^^^^^^^^^^^^ will absolutely not work, that's one of the ones I tried, as did others. No matter, now that we all know about "site.enet@decwrl.dec.com", it's a big win. I hope that my site and the other two weren't the only ones on usenet with the problem. I spent a lot of bandwidth if so. -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill
reid@decwrl.dec.com (Brian Reid) (07/16/88)
In article <122@carpet.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >>maximally conservative address decwrl!tsc.dec.com!pete > >Alas! I can assure you that ^^^^^^^^^^^^^^^^^^^^^^^ will absolutely not >work, that's one of the ones I tried, as did others. If the address decwrl!tsc.dec.com!pete did not work, then there is something wrong with your mailer. If you will forward me the error message that you get back I will diagnose it for you and make suggestions for how you might fix it.
vixie@palo-alto.DEC.COM (Paul Vixie) (07/19/88)
In article <122@carpet.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes:
# [...] I was
# also told (and on a re-read of my posting, I agree) that I suggested that
# decwrl doesn't do a thorough job of routing.
Don't feed _too_ badly about it, because...
...we don't.
Hmmm?
Yup. No UUCP routing. If you send mail to decwrl!xyzzy!person, then xyzzy had
better be one of...
a dotted internet domain, MX or A record known to the root named's
an internal (decnet or SMTP) host
a UUCP neighbor of decwrl
...the one thing we don't do (yet) is find a path to "xyzzy" if they aren't
found in the above search path but are in the UUCP map.
It's coming. RSN. The glow is almost visible on the horizon.
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013reid@decwrl.dec.com (Brian Reid) (07/19/88)
In article <3501@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: >Yup. No UUCP routing. If you send mail to decwrl!xyzzy!person, then xyzzy >had better be one of... > > a dotted internet domain, MX or A record known to the root named's > an internal (decnet or SMTP) host > a UUCP neighbor of decwrl > >...the one thing we don't do (yet) is find a path to "xyzzy" if they aren't >found in the above search path but are in the UUCP map. And with a little luck, we never will. This kind of pseudo-AI belongs in user agents, not transport.
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/20/88)
In article <616@bacchus.DEC.COM>, reid@decwrl.dec.com (Brian Reid) writes: > In article <3501@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: > And with a little luck, we never will. This kind of pseudo-AI belongs in user > agents, not transport. That's a matter of opinion ... -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- A misplaced Kansan trapped in the heart of Kentucky, <---- the state where it is now illegal to water your lawn on the wrong day.
jordan@zooks.ads.com (Jordan Hayes) (07/21/88)
David Herron <david@ms.uky.edu> comments on Brian Reid's <reid@decwrl.dec.com> assertion that "This kind of pseudo-AI belongs in user agents, not transport.": "That's a matter of opinion ..." I guess, 4 years later, i've still not seen good justification for what David is implying ... /jordan
egisin@watmath.waterloo.edu (Eric Gisin) (07/21/88)
In article <616@bacchus.DEC.COM>, reid@decwrl.dec.com (Brian Reid) writes: > In article <3501@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: > >Yup. No UUCP routing. If you send mail to decwrl!xyzzy!person, then xyzzy > >had better be one of... > > > > a dotted internet domain, MX or A record known to the root named's > > an internal (decnet or SMTP) host > > a UUCP neighbor of decwrl > > > >...the one thing we don't do (yet) is find a path to "xyzzy" if they aren't > >found in the above search path but are in the UUCP map. > > And with a little luck, we never will. This kind of pseudo-AI belongs in user > agents, not transport. Another reason not to do it is that you have two independently managed namespaces, the internal DEC hosts and the .UUCP hosts. If decwrl!grot!user where routed to grot.uucp one day, it might be routed to grot.dec.com the next day, and Usenet users would never know about it since DEC doesn't make their internal host namespace known to Usenet. Routing decwrl!host.uucp!user is reasonable though.
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/22/88)
In article <4930@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: >David Herron <david@ms.uky.edu> comments on Brian Reid's ><reid@decwrl.dec.com> assertion that "This kind of pseudo-AI belongs in >user agents, not transport.": > > "That's a matter of opinion ..." > >I guess, 4 years later, i've still not seen good justification for >what David is implying ... > >/jordan ok, I am assuming that Brian meant to say that he always wants to compute his own UUCP paths out to the n-th degree. That is, if he wants to send mail to someone in Europe, he figures out the path over to uunet, then from mcvax to wherever it needs to go. [I picked a worse case on purpose]. Maybe that's not what he meant but that's how I took it. Gack! I don't like figuring routes out. That's what computers are for, remembering stupid little things like that. Unfortunately we've got a huge network that's hard to keep track of so I can't do the ideal situation here (simply say user@place and let the mail system take care of it) so I have to provide hooks to let people route their own stuff. But I give them as much help as I can by keeping an up-to-date routing database and routing on the first listed node in the path. well whatever. we all know that there's a good fight contained in this argument and we all know that there are a number of camps which won't come to terms on it ... my opinion is that end users want to have as simple a system to use as is possible. that means, to me, they should be able to utter something like user@place and let the mail system figure the rest out. now. about whether to put routing intelligence into the user-agent or not? why in the world would you want to do that? I don't like the ucbmail (mailx/Mail; /usr/src/ucb/Mail) interface. Now, it takes a fair bit of work to get routing intelligence working right -- especially to the level that peter has in his user agent. If the world requires routing intelligence in the user agent, ok, but EVERY user agent needs to have the same level of intelligence. I gaurantee you that will not happen though, because not every writer of a user agent has the same amount of time to put into things -- not all of them are interested in routing problems either. after 4 years of playing with mail systems I don't see any good justification for what Brian is apparently asserting, and if I've got the assertions down right, what you are asserting either Jordan. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- A misplaced Kansan trapped in the heart of Kentucky, <---- the state where it is now illegal to water your lawn on the wrong day.
honey@umix.cc.umich.edu (Peter Honeyman) (07/22/88)
david, i don't buy brian's argument either. saying that routing is exclusively a user agent issue is like saying that the ua should do mx queries. like you, my mta uses pathalias as a last resort for the "left-most" host (in a bang path). like brian (i guess, or maybe he's just blowing smoke), my ua has more sophisticated stuff, peter
reid@decwrl.dec.com (Brian Reid) (07/24/88)
In article <4166@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >david, i don't buy brian's argument either. saying that routing is >exclusively a user agent issue is like saying that the ua should do mx >queries. The problem is that pathalias believes what you tell it. A small amount of bad data can create a large amount of havoc. Until the data is centrally controlled, with someone responsible for errors, then I don't want my mta's doing any form of routing unless I explicitly ask them to do it for me. If I could be confident that the contents of mod.maps was mostly true, I would be happy to let the mta take over almost all routing.
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/25/88)
In article <631@bacchus.DEC.COM> reid@decwrl.UUCP (Brian Reid) writes: >The problem is that pathalias believes what you tell it. yeeeah... good ol' garbage in / garbage out. >A small amount of >bad data can create a large amount of havoc. Until the data is centrally >controlled, with someone responsible for errors, then I don't want my mta's >doing any form of routing unless I explicitly ask them to do it for me. > >If I could be confident that the contents of mod.maps was mostly true, I >would be happy to let the mta take over almost all routing. well now ... I don't see as to how we could ever get centrally maintained maps without having to pay someone. But I dare say that even if we did find someone to pay, and have some way of paying them, that they wouldn't be able to keep the map any better up-to-date than the current group does. At what size did the arpanet people start complaining about the "size of the net"? I know that bitnet people have been having trouble maintaining their file for a couple of years -- the most recent map for bitnet is right at 2500 nodes. The Usenet maps contain some 6000+ nodes right now. (At least, the pathalias output from the map is that long -- there's likely a number of aliases in there). [Holy sheep **** batman! I just took a look at the length of the pathalais output -- 14000 lines!] With that many sites in Usenet the connectivity is going to be far too unstable to be able to predict routes with ANY good degree of reliability. As I see it the only solution is to make a drastic change. Unfortunately Usenet doesn't have the luxury of 56+kb lines running all over the place over which to do nameservers .. In order to have a manageable centrally-managed table it would have to be of a reasonable size. At a guess I'd say that the upper limit for that is ~1000 entries. That's enough room for an entry for all the "important" cities [note that I'm writing from a smallish city] plus the major companies & universities. [How many entries are in the current d.* files?]. We'd have to encourage the domain entries to coordinate within 2nd level domains to make sure that there is ONE entry for each 2nd level domain which wants a gateway (which wouldn't limit them from having >1 gateway, but so long as there is ONE entry then things will be fine). But mapping this onto UUCP names isn't going to be easy at all. I think the solution lies over towards regional domains. You set up a regional domain, announce gateway(s) to that domain and don't announce any site names (other than necessary) within the domain to the outside world. The general idea works well with other domains -- the difference here is that there is no already existing organizations for the regions to handle the setting up and such. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- A misplaced Kansan trapped in the heart of Kentucky, <---- the state where it is now illegal to water your lawn on the wrong day.
jordan@zooks.ads.com (Jordan Hayes) (07/25/88)
David Herron <david@ms.uky.edu> writes:
I think the solution lies over towards regional domains.
Although the idea of "office park" domaining has been kicked around for
a while, no one has really jumped on it, and the software shouldn't
gleen any routing information from the name ... for three points,
carefully describe how "regional domains" would solve this problem
without once breaking the rule of "names are not routes" ... then point
out the essential differences between "regional domains" and
"administrative domains" and show how the software should treat them
differently ...
/jordanahby@bungia.Bungia.MN.ORG (Shane P. McCarron) (07/27/88)
In article <4971@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: >David Herron <david@ms.uky.edu> writes: > > I think the solution lies over towards regional domains. > >Although the idea of "office park" domaining has been kicked around for >a while, no one has really jumped on it, and the software shouldn't >gleen any routing information from the name ... for three points, >carefully describe how "regional domains" would solve this problem >without once breaking the rule of "names are not routes" ... then point >out the essential differences between "regional domains" and >"administrative domains" and show how the software should treat them >differently ... > >/jordan Okay... I know that I am starting to sound like a broken record on this subject, but... Minnesota has in fact had such a system in place for over a year now. Let me try and summarize how it all works: First, you have to find some jerk who is willing to take on all of the responsibility and headaches of administering the domain park (that's me :-). Once you have found your patsy, you can go to town. The idea is to have everyone in the region get a domain address. Since the concept of domain addresses is well known in this forum, I will not belabor it - suffice it to say that you need to educate your public about why being a member of the internet community is a good thing. Once you have done this you try to get the major local sites to sign up, and the rest follow. That's it in a nutshell. For those of you who want gruesome details, I wrote a (rejected) paper for this summer's Usenix about it, and I would be happy to send it along. To address the points raised above: The names are not routes theory is fine as far as it goes. However, in the domain world names are routes. If I send something to site.lala.berkeley.edu I am pretty sure that it is going to go to UCB, and then be relayed from there. If it doesn't actually go that way, that's fine. However, the route is implied. Any site who is concerned about being associated with a specific region (because, for instance, they might move) can of course establish their own domain. The regional parks (like mn.org or chi.il.us) are for those companies or persons who want an internet name but do not want the hassle of finding forwarders and nameservers on the internet, or who do not want to clutter up an already polluted namespace. What is the difference between a "regional domain" and an "administrative domain"? Well, the former is a place in which companies, or administrative entities, can place themselves without a hassle. An administrative domain is just that - a namespace that is administered by a central authority. While a regional domain is sort of like that, it can be said that the regional domain park only administers the second level of the namespace. In an administrative domain, the namespace control would probably happen throughout the space. How would the software handle it differently? Well, it doesn't really have to. All that needs to happen is that mail destined for a specific domain be sent through that domain's gateway. This happens now, at all levels of the tree, and I don't believe that we need to complicate the situation any more. While there may be many gateways into sub-domains of a namespace, that is also automatically handled currently. Again, we need do nothing. This answer is so clear to me that I must not understand the question :-) Anyway, what are the advantages of domain parks? Well, they provide a central, regional routing and naming authority. This site is used as a router by about 60% of the registered sites in this region. Since these sites, for the most part, have no links outside of the region, they can leave the routing of outbound mail to bungia. I could go on about this, but I'm tired of typing :-) If there is sufficient interest, I will post a summary of all the services that our domain park provides to the subscribers, as well as a fee schedule, and ideas about how to start a regional domain park in your area. -- Shane P. McCarron UUCP: ahby@bungia.mn.org Systems Analyst ATT: +1 612 224-9239
tron@amdahl.uts.amdahl.com (Ronald S. Karr) (07/28/88)
In article <4930@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: >David Herron <david@ms.uky.edu> comments on Brian Reid's ><reid@decwrl.dec.com> assertion that "This kind of pseudo-AI belongs in >user agents, not transport.": > > "That's a matter of opinion ..." As somebody who is helping to write a complete mailer from the ground up, I must say that this kind of intelligence definitely should not exist in the user agent. Why? 1. The means for resolving addresses should be centralized. When there exists more than one user agent on a system, there is only one reasonable means of centralizing the algorithm: put it in the mailer. 2. There is no reason to assume a specific model for performing hostname resolving, when pathalias is available. Consider, for example the model for a site that is on the internet, has some local networks of its own, is connected to UUCP, and is the registered gateway for a set of UUCP-only sites. To do this requires: a. A file describing the paths to sites for which we perform the gateway service. b. Hostname resolution through name server queries. c. Various other routers/hostname resolvers, to match your internal networking systems. d. A paths file describing the UUCP zone. In order for pathalias routing to occur in the user agent, a user agent would have to determine that a host could not be matched by any of steps a, b or c. Question for those who advocate not having routing done in the mailer: Consider a site which is not on the internet at all: should the UA also route for user@dom.ain addresses as well? Remember that we are discouraged from using the ARPAnet as a means of transmitting mail from point A in the UUCP zone to point B in the UUCP zone. If point B is a domain address, then a site must find a path to B for this to work. Should a UA do this even in the presence of a set of local area networks that have a domain-based organization? -- tron |-<=>-| ARPAnet: amdahl!tron@Sun.COM tron@uts.amdahl.com UUCPnet: {decwrl,sun,uunet}!amdahl!tron [views above shouldn't be viewed as Amdahl views, or as views from Amdahl, or as Amdahl views views, or as views by Mr. Amdahl, or as views from his house]