argv%eureka@Sun.COM (Dan Heller) (07/13/89)
In article <330@capmkt.COM> brent@capmkt.COM (Brent Chapman) writes: > Part of the problem is that, despite the valiant and praise-worthy efforts > of the UUCP Mapping Project, there's still a lot of bullshit, incomplete, > and incorrect information in the maps. Just a quick question... what's the difference between a bullshit entry and an incomplete entry and an incorrect entry? The following paragraph summarizes what's been going on with this religious argument for years. > I don't think that routing is bad; I think that RErouting when the user has > given what he _though_ was a source-route is bad. If I send something to > a!b!c!d!user because I know that site e is going to be down all afternoon > for maintenance, and some so-called "smart" mailer at a reroutes this to > "a!e!d!user" because it "knows" that this is a better route, I'm going to > be _REAL_ pissed off... Fact is, if you see a!b!c!d!user, site "b" has -no idea- that the original sender had in mind -- was it originally sent as user@d.uucp or was it changed by host a? Unless someone comes up with a "law", anarchy will continue. Machines will continue to route, reroute, dump mail, or whatever.. There are good arguments both for and against rerouting mail. *soap box* The "law" in this case, comes in the form of an RFC. So just for the sake of discussion, let's say that the rfc had something in there that said, "If the header Reroute: exists, then the mail is not rerouted if it says 'NO'". If that were specified (and it has been suggested in the past), then everyone would know what to do... Now, I'm not suggesting that -that- be the answer, but I am suggesting that the "lawmakers" should figure out something as a standard so everyone can follow it. Even if it's not optimal, if everyone does the same thing, there will at least be consistency. Everyone hates sendmail (and sendmail.cf's), but everyone still uses it (ok, not everyone). The point is, that's what comes off the shelf, and 900 small companies that start up every year in the valley with their sun's and their uucp connections are not going to know a hell of a lot about what the "right thing to do" is. If the proposal was made for standardizing this stuff, then reputable companies who sell software like this off the shelf will be compelled to adhere to these standards. Or at least attempt to. dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.
lear@NET.BIO.NET (Eliot Lear) (07/13/89)
Dan, IN ALMOST EVERY CASE, given a path of a!b!c!d!e..., if I am `b', I can determine whether the `d' you mentioned is the `d' in the UUCP maps by checking to see if `c' claims that `d' is a neighbor. Eliot -- Eliot Lear [lear@net.bio.net]
woods@ncar.ucar.edu (Greg Woods) (07/13/89)
In article <Jul.12.11.35.53.1989.20053@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: >IN ALMOST EVERY CASE, given a path of a!b!c!d!e..., if I am `b', I can >determine whether the `d' you mentioned is the `d' in the UUCP maps by >checking to see if `c' claims that `d' is a neighbor. Yes, you COULD do this, but I am willing to bet that the vast majority of "rerouting" sites do not bother to do this. --Greg
argv%eureka@Sun.COM (Dan Heller) (07/13/89)
In article lear@NET.BIO.NET (Eliot Lear) writes: > IN ALMOST EVERY CASE, given a path of a!b!c!d!e..., if I am `b', I can > determine whether the `d' you mentioned is the `d' in the UUCP maps by > checking to see if `c' claims that `d' is a neighbor. I don't disbelieve you. I remain neutral on the issue of whether it is a good idea to reroute or not to. I have never -administered- a mail host, so everything I know about this stuff comes from you guys. However, I do remember one particular situation which merits comment. One day, a long time ago, amd had a local workstation that happened to name itself "island". amd talks to "sco". Someone at sco mailed me: amd!sun!island!argv The mail admin at amd rerouted mail and, as you can imagine, all my mail went to this guy's workstation and it bounced back. One could use this as an argument not to reroute, but I don't think so -- at the time, the "management" at island were ignorant about "usenet" and so on and they wanted "island" to be "unknown" to the world. Island talks (or has talked) via uucp to client machines that may or may not have been on the net. The management felt that if island were "registered", then people would figure out how to mail to a "sensitive" company and all hell would break lose. So, island remianed unregistered for a long time and our connection to the world was advertised as sun!island... The guy at amd could not be held responsible for the decision island made about registering "island." The point is, there are lots of companies who, whether they are aware of it or not, are not registered with a domain or in the uucp maps or whatever. This is more common than people seem to think. Also, what does one do about all the machines within a company. For example, at island, my workstation's name is "maui". It's a sun and runs your standard sendmail.cf. People from the outside get my mail and it reads ...sun!island!maui!argv. Altho island is now a registered uucp site, none of the workstations at island are. And they won't be; machines and machine names come and go like (fill in your own analogy) at island. At one time, I had spent long hours trying to figure out how to configure island's sendmail.cf to have it not mention the other machines at island and to have outgoing mail always say island!<user>. Replies from the outside worked just fine, but then we upgraded to SunOS 3.5 and my hack no longer worked, and I haven't looked into it since. I doubt that most of these companies who don't know squat about email are going to know much more than I did. What does one do about these situations? To me, it seems like the best thing to do is not reroute because chances are [%] that there are going to be addresses which route thru or are destined for hostnames which are not registered. Of course, fully qualified domain names are quite a diff- erent issue. [%] I don't venture to guess on the likely hood of "chances" since I don't have empirical evidence. dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.
lear@NET.BIO.NET (Eliot Lear) (07/14/89)
Dan, The case where my rerouting will fail is that where there is a ghost site such as maui listed in island's entry, and another registered maui. This is rare. In no case will the method I use attempt to optimize a path beyond a site that is not in the maps. In the case of sun!island!maui!you, I would optimize to island. Eliot -- Eliot Lear [lear@net.bio.net]
chip@ateng.com (Chip Salzenberg) (07/15/89)
According to lear@NET.BIO.NET (Eliot Lear): >IN ALMOST EVERY CASE, given a path of a!b!c!d!e..., if I am `b', I can >determine whether the `d' you mentioned is the `d' in the UUCP maps by >checking to see if `c' claims that `d' is a neighbor. I believe the operative word here is "almost." -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg | <chip@ateng.com> or <uunet!ateng!chip> A T Engineering | Me? Speak for my company? Surely you jest!