sean@dranet.dra.com (Sean Donelan) (10/30/89)
In article <71081@uunet.UU.NET>, rick@uunet.UU.NET (Rick Adams) writes: > > I dont know how much more simple you can make it than "leave #4 alone" Simple don't put #4 on the form. I think there are several problems with trying to MX-the-world to eliminate the %-hack and other forms of explicit routing. 1. It is impractical, if not impossible. One of the readers of this list has most likely written the definitive routing paper to date (or at least included it the bibliography of the paper they did write), why routers can't have universal knowledge of the network. Trying to minimize when one has to resort to explicit routing is fine, prohibiting explicit routing is something else. Security and other policies will most likely require the limitation of explicit routing at the cost of lower connectivity. But that is the purpose of those security and other policies (to lower connectivity). 2. Politically, and adminstratively the Internet is difficult to deal with by non-Internet (though possibly gatewayed) networks. And "acceptable use" policies make it necessary to route through an "acceptable" route. The choice of these two (or more) routes must be determined by the sender based on the "intent" of the communication. Currently my company has a half-dozen network addresses, assigned by various network bodies. Most are chartered to provide essentially "universal" service, but the Internet is not. If, as I believe, the Internet DNS exists to make life easier for Internet users then registration of non-Internet networks is merely a matter of convience for the Internet community. If registration is a prerequisite for communication between Internet and non-Internet networks then it becomes a enforcement mechanism. 3. The "what do you care?" point. The %-hack is in the local part anyway. It should only be the concern of the sender and the gateway. If you're not a gateway don't worry, if you are a gateway its your job to worry. -- Sean Donelan, Data Research Associates, 1276 N. Warson, St. Louis, MO 63132 Domain: sean@dranet.dra.com, sean%dranet@wupost.wustl.edu UUCP: ...!wugate!wupost!dranet!sean, Voice: (Work) +1 314-432-1100 "I don't speak for anyone else, and they don't speak for me."
amanda@mermaid.intercon.com (Amanda Walker) (10/31/89)
In article <299@dranet.dra.com>, sean@dranet.dra.com (Sean Donelan) writes: > 3. The "what do you care?" point. The %-hack is in the local part anyway. > It should only be the concern of the sender and the gateway. If you're not > a gateway don't worry, if you are a gateway its your job to worry. This is fine when there is only one gateway involved. What happens when I need to go through a number of gateways, each of which has its own magic local part? One of the big problems with mixing addresses and routes (which is what using % does) is that it can give you some real ambiguity headaches. Consider the "address" random!mumble%foo!bar%zot@foobar.domain from a UUCP site whose mailer understands both RFC 822 addresses and UUCP routes (as many do these days). How do you send mail to this person? Answer: you pray, and your mail probably bounces somewhere, not because any individual pair of hosts don't talk to each other, but because you can't tell them where you want the mail to go unambiguously. This is something that the DNS and MX records are very good at addressing, as Karl has pointed out with his CompuServe example. Anyone who thinks my example is contrivedly complex is either new to inter- network mail or doesn't try to send mail to certain organizations that shall remain nameless for the moment (which use DECnet and VMS mail :-)). Also, any time a gateway cobbles up a source route in the local part, you run the (very real) risk of ending up with one-way mail. A good friend of mine is currently on a site that can send me mail, and to which I can send mail. However, in both directions the return address gets mangled beyond usability, thanks to helpful bangs and %s in the local part. As it happens, using simple domain addresses works great (thanks to the DNS and pathalias), but the gateway doesn't know this :-(... I've also gotten plenty of mail replying to articles I've posted in which the return addresses are undecipherable, thanks to gateways using source routing. -- Amanda Walker <amanda@intercon.com>
CERF@A.ISI.EDU (11/04/89)
Sean, I don;t disagree with your observation that one can probably never eliminate source-routing in its entirety. However, as a long-time user of a broken User Agent (which relied on host tables), I can say with confidence that it was a pleasure to move to a user agent which had regular access to DNS information. I was unable to respond conveniently to about 25% of the messages that arrived using the older system. Consequently, I think it would be helpful to pursue the goal of outfitting as many systems as possible with reliable access to DNS. As to source routing specifically, it has always seemed to me a problem to know which gateways to route through. Figuring out ab initio how to route to a bitnet user has always been awkward for me, at any rate. Once I memorized a likely gateway/relay, they'd retire the darn thing, for instance. Replying to a message received from a source routing sender is a little easier, assuming, of course, that the relay is known to DNS or is in your host table (sigh). Vint Cerf
rhg@cpsolv.UUCP (Richard H. Gumpertz) (11/09/89)
In article <2441@csun.edu> cbcscmrs@ma.csun.edu (Mike Stump) writes: >I have one simple question, why don't we (The Internet side) put an MX record >into the root servers for the top-level domains .bitnet and maybe even .uucp? I have always wondered why there were no .MX records for ".UUCP". It sure would make things easier for the sites that are in the "official" UUCP maps to interact with the Internet world. Any reason not to implement it? I suspect that many of the major backbone sites already have the maps in place, so it probably wouldn't cost much in time or resources. -- =============================================================================== | Richard H. Gumpertz rhg%cpsolv@uunet.uu.NET -or- ...uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ===============================================================================
brian@ucsd.Edu (Brian Kantor) (11/10/89)
I have in MY nameserver the following for the bitnet "top level domain". Because there is no record in the root nameserver pointing at me for ".bitnet", this is not advertised to the outside world, but it allows my mail system to treat "user@host.bitnet" just as it would any other domain-type mail. Because I assign these hosts equal priority (and because sendmail-5.61 randomizes usage of equal-priority MXs), my limited amount of bitnet traffic gets spread between the several gateways I have listed. (I think there are more internet->bitnet mail gateways but these are the ones I know about.) This is a real hack but it works real well for me. I don't see why this couldn`t be done internet-wide but I suspect the reason is other than technical. Is that true? - Brian in the boot file: primary bitnet bitnet in the 'bitnet' file: @ IN SOA ucsd.EDU. brian.ucsd.EDU. ( 880506 7200 1800 2419200 86400 ) * IN MX 10 cunyvm.cuny.edu. * IN MX 10 mitvma.mit.edu. * IN MX 10 uicvm.uic.edu.
scs@itivax.iti.org (Steve Simmons) (11/11/89)
cbcscmrs@ma.csun.edu (Mike Stump) writes: >I have one simple question, why don't we (The Internet side) put an MX record >into the root servers for the top-level domains .bitnet and maybe even .uucp? rhg@cpsolv.UUCP (Richard H. Gumpertz) writes: >I have always wondered why there were no .MX records for ".UUCP". It sure >would make things easier for the sites that are in the "official" UUCP maps to >interact with the Internet world. Any reason not to implement it? I suspect >that many of the major backbone sites already have the maps in place, so it >probably wouldn't cost much in time or resources. How do you differentiate between the 'right' .uucp site for your mail? The MX records will come to you in preference order, not uucp connectivity order for the site you want. Since the MX record causes the mail to be delivered to the host listed in the record, all *.uucp mail would go to the *same* host for uucp handling. I dunno anybody willing to handle that! -- Steve Simmons scs@iti.org Industrial Technology Institute "Batches? We don't need no steenking batches."
jmwobus@cmx.npac.syr.edu (John Wobus) (11/11/89)
In article <4395@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes: >cbcscmrs@ma.csun.edu (Mike Stump) writes: >>I have one simple question, why don't we (The Internet side) put an MX record >>into the root servers for the top-level domains .bitnet and maybe even .uucp? > >rhg@cpsolv.UUCP (Richard H. Gumpertz) writes: >>I have always wondered why there were no .MX records for ".UUCP". It sure >>would make things easier for the sites that are in the "official" UUCP maps to >>interact with the Internet world. Any reason not to implement it? I suspect >>that many of the major backbone sites already have the maps in place, so it >>probably wouldn't cost much in time or resources. > >How do you differentiate between the 'right' .uucp site for your mail? >The MX records will come to you in preference order, not uucp connectivity >order for the site you want. Since the MX record causes the mail to be >delivered to the host listed in the record, all *.uucp mail would go to >the *same* host for uucp handling. I dunno anybody willing to handle that! >-- >Steve Simmons scs@iti.org Industrial Technology Institute > "Batches? We don't need no steenking batches." It would be neat if mail software could automatically find the nearest public gateway to BITNET. The DNS doesn't doesn't deal with concepts like "nearest", but IP routing tables do. In the past, I've dreamed of kludging together some method by which routing metrics route information to the nearest gateway, but we can imagine what it would be like to open an SMTP connection to some gateway and in the middle of transmitting the message, have a "network shift" cause your data to start heading for a different gateway! However, one could imagine a system by which a single packet uses the routing table to find the nearest gateway, an answer from the gateway tells the sender what the gateway's (normal) IP address is and then the SMTP session starts after that. In more straightforward terms: (1) Sender asks DNS for the IP address & gets an address which is being advertised by gateways in many places. (2) Sender sends a single packet to that address to a service which returns its own real IP address. (3) Sender starts SMTP session. Since this is a whole lot of changes, the real "first" question is: are there enough similar needs to justify the trouble involved in getting everyone to implement whatever is necessary? One could imagine that files wanted by a lot of people could be dispensed from a system of identical file servers throughout the Internet, each holding the same files. The root nameserver addresses could be advertised that way. Perhaps at the local level, nameservers suitable for resolver use could be advertised that way. Can anyone think of other uses? The "second" question is: what is the least amount of changes that could make something like this work (without "too" much kludging). John Wobus Syracuse University
carlson@uxh.cso.uiuc.edu (11/12/89)
By: jmwobus@cmx.npac.syr.edu Nov 10, 1989 [ stuff about UUCP deleted ] >It would be neat if mail software could automatically find the >nearest public gateway to BITNET. The DNS doesn't deal >with concepts like "nearest", but IP routing tables do. This is the crucial point. IP routine minimizes travel time (and travail) for IP packets. UUCP (I think) also optimizes routes. DNS was, of course, is designed for a different purpose, and was not intended to duplicate the functionallity of IP routing. DNS seemed like a good place to put MX translation, and it works fine for Internet mail, since Autonomous Sites and MX handlers corrolelate very well with geographical/topological regions. >However, one could imagine a system by which >a single packet uses the routing table to find the nearest gateway, >an answer from the gateway tells the sender what the gateway's >(normal) IP address is and then the SMTP session starts after that. One hitch is that it sounds like "nearest foriegn gateway" information would have to be encoded in every new routing protocol that comes along. (Though it might just be worth the trouble.) What I think is really needed is for the IP protocol to have some concept of foreign destinations. Perhaps a Class D (Multi-cast) address could be reserved for the meaning of "Nearest Bitnet Gateway", and gateway hosts would advertise themselves as such. I am not up on the details of multicasting, but sounds like this capability could implement what John suggests. Hosts wishing to send to the .Bitnet domain could skip DNS tables and query IP routers with a special request packet. This way, Non-IP mail could be properly routed based on distance. This would of course require fundemental additions to the IP protocol (disturbing to purists), but mail service is so central to the use and growth of the network that perhaps someone should give it some serious though. >John Wobus -- Syracuse University -------------------- Brad Carlson <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu> University of Illinois -- Consultant -- NeXT guru -- Windows Programmer
david@ms.uky.edu (David Herron -- One of the vertebrae) (11/12/89)
There's a problem that's been floating around in the back of my head
that's partly politics and partly graph theory. I've never come
to an acceptible answer ...
It's this
suppose you have >= two computer networks which are described with
a weighted directed graph. (er.. come to think of it, the real world
example includes a net that isn't weighted or directed. at least from
the e-mail point of view). These networks actually have multiple
physical connections between themselves, but little-to-no coordination
of routing between themselves.
Now ... how do you pick the "shortest" and/or "best" route between
any two nodes on this conglomerated network?
In (almost) all cases all a site knows is that the destination site is
on another network, due to MX records this isn't always known. What
is always known is one-or-more gateways to use. All the site knows
is the "weight" to reach the gateways. It doesn't know the weight
from each of the gateways to the destination, and it doesn't always
know an actual weight to the gateways.
(In MX records, there's a weight of sorts attached to each gateway.
However that weight isn't related to the topological distance between
the nodes. Therefore it's not a useful weight in figuring out
which is the closest gateway to the sender ...)
For instance ... if you're on UUCP going to BITNET you only know
the closest BITNET gateway. All your BITNET mail goes over to that
gateway even though it might be better to send some BITNET mail to
one gateway and some to another. On BITNET there's some links near the
"center" of the net which are chronically overcrowded. It'd be
best in terms of reliability and transmission times if ... well,
your gateway is going to be on one side or another of the "center"
of BITNET. If your routing software somehow knew which side your
target was on then it could pick an appropriate gateway.
This would become easier if BITNET & UUCP were to exchange weighting
information back and forth ... each network has a pathalias-like tool
(program for calculating spanning trees of a weighted directed graph).
In a previous message I suggested a method whereby BITNET information
could be distributed in the Usenet maps. Specifically for each gateway
list all the BITNET nodes along with weights from that gateway to the
particular node. Hopefully a good criteria for calculating the weights
could be come up which would weigh in both the actual distance and
normal traffic loads on that section of BITNET.
It's more complicated on the Internet since MX records, or anything
else for that matter, doesn't give you any indication of reachability
between any two nodes on the Internet. The Internet likes to
pretend that all sites are equally reachable, which just ain't
so. For instance, from SURAnet most of MILnet is basically unreachable.
The normal RTT for ping packets is on the order of 1.5 to 3 seconds,
which just ain't good.. Keep alive mechanisms start failing at that
sort of RTT times ... (unless you're using Phil Karn's TCP/IP code :-)).
Anyway, this is a bunch of incompleted thoughts and I apologize if
this seems rough around the edges. It's been awhile since I've
had the spare time to think about this problem, and it is somewhat
late right now. (gosh, back when I was a student this was certainly
not a "late" time of night -- it's only midnight :-)).
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New official address: attmail!sparsdev!dsh@attunix.att.comlear@GENBANK.BIO.NET (Eliot Lear) (11/12/89)
A problem with .BITNET is that there is indeed a lack of granularity. This would seem to me to be a strong reason for BITNET hosts to get real domains (as it seems they have been). -- Eliot Lear [lear@net.bio.net]
tneff@bfmny0.UU.NET (Tom Neff) (11/13/89)
Perhaps, instead of trying to pre-guess the weighting of the world, we could dynamically exchange weighted volume-carried information between all nodes and gateways before transmission begins. This way you would have a constantly self-adjusting network. -- There's nothing wrong with Southern California that a || Tom Neff rise in the ocean level wouldn't cure. -- Ross MacDonald || tneff@bfmn0.UU.NET
brnstnd@stealth.acf.nyu.edu (Dan Bernstein) (11/14/89)
In article <16300008@uxh.cso.uiuc.edu> carlson@uxh.cso.uiuc.edu writes: > IP routine minimizes travel time > (and travail) for IP packets. Ummm, no. It ``minimizes'' travel time based on an always out-of-date picture of network load. The routing algorithms used by the Internet transmit and use routing information as quickly and as often as data; this leads to route flapping, completely lost routes, and other forms of instability. There is no way to minimize correctly, dynamically, and in real time. ---Dan
roy@phri.UUCP (Roy Smith) (11/14/89)
In <16300008@uxh.cso.uiuc.edu> carlson@uxh.cso.uiuc.edu writes: > The DNS doesn't deal with concepts like "nearest" But what if it did? Let's say I'm the DNS server for the .BITNET domain. When a request comes in for an MX, I take a look at where the request came from and use that information to select the proper MX record to send back. If I can't figure out which is the best, I send back some default gateway. I could even send back the same set of MXers to everybody, but with customized priorities. That's not how DNS is supposed to work, but how could an outside entity detect that I'm doing something fishy? The fact that repeted requests don't give back the same answer is in itself not a protocol violation; what's to keep me from changing my master file every 10 seconds if I wanted to, and how could you tell the difference between a quickly changing master file and a routing DNS server? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/16/89)
In article <4118@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > But what if it did? Let's say I'm the DNS server for the .BITNET >domain. When a request comes in for an MX, I take a look at where the >request came from and use that information to select the proper MX record >to send back. If I can't figure out which is the best, I send back some >default gateway. I'd like to see something similar for uucp sites. Let's say we create a domain foo.org and allow uucp sites to call themselves uucp_name.foo.org (without the problem of having to find a forwarder). When a MX request comes in, we look up the closest internet site based on pathalias data and a list of internet/uucp gateways and respond with this. Make sure that the list of internet/uucp gateways is large wrt to the number of uucp sites using foo.org to prevent load problems. You could do this right now, except for the fact that these internet/uucp gateways need to rewrite the address from uucp_name.foo.org to uucp_name. Too bad sendmail isn't a bit smarter about using some other means of address resolution when it ends up talking to itself (or the DNS having some address rewriting ability). There is currently a problem with uucp sites not getting domain names because they don't have any contacts with forwarders and don't want to pay for something like uunet. They still use the forwarders (by things like user%site@forwarder.domain); it just makes for ugly addresses. -- Branch Technology <zeeff@b-tech.ann-arbor.mi.us>