brant@linc.cis.upenn.edu (Brant Cheikes) (08/26/88)
I've been following the "dynamic vs. passive" rerouting debate, and one concern that I haven't seen adequately addressed by those opposing dynamic routing is: who has the right to determine how a given machine's resources are used? One person's rule tells us that machines should respect explicit bang paths, only rerouting when the next hop is not a neighbor. The effect of this rule for a given host may be higher phone bills. Suppose machine A has a cheap link to B and an expensive link to C. If mail comes to A, with next-hop listed as C, and A can determine that link B could be used instead (dynamic routing), then doesn't A have the right to change the route? Or must A use the more expensive route it was given, just because someone else decided it was "better" BY THEIR DEFINITION. My question for those who would abolish dynamic routing, is: do you assume the right to dictate how my machine's resources will be used? When arguing this point remember that there are still many sites that do not use smart mailers, that hand-generated paths are still commonplace, and that sites are allowed to maintain unpublished connectivity data. Though I have been bitten by dynamic routing on several occasions, I can see why some sites (especially big ones) may consider it necessary. -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science
lmb@vsi1.UUCP (Larry Blair) (08/26/88)
In article <4902@netnews.upenn.edu> brant@linc.cis.upenn.edu (Brant Cheikes) writes:
=One person's rule tells us that machines should respect explicit bang
=paths, only rerouting when the next hop is not a neighbor. The effect
=of this rule for a given host may be higher phone bills. Suppose
=machine A has a cheap link to B and an expensive link to C. If mail
=comes to A, with next-hop listed as C, and A can determine that link B
=could be used instead (dynamic routing), then doesn't A have the right
=to change the route? Or must A use the more expensive route it was
=given, just because someone else decided it was "better" BY THEIR
=DEFINITION.
You've completely missed the point. If I give your site a path b!c!user,
I don't care how you get it to b. If you have a cheaper path to b than
a direct call, send it that way. What I care about is when you send it
to a site that you think is c. Only b knows who their c is.jbuck@epimass.EPI.COM (Joe Buck) (08/26/88)
In article <4902@netnews.upenn.edu> brant@linc.cis.upenn.edu (Brant Cheikes) writes: >My question for those who would abolish dynamic routing, is: do you >assume the right to dictate how my machine's resources will be used? Not at all. You are free to bounce mail that attempts to use a path you'd rather that the public didn't use. Also, as we move more and more to automatically generated routes, you can tune your map entry to steer usage away from expensive links. If we ever get to a point where large numbers of sites install active rerouters, we'll start to see things like mail loops, when two sites disagree as to what the best path is. A--B--D--E \ / C---- Here, B!D is an expensive link and the others are cheap. All links are two-way, same cost either way. In the above picture, assume B's database says the cheapest path to E is A!C!E, and A also believes the path is C!E. Now, site C announces it's going down for a few days. Site A changes its data base to take site C out of the map, so the best path to E is now B!D!E. Both A and B are running active rerouters. Somebody on A mails to user@E. What happens? A and B bounce the message back and forth forever, or until somebody's "too many hops" alarm goes off. We don't see much of this these days because only a small number of sites do rerouting. If it ever becomes common the network is wrecked, because of the very large number of possible loops. Now maybe site A justifies aggressive rerouting because A's manager, Mel Cheerful :-), believes his map data is the best in the world and anyone who specifies a different path is wrong. B's admin, Brant Chuckles :-), believes that the B!D link is expensive, and would rather have A handle all mail, but hasn't changed his map entry to cause this, but justifies rewriting paths based on a personal concept of property rights. The reasons don't matter; rerouting is just A Bad Thing. If B doesn't want to send other's mail through D, fine; bounce it, and if the connection is listed in the UUCP maps use the terminal node syntax so only mail terminating at B uses the link. -- - Joe Buck {uunet,ucbvax,pyramid,<smart-site>}!epimass.epi.com!jbuck jbuck@epimass.epi.com Old Arpa mailers: jbuck%epimass.epi.com@uunet.uu.net If you leave your fate in the hands of the gods, don't be surprised if they have a few grins at your expense. - Tom Robbins
vixie@decwrl.dec.com (Paul Vixie) (08/26/88)
Drat. I'm losing count, and more news is coming in.
In <4902@netnews.upenn.edu> brant@linc.cis.upenn.edu (Brant Cheikes) writes:
# My question for those who would abolish dynamic routing, is: do you
# assume the right to dictate how my machine's resources will be used?
No. Do you assume the right to tell me what I mean? That's the other side
of it. If something between !'s in a UUCP route does not have dots in it,
it has unambiguous meaning only to the entity named on the left of the
bounding !.
If you want people to use your resources in a certain way and in no other,
then do these things:
(a) publish your preferences in your UUCP map entry
(b) block mail along non-published exits from your system
except from privileged users / sites.
But please do not assume that you know more about what I mean than I do.
--
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 7013honey@umix.cc.umich.edu (Peter Honeyman) (08/26/88)
sure, beggars can't be choosers. no one has a right to demand that mel turn off agressive routing. but it remains a cherished privilege to help him see the error in his ways. (especially when he's so far from his keyboard.) peter
lear@NET.BIO.NET (Eliot Lear) (08/27/88)
All you are arguing for is a better method for map updates. I think that's a great idea... -- Eliot Lear [lear@net.bio.net]
lear@NET.BIO.NET (Eliot Lear) (08/27/88)
Paul, Could you please explain how I might block of some people's mail and let others' go, WITHOUT UUCP source? Also, when it comes to rights, whose should I give more weight: my right to control my resources or your right to pick your own path? -- Eliot Lear [lear@net.bio.net]
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/27/88)
In article <Aug.26.11.29.05.1988.18591@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: >Also, when it comes to rights, >whose should I give more weight: my right to control my resources or >your right to pick your own path? This whole business of rights is getting out of hand. With what goal in mind does a site agree to be a mail relay? Is that goal furthered or not if that site also does rerouting? These are the questions that are relevant. The statement "don't reroute" should be taken to mean "don't exercise your right to reroute". Which is a different kettle of fish. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
les@chinet.UUCP (Leslie Mikesell) (08/27/88)
In article <965@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: > >You've completely missed the point. If I give your site a path b!c!user, >I don't care how you get it to b. If you have a cheaper path to b than >a direct call, send it that way. What I care about is when you send it >to a site that you think is c. Only b knows who their c is. But if you have a map entry for b showing that it talks to your site and c, and you have a map entry for c showing that it talks to b, do you not then know that the c in your map entry is the same c that b is going to forward to? Of course it is possible to lie both in the map entries and in a uucp conversation, but then you deserve to lose... Les Mikesell
lear@NET.BIO.NET (Eliot Lear) (08/27/88)
In reference to Rahul Dhesi's posting (<3769@bsu-cs.UUCP>), I really do believe that I should start tagging long expirations on my messages. The answer to your question lies in my August 10 posting. I am forwarding it to Rahul. My goal is to improve connectivity as much as possible. I do that by exercising my right to reroute. You can read my August 10 posting for further information. -- Eliot Lear [lear@net.bio.net]
lmb@vsi1.UUCP (Larry Blair) (08/27/88)
In article <6392@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: =In article <965@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: => =>You've completely missed the point. If I give your site a path b!c!user, =>I don't care how you get it to b. If you have a cheaper path to b than =>a direct call, send it that way. What I care about is when you send it =>to a site that you think is c. Only b knows who their c is. = =But if you have a map entry for b showing that it talks to your site =and c, and you have a map entry for c showing that it talks to b, do =you not then know that the c in your map entry is the same c that =b is going to forward to? Of course it is possible to lie both in the =map entries and in a uucp conversation, but then you deserve to lose... I'll accept your logic. If b publishes its connect to c, it is acceptable to assume that b!c means b!c.UUCP. This, of course, has nothing to do with the rerouting that smail can be made to perform. -- Larry Blair ames!vsi1!lmb
kre@munnari.oz (Robert Elz) (08/27/88)
In article <Aug.26.11.29.05.1988.18591@NET.BIO.NET>, lear@NET.BIO.NET (Eliot Lear) writes: > Could you please explain how I might block of some people's mail and > let others' go, WITHOUT UUCP source? This is trivial, you do it the same way that all of the mailer (MTA) enhancements are made. You create new process that replaces rmail. When you've done whatever you want to with the mail (and you still want to send it), you exec the process that used to be called rmail. kre
cik@l.cc.purdue.edu (Herman Rubin) (08/27/88)
In article <Aug.26.20.28.38.1988.24988@NET.BIO.NET>, lear@NET.BIO.NET (Eliot Lear) writes: > My goal is to improve connectivity as much as possible. I do that by > exercising my right to reroute. You can read my August 10 posting for > further information. Exercising your right to reroute should give you the responsibility for correcting delivery failures due to rerouting. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
zeeff@b-tech.UUCP (Jon Zeeff) (08/27/88)
In article <Aug.26.20.28.38.1988.24988@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: > >My goal is to improve connectivity as much as possible. I do that by >exercising my right to reroute. Usenet depends heavily on sites being reasonable and not messing things up for other sites. If you are going to actively reroute, please be courteous and mark all your links as DEAD, saving everyone else alot of effort. I'd also encourage everyone connected to a active rerouter to mark that link as DEAD. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
vixie@decwrl.dec.com (Paul Vixie) (08/28/88)
Sometime back, Eliot Lear said: # My goal is to improve connectivity as much as possible. I do that by # exercising my right to reroute. I don't remember seeing any explaination of this "right" -- on what basis is it claimed to exist? And as for "rerouting" -- if you mean what I think you mean, no such route can exist. I think I'd like to see a definition and a validation of the right you claim to have. More recently, Jon Zeeff said: # I'd also encourage everyone connected to a active rerouter to mark # that link as DEAD. I have an even better idea -- everyone on the net should mark all known active rerouters as DEAD. That will save _everyone_ a lot of trouble. Remember that once your message hits an active rerouter, it has a good chance of winding up in the bit bucket after some poor postmaster gets it dumped in his lap N hops later, and he can no longer figure out where it was header or why it came to her. [Hey, Geoff, check out the new .sig:] -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
lmb@vsi1.UUCP (Larry Blair) (08/28/88)
In article <96@volition.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >I have an even better idea -- everyone on the net should mark all known >active rerouters as DEAD. That will save _everyone_ a lot of trouble. I made the suggestion many moons ago that the maps should indicate what kind of routing (i.e. active, passive, none) that a site does. I still think its a good idea, but I doubt that the powers that be would like it because it would make it too easy to avoid their sites. -- Larry Blair ames!vsi1!lmb
bill@carpet.WLK.COM (Bill Kennedy) (08/28/88)
In article <898@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <Aug.26.20.28.38.1988.24988@NET.BIO.NET>, lear@NET.BIO.NET (Eliot Lear) writes: > >> My goal is to improve connectivity as much as possible. I do that by >> exercising my right to reroute. You can read my August 10 posting for >> further information. > >Exercising your right to reroute should give you the responsibility for >correcting delivery failures due to rerouting. I want to straighten just one hair here. I have been one of the most vocal criticizers of rutgers in one of the earlier incarnations of the current war. Both of these folks are right from their own point of view. The log I'd like to toss onto the current fire is something that Mel Pleasant pointed out to me when I was ragging him about rerouting perfectly good paths. A site's published map is, by definition, the way that site chooses to be advertised, i.e. the way the local folks want things to move. I get a bit jumpy about routing something through sitea!uunet, since uunet is pay-fer, But if sitea has uunet (DIRECT+HIGH) I must ASSume that they encourage that path, so I use it. My site has (DEMAND) connections that are published as (EVENING) in order to encourage traffic to flow another way. It's my nickel and I'll rule on how it's spent. While rutgers' rerouting willy-nilly is a nuisance and a frustration, it's about the only site on the net who can claim to have the most up-to-date copy of the sites' wishes. If deliveries fail because of re-routing that's not rutgers' fault, BY DEFINITION, rutgers is correct. Should they take responsibility for some site having an umpteen year old map? I think not. As I zip up my asbestos suit, I suggest that we put pressure on our neighbors to keep their map up-to-date. As a matter of routine ssbn exchanges maps with its neighbors, public and private. What gets used in ssbn's pathalias run? The private ones, of course :-) Since rutgers routes by the public maps my mail goes through Turkey Jaw East Dakota. Who's fault is that? My site talks to rutgers at least once a day but the published map suggests that Turkey Jaw is a better route and rutgers uses it. Should I make them accountable for that? -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill
gunnar@hafro.is (Gunnar Stefansson) (08/28/88)
From article <898@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin): > In article <Aug.26.20.28.38.1988.24988@NET.BIO.NET>, lear@NET.BIO.NET (Eliot Lear) writes: > >> My goal is to improve connectivity as much as possible. I do that by >> exercising my right to reroute. You can read my August 10 posting for >> further information. > > Exercising your right to reroute should give you the responsibility for > correcting delivery failures due to rerouting. Sorry, Herman - and most of you, but you really have got it wrong. It should be a fellony to post incorrect map data which causes mail to bounce. When map data is correct, there is never any need at all for the user to do routing, and as you may have noticed, these bang paths are among the most difficult to teach new users. Rerouting is really only needed when one gets ridiculous paths, but that does tend to be most of the time at the backbones. Also, there is no way to justify the extra cost incurred when replies to news articles go all over the world before reaching the destination in the same state. Installing smail and either using an up-to-date map database or getting access to a good smart-host means that the users never have to know a route, ever. Errors "due to rerouting" are not the problem. The problem is site administrators who allocate names without checking for uniqueness, administrators who allow sites to hook up without asking them to register in the maps and administrators who don't install a domain-based mailer, such as sendmail or smail. These are the culprits who are costing us money. A case in point : Some silly administrator told a user that the path to Iceland from California went through kddlabs. The user promptly advertised this to all his friends. Sorry folks, but the route to California from Iceland does not go via Japan. Do you guys really want me to pay for those phone bills. Come on, don't be ridiculous. When I reroute, that is simply to see to it that things work as well as possible. If an error occurs, that is due to a map entry being incorrect and that is where the problem should be corrected. Remember : humans should not have to do jobs like routing, which computers can do much better. Gunnar
dave@onfcanim.UUCP (Dave Martindale) (08/29/88)
In article <Aug.26.20.28.38.1988.24988@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: > >My goal is to improve connectivity as much as possible. I do that by >exercising my right to reroute. You can read my August 10 posting for >further information. It is my impression that smail, in its most conservative configuration, does the following with mail addressed to a!b!c!d!user: (1) If we talk to "a", send it to a - no rewriting at all. (2) If we don't talk to a, try to find a route to "a" using the USENET maps (3) If we can't find a route to "a" at all, try finding a route to other sites in the path, starting at "d" and working leftward. Note that this does "improve connectivity" as much as possible, in that it makes it seem that you talk to almost everybody. It may not always generate the shortest path to anybody, but it has the advantage that it never messes up a route that is already OK - it intervenes only when the alternative would be to reject the mail. The smail installation documents also tell you how to set things up so that you skip from (1) to (3) without trying (2). This still has the property of leaving alone mail that is correctly routed at the source, while usually picking "better" paths for mail that would otherwise fail. It is also possible to configure smail so that it always does (3), on every piece of mail, without trying (1). However, given the other two choices available, and given that omitting (1) causes problems for some people and may also cause routing loops, I don't understand why people configure smail this way. Dave Martindale
wisner@killer.DALLAS.TX.US (Bill Wisner) (08/29/88)
In article <15923@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: >It is my impression that smail, in its most conservative configuration, >does the following with mail addressed to a!b!c!d!user: [...] > (3) If we can't find a route to "a" at all, try finding a > route to other sites in the path, starting at "d" and > working leftward. No. The real action 3 is "if a smart host is defined give the mail to them. If not, bounce it." Aggressive rerouting is a seperate option and, if defined, is performed before your (1). In smail 3.0 (which has no aggressive routing!) the order is: (1) If you're BSD, check if the destination is an Internet address like [10.1.7.9]. (2) If you're BSD, check the nameservers or host table for the destination machine. (3) Check for a route in the paths file. (4) See if destination machine is listed by "uuname" (5) If a smart host is defined, give it to them. If not, bounce it. And before anyone asks, smail 3.0 is still alpha testing (it's at Smail3.1.7.2 right now).
tron@amdahl.uts.amdahl.com (Ronald S. Karr) (08/30/88)
In article <6392@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: >But if you have a map entry for b showing that it talks to your site >and c, and you have a map entry for c showing that it talks to b, do >you not then know that the c in your map entry is the same c that >b is going to forward to? Of course it is possible to lie both in the >map entries and in a uucp conversation, but then you deserve to lose... In this specific case, you probably know that the two c's are the same. Now if you can get this information into your mailer then you are doing something that is a substantial improvement over the current state-of- the-art in active rerouting. Current mailers do not look at map data, they look at path data produced from this map data. A reasonable implementation of your strategy would require the mailer to step through the map data and find an optimal solution for each path. This is very expensive (in CPU and disk) relative to the present solution where pathalias produces an "optimal" solution for each host. I suspect there are special cases, though, that are not as expensive. Although your strategy would be a big improvement, that doesn't necessarily make it correct. -- 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]
honey@umix.cc.umich.edu (Peter Honeyman) (08/30/88)
hit the books, mr. tron. see "a parser for electronic mail addresses" by me and pat parseghian, jan '85 usenix, or slightly revised in jan '87 software--practice and experience. peter
rpw3@amdcad.AMD.COM (Rob Warnock) (08/31/88)
tron@amdahl.uts.amdahl.com (Ronald S. Karr) writes: +--------------- | In article <6392@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: | >But if you have a map entry for b showing that it talks to your site | >and c, and you have a map entry for c showing that it talks to b, do | >you not then know that the c in your map entry is the same c that | >b is going to forward to? | In this specific case, you probably know that the two c's are the same. Now | if you can get this information into your mailer then you are doing something | that is a substantial improvement over the current state-of-the-art... | A reasonable implementation of your strategy would require the mailer | to step through the map data and find an optimal solution for each path. | This is very expensive (in CPU and disk)... +--------------- There is an intermediate strategy that does not cost very much, is completely correct, *and* which would trim paths a lot if we all did it. (Peter Honeyman and I discussed this in the halls way back at the SLC USENIX and agreed that it would work, but neither of us ever implemented it.) What you do is a bounded-depth tree walk starting at your site, and going out for some small path length "x" (say, 3 to 6), computing *left-prefix* paths using the map data. Whenever two completely known (in the sense of the connectivity being in the maps) left-prefixes go to the same site, you store a rule which says that it's o.k. to rewrite the poorer into the better (by whatever criteria -- usually path cost -- you prefer). You stop when you exceed depth "x" or when your rewrite table gets "too big". (The rewrite table can be searched with the same binary search smail uses for the "paths" file.) For example, if you talk to "a" and the map for "a" says he talks to "b" and the map for "b" says she talks to "c" and that's the *same* "c" you talk directly to, you can rewrite "a!b!c!..." to "c!..." (as suggested above). This is completely correct and safe, since you you are exploring a path anchored at yourself. You are *not* "reaching into" a UUCP path (e.g., starting at the right -- *UGH*) and pulling out a name without indeed knowing that that's the same host you talk to. For example, if your depth limit is 4, and you see the path "a!b!c!d!e!c!x!..." you may safely rewrite as "c!d!e!c!x!..." (assuming the maps as above), but you *MUST NOT* rewrite it as "c!x!..." since you did not actually prove that the two c's were the same. (Yes, I have seen cases where they were different.) Nor may you rerwrite "a!b!q!j!c!x!..." to "c!x!...", for the same reason: You didn't search out far enough to prove that that "c" is the one you talk to. So if you're so limited in what you can do, why bother? Because if everyone rewrote 2-3 hops out of an outrageous path (and the truly outrageous ones seem to wander 'round and 'round), it would become merely long. Yet no unregistered host need ever be "cut off", nor would any unregistered host ever become a black hole for a registered host's mail (nor vice-versa). The preprocessing should be much less than a full pathalias run, since you are basically just exploring "your neighborhood", and not the whole net. (You still need the pathalias output for routing domain names, or if you want to be somebody's "smart-host", that is, routing left-most non-direct- connect names.) Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
honey@umix.cc.umich.edu (Peter Honeyman) (08/31/88)
indeed, rob, your suggestion led to pathparse. (did i ever thank you? i'm sure i did.) furthermore, i did implement it. the paper describes the idea and the performance of pathparse. it turns out to be unnecessary to limit the depth. each additional host in the path incurs one more disk access. (i believe this is how dbm works, but i'm not positive.) building the database from the map files turns out to be a big pain -- an hour on a 750 -- so i no longer use pathparse, although i did for about a year. peter
dave@onfcanim.UUCP (Dave Martindale) (09/01/88)
In article <5345@killer.DALLAS.TX.US> wisner@killer.Dallas.TX.US (Bill Wisner) writes: > >No. The real action 3 is "if a smart host is defined give the mail to >them. If not, bounce it." Aggressive rerouting is a seperate option >and, if defined, is performed before your (1). I must disagree. The documentation implies that if routing to the first host fails, it will try "agressive rerouting" as a last chance before bouncing mail. Then, wondering if the documentation was right, I tried it. I sent mail to trash!watcgl!user, where "trash" does not exist but "watcgl" does. The mail was queued for watcgl!user, not bounced. And I have "#define ROUTING JUSTDOMAIN" in defs.h, not REROUTE.
robert@hemingway.WEITEK.COM (Robert Plamondon) (09/01/88)
In article <15979@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: > >I must disagree. The documentation implies that if routing to the >first host fails, it will try "agressive rerouting" as a last chance >before bouncing mail. One of the basic ideas of mail is that non-deliverable mail will bounce, so the sender will know that it doesn't arrive. Using aggressive re-routing both a) Increases the chance that the message will vanish without a trace b) Increases the chance that the message will be delivered to the wrong person. Both of these are things we want to avoid. The whole argument FOR aggressive rerouting is silly: Re-router: "Why are you complaining? I'm doing you a favor." Sender: "I'd rather avoid your site altogether than receive such favors." Maybe your largesse is best spent on something else. -- Robert -- Robert Plamondon robert@weitek.COM "No Toon can resist the old 'Shave and a Hair-Cut'"
phil@amdcad.AMD.COM (Phil Ngai) (09/03/88)
In article <715@hemingway.WEITEK.COM> robert@hemingway.WEITEK.COM (Robert Plamondon) writes:
<One of the basic ideas of mail is that non-deliverable mail will
<bounce, so the sender will know that it doesn't arrive. Using
<aggressive re-routing both
<
<a) Increases the chance that the message will vanish without a trace
<b) Increases the chance that the message will be delivered to the
<wrong person.
<
<Both of these are things we want to avoid.
I very strongly agree with this.
--
Why do Big-Endians number their bytes backwards from their bits?
I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.comdave@onfcanim.UUCP (Dave Martindale) (09/03/88)
I'm not sure why Robert is arguing with my postings - we seem to be on the same side, more or less. I was simply pointing out that smail 2.5, as delivered, in its most conservative configuration (which is the default) STILL does agressive re-routing if nothing else works. I hope this has been established as fact by now. Given that smail WILL use agressive re-routing as a last resort, I do not see why everyone does not let it try its more conservative, and more correct, routing methods first. I cannot understand why people configure smail to do agressive rerouting ALL the time, unless they really believe that delivering mail faster is more important than sending it to the correct place. Robert seems to be arguing that agressive rerouting should never be done at all, under any circumstances. I don't wish to argue about what smail should do, just what smail 2.5 currently does. There seemed to be some misunderstanding about the latter, and I was just trying to clear it up - not start a philosophical debate. Dave Martindale