honey@umix.cc.umich.edu (Peter Honeyman) (09/26/87)
In article <7333@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >At the moment our problem with it [mush] is that > > 1. It wants to do routing ... That feature can be turned > off, but still it doesn't belong in a User Agent. it follows from bitter experience that routing in the DA should be of the most casual style ("dumb" or "first host" routing). the UA is precisely where routing belongs, where it can be as smart as you like since the user can inspect and modify the result. peter
greg@ncr-sd.UUCP (09/27/87)
>In article <7333@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >> [discussing what he perceives as problems in Mush] >> 1. It wants to do routing ... That feature can be turned >> off, but still it doesn't belong in a User Agent. To which the infamous Peter Honeyman (honey@citi.umich.edu), replies in article <1631@umix.cc.umich.edu>: >the UA is precisely where routing belongs, where it can be as smart as >you like since the user can inspect and modify the result. I think you are both right and both wrong. There are certainly some aspects of generating a valid return address that belong in the user agent, including inspecting the path that the the router proposes to use, but on the other hand, I don't think that the user agent is the right place for making the actual routing decisions. That should be done by an agent of the system administrator (or other management) as they are the ones that should have the final say in allocating the resources. Note that there are several issues here. One is re-writing the destination given by the user (or extracted from a header, or whatever) into a valid address. This would include tasks like taking a partially-qualified name and changing it into a fully-qualified domain name, modifying a path relative to somewhere else into a self-relative path, or converting a path into an address (I know, it's not always possible to do, but a partial job would be better than none). This is clearly the job of a user agent. Another job is the delivery of the mail. In most cases (Peter is an exception), the user doesn't care how the mail is delivered, as long as it \is/ delivered. This job is better left to a delivery agent, that is, a router, that enforces the policy decisions of management. Another way of saying this is that the routing decisions should be left to someone who knows more about the routes; this person is almost \never/ the user. What I would like to see would be some way of capturing the routing descisions (not only local decisions, but also considerations about other machines) in a way that a user agent could make use of them, and then to be able to look at the proposed routes and amend the addresses if desired. And I would like the descisions to be maintained centrally; that is, the user agents all use the information in the same way. And that it would be easy to change a things around. About the only way I see of doing this is for someone to implement a library (or at least, a library interface) that does all of these things, and make it so easy to use that all user agents \want/ to use it. But do I think this is possible? Naaahhhh..... Hmmm, this is getting a little long; I'd better quit before what I am trying to say gets lost in the fog. The basic point that I am trying to make is that to say that routing (decisions/information) belongs \only/ in the user agent or \only/ in the delivery agent is too narrow a position. Routing is a job that often can use some direction from the user, but on the other hand, it is too (dangerous/costly/error-prone) to leave completely in the hands of the average user. Rather than argue about where the decision should be made, I'd rather that we discuss how to distribute the functionality so that the user can see what is intended for his mail and can influence the process. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (09/27/87)
In article <1631@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >In article <7333@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >>At the moment our problem with it [mush] is that >> >> 1. It wants to do routing ... That feature can be turned >> off, but still it doesn't belong in a User Agent. First, I think I said that about ELM, not MUSH. I personally haven't looked at MUSH enough to say that about it. But no matter, the objection is still correct. >it follows from bitter experience that routing in the DA should be of >the most casual style ("dumb" or "first host" routing). > >the UA is precisely where routing belongs, where it can be as smart as >you like since the user can inspect and modify the result. > > peter Putting the routing into the UA would require my users to know all sorts of grungy details about networks. Things which they don't want to know! Things which change from time to time. seismo is no longer the forwarder for the Known World. ihnp4 is no longer the center of the universe. akgua no longer is the center of the southeast, and cbosgd will probably no longer be the center of the eastern-mid-west. And so on. Two of the networks we're on want us to believe there is no such things as routes, and for the most part there isn't. (BITNET and the Internet). Not even I (the E-mail hack for the U of KY) want to deal with that routing baggage in the User Agent. Also, I don't think I could possibly generate the appropriate information with the configuration of the local systems. Locally we have an 11/750 and some uVaxIIen and some Sunen and a Sequent. For historical reasons, the Vaxen are the main machines ... especially for mail purposes. The interface into bitnet is at the 750. The interface into uucp is on one of the uVaxIIen. The "controlling system" from which all the connection information is emanated is yet another uVaxIIen. That's 3 machines which have a good idea of the shape of the world. ALL of the other machines only know about the local machines, and to forward anything they don't know about over to the "controlling system". Suppose we've got this fancy-dancy user-agent you've described before, where you give it an address and it tells you the way it's going to route it, allowing the details to be changed as desired. (I'll pretend for the moment that this is do-able under MMDF, which I'm not sure if it is or isn't ...). I'm sending mail from a uVaxII workstation which doesn't have the disk-space to store the whole routing database. Where do I get the information from? Yah, I could have some sort of protocol the UA talks to a server on a central machine ... This fancy database/server combination doesn't help anyway. The maps are always a couple of months out of date, a fact which will probably never change. Given that it's always out of date, how is every last one of my users going to be able to keep up with the connection information. They generally have a very vague idea how all this stuff works to begin with? But all this stuff we're talking about here is stuff-to-be-implemented. And also of questionable value (i.e. it's questionable if many people want it). -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- E-Mail hacks get to talk about Spanish Cows whenever they want.
edward@engr.uky.edu (Edward C. Bennett) (09/27/87)
In article <1631@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >In article <7333@e.ms.uky.edu> david@ms.uky.edu (David Herron) writes: >>At the moment our problem with it [mush] is that >> 1. It wants to do routing ... That feature can be turned >> off, but still it doesn't belong in a User Agent. >it follows from bitter experience that routing in the DA should be of >the most casual style ("dumb" or "first host" routing). >the UA is precisely where routing belongs, where it can be as smart as >you like since the user can inspect and modify the result. I must disagree. With the advent of domains, users aren't supposed to need to know about routes any more. DA's are the ones that know all the good routes to places. That way, all a UA has to know is how to compose and submit a piece of mail. HOWEVER, I, as a user, should still be able to use, say, mail ukma!cbosgd!mtuxo!mtune!rutgers!citi!honey and not have anything mess with the route. -- Edward C. Bennett DOMAIN: edward@engr.uky.edu UUCP: cbosgd!ukma!ukecc!edward "Goodnight M.A." BITNET: edward%ukecc.uucp@ukma "He's become a growling, snarling white-hot mass of canine terror"
honey@umix.UUCP (09/28/87)
it appears that greg and i are in violent agreement (except on a small matter of infamy). yes, the MTA has to be a able to route messages. (in a previous note, i said something about a DA doing the routing. i take it back. i mean the MTA.) this is a vacuous point, since the MTA has the fundamental responsibility for the most basic routing decisions: picking the delivery channel. the utility of UA routing is as greg suggests: letting users inspect the routes, as a sanity check. this allows mail hackers to employ arbitrarily complex routing algorithms without having to worry (too much) about host name collisions, etc. mind you, "under user control" means precisely that: the default action is to ship the specified addresses to the MTA untouched. and of course, the MTA remains the final arbiter of routing decisions. this is not a gedanken experiment: i added a comand to the UA i use (a hacked up Mail) a long time ago, and it's quite satisfactory. i don't \always/ use its routing capability, but i use it enough to be convinced it's a good thing. david and edward seem to doubt whether routing in the UA can be done at all, or whether there is such a thing as routing. we disagree on the basics, and will probably never find a common ground, which is ok too. peter
honey@umix.UUCP (09/28/87)
steve bellovin, who wrote the first version of pathalias, also
distributed hooks to the prevailing UA and MTA of the day. even
there, users had coarse-grained control over routing, as in the
following .mailrc fragment.
# trust originating addresses, don't trust reply addresses.
if receive
set pathalias="smart"
else
set pathalias="dumb"
endif
petertorben@dorsai.ics.hawaii.edu (Torben N. Nielsen) (09/28/87)
In article <1599@ukecc.engr.uky.edu> edward@engr.uky.edu (Edward C. Bennett) writes: >In article <1631@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >>In article <7333@e.ms.uky.edu> david@ms.uky.edu (David Herron) writes: >>>At the moment our problem with it [mush] is that >>> 1. It wants to do routing ... That feature can be turned >>> off, but still it doesn't belong in a User Agent. >I must disagree. With the advent of domains, users aren't supposed >to need to know about routes any more. DA's are the ones that know >all the good routes to places. That way, all a UA has to know is >how to compose and submit a piece of mail. > >HOWEVER, I, as a user, should still be able to use, say, > mail ukma!cbosgd!mtuxo!mtune!rutgers!citi!honey >and not have anything mess with the route. I have to agree with David. User's should not know ANYTHING about the route a given message will take. The UA should only know how about addresses and the proper format of the message itself. All issues of routing should be handled through an MTA (Mail Transfer Agent) such as ``sendmail" (using appropriate databases generated through ``pathalias" or some similar tool). Can anyone site a single advantage of having users know about routes? The argument about the maps frequently being out of date doesn't hold water. Experience shows that users are far more out of date than the maps. Maybe we should all put some more effort into assuring that the maps ARE kept up to date :-) Consider what users do when they use explicit path routing. since the paths are so long, they typically use some sort of aliasing facility. That works fine until there's a problem with some site. Maybe they are dropping mail or have simply disappeared from the net. If the MTA handles all routing, I could very quickly remove the site in question from the database (at the first indication of trouble) and mail would be routed around that site. Except for the mail coming from users with long established aliases that contain full routes. Their mail might disappear into nowhere and guess who gets blamed for it.... Users should be concerned with addresses and not routes. Do you want to tell the postman the exact path he should take in order to deliver your letter? I think not. Teach the postman how to do do routing, tell him the address and leave it at that.
daveb@geac.UUCP (Brown) (09/28/87)
In article <1758@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM | (Greg Noel) writes: I think you are both right and both wrong. There | are certainly some aspects of generating a valid return address that | belong in the user agent, including inspecting the path that the the | router proposes to use, but on the other hand, I don't think that the | user agent is the right place for making the actual routing decisions. | That should be done by an agent of the system administrator (or other | management) as they are the ones that should have the final say in | allocating the resources. Well, when Honeywell was putting up an (SMTP based) mailer on one of their lines of machines this very question came up. Domains weren' tquite working ((:-)), and the routing was passed off to a logically separate entity, the "Network Host and Domain Table", which in this case really was a table. A seperate "User Oracle" was in charge of the table, and could be asked for domain, identification, routing and delivery information by the user agent, the transfer agent, the administrator or the client. It sorta worked REAL GOOD. --dave reference: Stachour et all, "GCOS Internet Mail Project Internal Documentation", Mineapolis, MN (Honeywell Corp. Computer Sci. Centre), 1983. [Stachour@Hi-Multics.ARPA] -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
usenet@calyx.UUCP (USENET admin) (09/28/87)
In article <1599@ukecc.engr.uky.edu> edward@engr.uky.edu (Edward C. Bennett) writes: >In article <1631@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >>it follows from bitter experience that routing in the DA should be of >>the most casual style ("dumb" or "first host" routing). >>the UA is precisely where routing belongs, where it can be as smart as >>you like since the user can inspect and modify the result. > >I must disagree. With the advent of domains, users aren't supposed >to need to know about routes any more. DA's are the ones that know >all the good routes to places. That way, all a UA has to know is >how to compose and submit a piece of mail. If domains worked perfectly, if databases were always up to date, if uucp connections never changed... but they do. And as long as they do, I want to be able to play with the mail routing myself. I want to be able to say "route me around system X, please." Or, "go through systems a and b, please." Right now I do routing the hard way: first, I see what the mail message (or article) has for a path - then I try pathalias. I also check whether the system is on Arpanet... all by hand. It would be nice to have this done automatically - IF I could tell the mailer, "no, please don't send it that way - it bounced the last time." ___ Ariel Glenn (std.disclaimer) {rutgers,ihnp4}!uwvax!uwmcsd1!calyx!ariel (UUCP) Love is the Law, Love under will! calyx!ariel@csd1.milw.wisc.edu (Internet)
krs@amdahl.amdahl.com (Kris Stephens) (09/28/87)
When I, as a user, know that mail is getting stuck on the "preferred"
path from here to there, and I know that another path is working
rapidly and well, *and* I have mail I feel is urgent, I want the
option of routing around the standard path. The (in)famous problems
of ihnp4 being *the* way into most of AT&T and Bell Labs while they
were hard to reach and were constantly dropping mail on the floor is
a perfect example. Here's another one: Amdahl (we) took a power hit
a couple of weeks ago (the city had to replace the massive junction box
providing power to the building). Were I a user on a nearby machine,
had I seen the posting from a neighboring site getting the word out,
and had I mail that I wanted to get through *now*, I'd want to be able
to hand-feed the path to route around the dead node.
So, make it so that I can ignore paths almost all the time, but leave
me recourse when *I* know more than pathalias does about what the
condition of the net is.
...Kris
--
Kristopher Stephens, | (408-746-6047) | {whatever}!amdahl!krs
Amdahl Corporation | | -or- krs@amdahl.amdahl.com
[The opinions expressed above are mine, solely, and do not ]
[necessarily reflect the opinions or policies of Amdahl Corp. ]honey@umix.cc.umich.edu (Peter Honeyman) (09/29/87)
there's a big difference between "users should not know anything about routing" and "users shall not know anything about routing." peter
kyle@xanth.UUCP (Kyle Jones) (09/29/87)
I completely agree that users should be given the option to override paths; pathalias/smail are not infallible. But I do question putting routing information into *the headers* and I question having the *UA* do the routing. In all the cases cited so far "routing by hand" is used as a last resort, so why should the uninitiated have to see the way routed are crazy-glued together? Furthermore if the UA uses the same data that the DA uses to produce its routes, you gain nothing. So you're left doing the routing by hand, in which case it's simple to format your own messages and hand them to the DA directly (with a good route).
krs@amdahl.amdahl.com (Kris Stephens) (09/29/87)
In article <1798@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >there's a big difference between "users should not know anything about >routing" and "users shall not know anything about routing." > > peter I still think the significant point is the difference between either of your statements and "users need not not anything about routing". ...Kris -- Kristopher Stephens, | (408-746-6047) | {whatever}!amdahl!krs Amdahl Corporation | | -or- krs@amdahl.amdahl.com [The opinions expressed above are mine, solely, and do not ] [necessarily reflect the opinions or policies of Amdahl Corp. ]
krs@amdahl.amdahl.com (Kris Stephens) (09/29/87)
In article <2589@xanth.UUCP> kyle@xanth.UUCP (Kyle Jones) writes: >I completely agree that users should be given the option to override >paths; pathalias/smail are not infallible. But I do question putting >routing information into *the headers* and I question having the *UA* >do the routing. > >In all the cases cited so far "routing by hand" is used as a last >resort, so why should the uninitiated have to see the way routed are >crazy-glued together? Furthermore if the UA uses the same data that >the DA uses to produce its routes, you gain nothing. So you're left >doing the routing by hand, in which case it's simple to format your >own messages and hand them to the DA directly (with a good route). I have no real problem with this as long as the user-interface remains constant. It's tough enough teaching someone how to use this system without letting them in on multiple pipes into the mailer. If a user can send mail to "name" or "name-at-site" or to a fully-specified path all with the same command and with all other tactile aspects the same, I think we've done him a great service. ...Kris -- Kristopher Stephens, | (408-746-6047) | {whatever}!amdahl!krs Amdahl Corporation | | -or- krs@amdahl.amdahl.com [The opinions expressed above are mine, solely, and do not ] [necessarily reflect the opinions or policies of Amdahl Corp. ]
bryan@seradg.Dayton.NCR.COM (Bryan Klopfenstein) (09/30/87)
In message <1798@umix.cc.umich.edu> Peter da Silva writes: > there's a big difference between "users should not know anything about > routing" and "users shall not know anything about routing." It appears to me that the desired phrase should be "users should not BE REQUIRED TO know anything about routing." If the individual user should wish to override the "automatic" routing capabilities, this should be allowed, however, the individual should be able to proceed quite happily without routing knowledge also. Bryan Klopfenstein (bryan@dayton.ncr.com) (usual disclaimer applies)
jwg1@bunny.UUCP (James W. Gish) (10/01/87)
In article <101@dorsai.ics.hawaii.edu> torben@dorsai.ics.hawaii.edu (Torben N. Nielsen) writes: >Users should be concerned with addresses and not routes. Do you want to tell the >postman the exact path he should take in order to deliver your letter? I think >not. Teach the postman how to do do routing, tell him the address and leave it >at that. I agree totally that users should not be concerned with routes. However I strongly believe that in general they should not be concerned with addresses either. That's what computers are for. I have worked in office automation and on electronic mail systems for a long time now and one mistake I find many people making is trying to make automated systems mimic manual systems, e.g. the "desktop" analogy or the "postman" analogy. While I do see some merit in such familiar notions to help educate novice users and make the transition to automation easier, I think that we often don't end up with the best systems by adhering to the structures of manual systems. But I digress... What I want to be able to do when I sit down to send mail is enter what in the X.400 standard is referred to as a "user friendly" name, e.g. "Jim Gish" or "Jim Gish @ GTE Labs." I don't give a hoot, nor should I, that a user's login id is jwg1 and that his host is bunny. Now I know that this is a complex technical, organizational and like it or not political problem that involves setting up naming domains and deciding how and what information is to be distributed, how name resolution is handled etc., but it is within our technical abilities to design and contruct distributed Directory Service Agents (DSAs). I also want public distributed nested distribution lists, private directories, and more. There is lots of good work being done in the standards community (see for example the CCITT x.ds work now in "progress"). However, there are many problems to be solved and too few people working on them. Let's get to work to free ourselves from the user having to know all the address gobbledygook now required to send a message. (flame over) -- Jim Gish GTE Laboratories, Inc., Waltham, MA CSNET: jwg1@gte-labs UUCP: ..!harvard!bunny!jwg1
jc@minya.UUCP (jc) (10/10/87)
> Users should be concerned with addresses and not routes. Do you want to tell the > postman the exact path he should take in order to deliver your letter? I think > not. Teach the postman how to do do routing, tell him the address and leave it > at that. This turns out to be a real bad example. Like many people, I have no trouble coming up with personal cases where the postman screwed up. For instance, a couple years back I lived close to a family that had once moved away, to the other coast in fact, and after a year or so moved back to their original home. Ten years later, they were still receiving mail that had been noticed by some diligent postal worker, forwarded to their "new" address across the country, and then forwarded back. They brought this to the attention of many, many people in the Postal Service, to no avail. The rules said that the changes of address could only be removed if they were wrong, and the family had in fact moved just like the records said, so the records had to remain unchanged. Now, I'm quite certain that everyone in that post office knew exactly what they were doing, and understood exactly why it was wrong. But rules is rules. Do you really think that we are going to have mailers installed that are more intelligent than this, in our lifetimes? If you do, hey, I've got a just slightly used bridge which you may like as an investment opportunity. Even if you can write such an intelligent forwarder, well, that's fine if my mail goes through your machine. But how are you going to stop all those organizations out there from installing "standard" mailers that follow the rules just like the above-mentioned postal workers, and screw up my mail just as badly? I hope you're not so naive that you expect a standards organization to come up with a forwarding scheme that works, or that vendors will implement a standard correctly. You might not have noticed, but there is a growing population of email users around who are concluding in a bemused fashion that those email turkeys will never get their acts together so that email stops bouncing half the time. Perhaps you could get their respect if you gave them a way of figuring out a usable path. True, we'd all like to just stick on an address, drop it in the hopper, and trust that the email will go through. But we're not near that yet; most of the problems are caused by brain-damaged forwarders all over the network; and correcting it on one machine does very little to clear up the problem. If forwarders will honor absolute bang-paths, and bounce them back if they fail, then users will at least have a way out when mail fails. -- John Chambers <{adelie,ima,maynard}!minya!{jc,root}> (617/484-6393)
jc@minya.UUCP (jc) (10/10/87)
> first, I see what the mail message (or article) has for a path - then > I try pathalias. I also check whether the system is on Arpanet... all > by hand. > It would be nice to have this done automatically - IF I could tell the > mailer, "no, please don't send it that way - it bounced the last time." You know, there's an elegant solution to this sort of problem, exemplified by the way that Prolog resolves things. What is needed is a user agent that will first try what it thinks is a "best" path, and then, when that fails, can be told "try again, with the next-best path". This could be repeated until a good path is found, which could then be made the "best" path for the next time. It might be a good idea if the "try again" command could accept a parameter, which would be advise from the user about a path (fragment) to include (or reject) in generating the next path. This would be a simply way for a user to select for/against a given site or link. It's not clear that this should be heavily automated; it could easily end up with a message bouncing around the net for years looking for a path. You'd probably want to tell the user about each failure, and hold the failed mail until told what to do with it. Just a few thoughts; let me know what's wrong with them. (;-) -- John Chambers <{adelie,ima,maynard}!minya!{jc,root}> (617/484-6393)
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (10/12/87)
In article <279@minya.UUCP> jc@minya.UUCP (jc) writes: [ Deleted quotation from someone describing their personal algorithm for sending mail ... i.e. Look at the address and determine where the site is, and re-write the address appropriately. All by hand. ] >You know, there's an elegant solution to this sort of problem, exemplified >by the way that Prolog resolves things. What is needed is a user agent >that will first try what it thinks is a "best" path, and then, when that >fails, can be told "try again, with the next-best path". This could be >repeated until a good path is found, which could then be made the "best" >path for the next time. hmmm ... how are you intending to test the path? You don't have the needed information on your machine. NOBODY does. The only information you have is the UUCP Project database, and that's gauranteed to be at least 1 to 2 months out of date. We can do this "try again until it works" algorithm of yours by hand right now. I do this quite often in fact (well, maybe a couple of times a month -- more often than I really want tho'). You send the mail, and if it bounces you forward the message through a different route. Obviously it's a good algorithm but I don't see the point of making it "automatic" like you suggest. -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- I thought that time was this neat invention that kept everything <---- from happening at once. Why doesn't this work in practice?
jc@minya.UUCP (John Chambers) (10/15/87)
In article <7461@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: > In article <279@minya.UUCP> jc@minya.UUCP (jc) writes: > [ Deleted quotation from someone describing their personal > algorithm for sending mail ... i.e. Look at the address > and determine where the site is, and re-write the address > appropriately. All by hand. ] > [ Deleted rephrasing of Prolog resolution applied to mail paths] > > hmmm ... how are you intending to test the path? Easy send it; if it bounces, that's a failure to resolve that path. > You don't have the needed information on your machine. NOBODY does. > The only information you have is the UUCP Project database, and that's > gauranteed to be at least 1 to 2 months out of date. Nonsense. I have much better info than that. My mailer extracts the paths from all incoming mail and puts it (with a timestamp) into the database. I thus have good info on good paths to those people who have sent me mail lately. This is at worst the same data as is used by the mailers; it is usually better. > Obviously it's a good algorithm but I don't see the point of making > it "automatic" like you suggest. Only because I get tired of doing something by hand when it could be done better by a computer. That's why we buy the little beasts, after all. Anyhow, characterizing the Prolog algorithm as "try it again until it works" is a bit inaccurate. Hunting around at random is quite a bit different from a systematic search through a list sorted according to recent successes. The current proposals for intelligent forwarders strike me as being basically an uncoordinated random walk. This will work, most of the time, and the mathematics of it all is over a century old. But there are much better algorithms known. The Prolog approach has the distinct advantage of being implementable on the originating machine. But it does require that the sender be able to dictate the path, and that other mailers not try to "improve" it. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (10/16/87)
In article <287@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >In article <7461@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >> hmmm ... how are you intending to test the path? >Easy send it; if it bounces, that's a failure to resolve that path. ok, I understood that to begin with ... but the point I wanted to make and apparently didn't, was that this bounce-try-another-path approach is expensive. >> You don't have the needed information on your machine. NOBODY does. >> The only information you have is the UUCP Project database, and that's >> gauranteed to be at least 1 to 2 months out of date. >Nonsense. I have much better info than that. My mailer extracts the >paths from all incoming mail and puts it (with a timestamp) into the >database. I thus have good info on good paths to those people who >have sent me mail lately. This is at worst the same data as is used >by the mailers; it is usually better. You must be on a well connected site. hmmm ... that's an interesting approach, just don't use Path: information from news headers. Too bad I don't have the time to try implementing such a thing. Have you thought about packaging up an rmail (or description of how to muck up an rmail) which records this information into a database, and distributing via a sources group? -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- I thought that time was this neat invention that kept everything <---- from happening at once. Why doesn't this work in practice?
ambar@athena.mit.edu (Jean Marie Diaz) (10/19/87)
In article <287@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > >Nonsense. I have much better info than that. My mailer extracts the >paths from all incoming mail and puts it (with a timestamp) into the >database. I thus have good info on good paths to those people who >have sent me mail lately. This is at worst the same data as is used >by the mailers; it is usually better. Er, no. It is never wise to assume that a mail path works both ways. An example I saw recently: someone was sending mail from Tektronix to MIT using the path fragment ..!allegra!eddie!athena!user. It was their dumb luck that allegra realized that "eddie" was the same machine as mit-eddie (aka eddie.mit.edu), AND that eddie would resolve "athena" as athena.mit.edu (which is mit-athena in the uucp world). How did I trip over this one? The recipient was trying to reverse that path and send along it. Oops. Didn't work. (mit-athena was looking for the uucp machine eddie, and losing.) Don't try this one at home... AMBAR {backbones}!mit-eddie!ambar ambar@eddie.mit.edu
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (10/19/87)
In article <287@minya.UUCP> jc@minya.UUCP (John Chambers) writes: |In article <7461@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: ... |Easy send it; if it bounces, that's a failure to resolve that path. | |> You don't have the needed information on your machine. NOBODY does. |> The only information you have is the UUCP Project database, and that's |> gauranteed to be at least 1 to 2 months out of date. | |Nonsense. I have much better info than that. My mailer extracts the |paths from all incoming mail and puts it (with a timestamp) into the |database. I thus have good info on good paths to those people who |have sent me mail lately. This is at worst the same data as is used |by the mailers; it is usually better. Excuse me, but that's not always the case. Things like the net map are smart enough to understand that all paths are not bidirectional, or at least not equal in cost in both directions. Your reversal of the incoming path may produce an inefficient or inoperative path. Two real examples: The machine sixwed3 connects to machine benway by calling at any time. The pathalias cost is DIRECT. The benway machine never calls sixwed3, and only passes mail back when called. Mail may be rejected after three days. The pathalias cost for the reverse link is POLLED. There is a better way via two hops, DEDICATED and DIRECT when reach the sixwed3 machine. The machine sixhub connects to sixwbn in a nonstandard way, and passes all mail to it compressed and batched late at night. The pathalias cost is DAILY+LOW. Mail coming back is returned on a weekly basis, rather than daily. The cost is WEEKLY+LOW. Hopefully this has demonstrated that paths should not be teated as bidirectional. There are a number of other examples which I could cite, having to do with backbone machines connected to one-off backbone machines. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jc@minya.UUCP (10/22/87)
> >Nonsense. I have much better info than that. My mailer extracts the > >paths from all incoming mail and puts it (with a timestamp) into the > >database. I thus have good info on good paths to those people who > >have sent me mail lately. This is at worst the same data as is used > >by the mailers; it is usually better. > > Er, no. It is never wise to assume that a mail path works both ways. > An example I saw recently: someone was sending mail from Tektronix to > MIT using the path fragment ..!allegra!eddie!athena!user. It was their > dumb luck that allegra realized that "eddie" was the same machine as > mit-eddie (aka eddie.mit.edu), AND that eddie would resolve "athena" as > athena.mit.edu (which is mit-athena in the uucp world). > Er, I hear what you're saying, but my experience is otherwise. It's true that some links don't work in both directions equally well. From here, I can get mail to my neighbors within minutes; they must wait for my call to deliver mail here. This is fairly common, but it doesn't interfere with reversing a path. Some links are truly one-directional. In such cases, a path-reversal simply won't work, unless there's an intelligent forwarder on this side of the bad link. The above example falls into this class, but in a truly original way. In effect, the link has been made one-way by having one of the machines lie about its name in the path. This is truly perverse! Despite the efforts of programmers and administrators to make life difficult, the fact is that in the current email network, path reversal is still the most effective way to respond. I have three neighbors with fairly intelligent forwarders, and when I submit mail with only "To: target!user" or "To: user@target", the chance of it being delivered is around 40%. When I send it through the same hosts with a reversed path, the success rate is around 90%. It would be better, but a fair number of the full paths are subverted and redirected along bogus paths by some "intelligent" forwarder along the path. Thus, all four of my neighbors talk to harvard; if the reverse path goes there, their mailer rewrites it, and is wrong about as often as it is right. If all mailers were willing to accept pure bang paths and not question them, I claim that path reversal would succeed in well over 99% of the cases. It's true that a reversed path will fail some percentage of the time. But replacing a method that fails 1% of the time with one that fails 60% of the time (at this site) doesn't seem to me to be much of a win. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
daveb@geac.UUCP (10/23/87)
||In article <7461@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: ||Nonsense. I have much better info than that. My mailer extracts the ||paths from all incoming mail and puts it (with a timestamp) into the ||database. I thus have good info on good paths to those people who ||have sent me mail lately. This is at worst the same data as is used ||by the mailers; it is usually better. In article <7651@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: |Excuse me, but that's not always the case. Things like the net map are |smart enough to understand that all paths are not bidirectional, or at |least not equal in cost in both directions. Your reversal of the |incoming path may produce an inefficient or inoperative path. Sounds like you need to have a path database and update routes known to be bidirectional on the basis of usage. Not an unreasonable thing for a prolong (oops, prolog) program to do. Add another rule! -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.