vixie@palo-alto.DEC.COM (Paul Vixie) (08/10/88)
I saw this today, and it occurs to be that we're bashing benefactors:
In article <1966@stpstn.UUCP> aad@stpstn.UUCP (Anthony A. Datri) writes:
# >Amen! Both rutgers and harvard are marked as "dead" in my local adjustments
# >file, which is automatically included by my pathalias wrapper script.
#
# I can echo the sentiment on harvard. Much of what I sent anywhere near
# them gets thrown to husc6 for some unknown reason, and as far as I can
# tell husc6's mailer doesn't even look at the address, it just bounces [...]
Sun, Rutgers, and Harvard are fairly well-connected sites that pass a lot of
mail without charging for it. Sometimes they do the "wrong" thing in
various details, where "wrong" seems to depend on who you ask, but these
facts remain:
1. network connectivity would be more chaotic without them
to act as collection points for local geographic areas;
2. they are doing it all for free, which is a burden on their
machines and on their administrators;
3. their machines and their administrators are forever on the
edge of overload;
4. those of us who explicitly route around them because of
supposed "wrongness" or "rudeness" are actually doing them
a small favor by removing some of their network load.
So, while I am one of those who rags on various sites for doing "wrong"
things, I still recognize that these sites are still essentially bene-
ficial to the network and that "their hearts are in the right place."
I'm deluged in mail and news articles arguing for and against the details
I've presented; lots of people agree with me; lots of people disagree.
I will try to respond cogently when I can pick the out the juicy stuff.
But in the mean time, I want to offer Sun, Rutgers, Harvard, and other
sites that are getting blasted this week a big
T H A N K Y O U
for all the GOOD things you do for all us ungrateful wretches.
Flame fest to resume tomorrow, same time, same news group :-).
--
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 7013ericb@athertn.Atherton.COM (Eric Black) (08/10/88)
In article <3746@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: >I saw this today, and it occurs to be that we're bashing benefactors: > [...] >But in the mean time, I want to offer Sun, Rutgers, Harvard, and other >sites that are getting blasted this week a big > > T H A N K Y O U > >for all the GOOD things you do for all us ungrateful wretches. Yes! And again, Yes! No matter how we complain about mail bouncing nowadays, think back to a few years ago... -- Eric Black "Garbage in, Gospel out" Atherton Technology, 1333 Bordeaux Dr., Sunnyvale, CA, 94089 UUCP: {sun,decwrl,hpda,pyramid}!athertn!ericb Domainist: ericb@Atherton.COM
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (08/13/88)
In article <3746@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: >Sun, Rutgers, and Harvard are fairly well-connected sites that pass a lot of >mail without charging for it. Sometimes they do the "wrong" thing in >various details, where "wrong" seems to depend on who you ask, but these >facts remain: > > 1. network connectivity would be more chaotic without them > to act as collection points for local geographic areas; I find this unlikely. There is still life after ihnp4... > 2. they are doing it all for free, which is a burden on their > machines and on their administrators; > 3. their machines and their administrators are forever on the > edge of overload; These are definately contributing factors to the problem. I too must say "thanks" to the sites that voluntarily handle large volumes of mail for other sites. I don't believe, though, that just because they do this free of charge, or out of the goodness of their hearts, that this gives them license to mess up headers or reroute perfectly valid paths. If one of the sources moderators (who are also "volunteers") were to start doing a lousy job, nobody would hesitate to raise hell over that... There are other sites on the net who handle a respectable volume of mail who manage to do things quite well without the need for rerouting or header munging. When's the last time you had mail bounce from pyramid? -- VE6BBM {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
gore@eecs.nwu.edu (Jacob Gore) (08/14/88)
/ comp.mail.uucp / allbery@ncoast.UUCP (Brandon S. Allbery) / Aug 12, 1988 /
>Domain-based mailers *cannot* route to unknown sites!
Huh? How can ANY mailer route to unknown sites? Where does "domain-based"
fit in?
Jacob Gore Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gorehoney@umix.cc.umich.edu (Peter Honeyman) (08/14/88)
Brandon S. Allbery writes: >(Note that the UUCP Project is the only >reason any Internet site can handle non-local UUCP addresses, so a big THANK >YOU! is also due to peter honeyman and Mark Horton!) for the record, i have never been part of "the uucp project." i'm not even sure what it is. but thanks anway. peter
les@chinet.chi.il.us (Leslie Mikesell) (08/15/88)
In article <3400004@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: >Huh? How can ANY mailer route to unknown sites? Where does "domain-based" >fit in? Routing is perhaps the wrong word here. Some mail transports require the end-point to be known. Using the bang routing notation, uucp only requires that each host on the path knows how to sent to the next site - beyond that is someone else's problem. That is, the "unknown site" can be unknown to everyone except the site immediately before it in the path. As to the active-rerouting debate that is going on here, the objection seems to be that often the site reached by parsing the path from the right side is not the same one that would be reached following left to right. Given the uucp map data that is being used for the re-routing, would it not be possible to determine (by common neighbors) if the new route is going to reach the same machine? Les Mikesell
allbery@ncoast.UUCP (Brandon S. Allbery) (08/16/88)
As quoted from <41@volition.dec.com> by vixie@decwrl.dec.com (Paul Vixie): +--------------- | In article <12212@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: | # We should require sites using the Internet for mail routing to become | # registered in at least the UUCP maps, so that *some* sites can find them. | | Well, you'd also have to require all uucp/internet gateways to run passive | rerouters. After all, "vixie" is listed in the maps, but "vixie!paul@Sun.COM" | is still bogus if Sun.COM cannot reach "vixie!". +--------------- I'd require *everyone* on the Internet to use passive routing. After all, the Internet was intended for this, and *not* for explicit routing. And the original network (former Arpanet) was using it long before we UUCP types got into it; we should conform to existing standards, no? If we want to use their network, we should play by their rules. ++Brandon (and YES, I'm working on getting ncoast registered!) -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
allbery@ncoast.UUCP (Brandon S. Allbery) (08/17/88)
As quoted from <3400004@eecs.nwu.edu> by gore@eecs.nwu.edu (Jacob Gore): +--------------- | / comp.mail.uucp / allbery@ncoast.UUCP (Brandon S. Allbery) / Aug 12, 1988 / | >Domain-based mailers *cannot* route to unknown sites! | | Huh? How can ANY mailer route to unknown sites? Where does "domain-based" | fit in? +--------------- I was speaking shorthand. What I meant was: as long as a UUCP mailer knows the *next* system in the path, it doesn't have to know the other systems. But domain-based (i.e. Internet non-UUCP) mailers do not use routing, so they must know the actual destination site! Thus, I can send to some site "foobar" that is unknown to ncoast's mailer if *I* know the path, but someone on CWRU20 (if it still exists; it was a CSNet host) can't without hiding the UUCP syntax from the domain-based mailer and sending the mail to a CSNet/UUCP relay site. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
allbery@ncoast.UUCP (Brandon S. Allbery) (08/17/88)
As quoted from <4337@umix.cc.umich.edu> by honey@umix.cc.umich.edu (Peter Honeyman): +--------------- | Brandon S. Allbery writes: | >(Note that the UUCP Project is the only | >reason any Internet site can handle non-local UUCP addresses, so a big THANK | >YOU! is also due to peter honeyman and Mark Horton!) | | for the record, i have never been part of "the uucp project." | i'm not even sure what it is. +--------------- I know you're not, but the UUCP Project is heavily dependent on a little program called pathalias.... ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/17/88)
In article <12246@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >But domain-based (i.e. Internet non-UUCP) mailers do not use routing, so >they must know the actual destination site! This restriction has always puzzled me. If you're sending mail to u@A.B.C.D.E, why should the server for E care about A? It ought to hand over the message to a server for D, and so on, until a server for the B domain gets it and figures out who A is. For the E server to find a shorter routing, or to send directly to A, is just an optimization that should be used when possible but not insisted upon. I think the Internet has it all wrong. But then again, I'm a UUCP user, what do I know? Can you imagine, the US Post Office returning mail undelivered because it hasn't heard of some little town in Yugoslavia, rather than simply handing over the letter to the Yugoslavian Post Office and letting it figure out where to deliver it? Postal addresses are domain-based too. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
honey@umix.cc.umich.edu (Peter Honeyman) (08/17/88)
rahul, you have a misconception about the domain name system. it provides name service, not mail forwarding service. given an address u@a.b.c.d.e, the server for e is consulted to provide the address of the name server for d.e, which is queried for the address of the server for c.d.e, and so on. eventually the name server for a.b.c.d.e is discovered and queried for mail exchanger (mx) or address info. with that in hand, the originator connects to the host specified, and delivers the message. usually, all of this happens in the blink of an eye. of course, it doesn't work like this in the uucp world, where nonexistant domains are commonplace. (e.g., i tried to send mail to someone at chinet.chi.il.us -- oops, no such domain.) peter
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/17/88)
Actually, the domain system is really just an addressing scheme and not
a name service. The name service that the Internet provides is a part
of the delivery mechanism. A UUCP link can also be part of the
delivery mechanism if the destination site is a UUCP site.
In any case, there's no need for a.b.c.d.e to be known to anybody
except b.c.d.e, except as an optimization.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesigore@eecs.nwu.edu (Jacob Gore) (08/18/88)
/ comp.mail.uucp / allbery@ncoast.UUCP (Brandon S. Allbery) / Aug 16, 1988 / >as long as a UUCP mailer knows >the *next* system in the path, it doesn't have to know the other systems. >But domain-based (i.e. Internet non-UUCP) mailers do not use routing, so >they must know the actual destination site! That's not correct. Explicit routing does exist within the RFC-822 world: @A,@B,...,@Y:user@Z The RFC requires all names in the route to be registered domains, but I doubt if any mailer pays any attention to this requirement. My machine just needs to know how to route to A, and then it's A's problem. Very much like UUCP paths with passive routing. >Thus, I can send to some site >"foobar" that is unknown to ncoast's mailer if *I* know the path, but >someone on CWRU20 (if it still exists; it was a CSNet host) can't without >hiding the UUCP syntax from the domain-based mailer and sending the mail to >a CSNet/UUCP relay site. gore 2> checkaddr -w @accuvax.nwu.edu:jacob@foobar @accuvax.nwu.edu:jacob@foobar: queueing for smtp-local: via 'accuvax.nwu.edu': '@accuvax.nwu.edu:jacob@foobar' OK gore 2> No problem. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore
jordan@zooks.ads.com (Jordan Hayes) (08/18/88)
Rahul Dhesi <dhesi@bsu-cs.UUCP> writes:
Actually, the domain system is really just an addressing scheme
and not a name service.
If you wanna be picky about it, it's not an addressing scheme, but
rather (as the name would imply -- "The Domain Naming System"), a
hierarchical *naming* system. It only specifies how to name things,
and an *example implementation* of how one might provide *name service*
using this naming scheme is outlined (with some random examples of
classes of "labels" that might be used, like hostnames, IP addresses,
etc. -- Hesiod uses the same naming system, but uses a superset of
these classes of labels)
The name service that the Internet provides is a part of the
delivery mechanism.
Not true. It is in fact very separate, since it's not just used for
mail, but general key -> value{,s} lookup ... the fact that SMTP as a
transport agent makes use of one lookup service over another is not
specified. Current *convention* is that SMTP mailers on the Internet
use DNS lookups, but there's no reason that they couldn't use something
else (since they had for some time used static host tables in whatever
OS-specific format they came in).
A UUCP link can also be part of the delivery mechanism if the
destination site is a UUCP site.
Hmmm. Now that you've begun to argue semantics, you've completely lost
me on your use of "UUCP link" and "delivery mechanism" ...
/jordanrsalz@bbn.com (Rich Salz) (08/19/88)
>Actually, the domain system is really just an addressing scheme and not >a name service. This is not true. It really is a very flexible naming service. Check out, e.g., what the MIT Athena people did -- a few hacks to bind, and presto! Naming services for printers, people, etc. >In any case, there's no need for a.b.c.d.e to be known to anybody >except b.c.d.e, except as an optimization. Not true. First, when do you stop the left-most removal? Your statement requires that there be a machine b.c.d.e; what about c.d.e and d.e and plain old e? Should someone who wants to reach me on my workstation, rsalz@fig.bbn.com, just send all their mail to the non-existant "com" machine? Second error, what's bad about the optimization? With caching, and proper data entries, the domain sytem is a powerful, effective distributed naming database. If foo.bar.com wants to ftp with zap.baz.edu, then those two machines -- if both are on the Internet -- should be talking directly, not going through bar.com and baz.edu. Especially when bar.com and baz.edu need not exist! Third error, which is implied in my previous paragraph: the name system is not just used for email, but for other things like TELNET and FTP... /rich$alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
allbery@ncoast.UUCP (Brandon S. Allbery) (08/22/88)
As quoted from <3400006@eecs.nwu.edu> by gore@eecs.nwu.edu (Jacob Gore): +--------------- | / comp.mail.uucp / allbery@ncoast.UUCP (Brandon S. Allbery) / Aug 16, 1988 / | >as long as a UUCP mailer knows | >the *next* system in the path, it doesn't have to know the other systems. | >But domain-based (i.e. Internet non-UUCP) mailers do not use routing, so | >they must know the actual destination site! | | That's not correct. Explicit routing does exist within the RFC-822 world: | | @A,@B,...,@Y:user@Z | | The RFC requires all names in the route to be registered domains, but I | doubt if any mailer pays any attention to this requirement. My machine | just needs to know how to route to A, and then it's A's problem. Very much | like UUCP paths with passive routing. +--------------- Some mailers do conform to it. And I *do* know about explicit RFC822 routing; but it is supposed to be a last resort, *not* used commonly! (Read your copy of RFC822.) +--------------- | >Thus, I can send to some site | >"foobar" that is unknown to ncoast's mailer if *I* know the path, but | >someone on CWRU20 (if it still exists; it was a CSNet host) can't without | >hiding the UUCP syntax from the domain-based mailer and sending the mail to | >a CSNet/UUCP relay site. | | gore 2> checkaddr -w @accuvax.nwu.edu:jacob@foobar | @accuvax.nwu.edu:jacob@foobar: | queueing for smtp-local: via 'accuvax.nwu.edu': '@accuvax.nwu.edu:jacob@foobar' | OK | gore 2> | | No problem. +--------------- I dropped a qualifier: it's a UUCP address (note my reference to a UUCP relay). Note also that some systems (including "invisible" passive-routed systems between CWRU20 and CSNet-Relay) may decide to look at the "!" before the "@" and proceed to botch the path. I'm not discussing sites known to the Internet nameservers; it's the ones that *aren't* known to them that cause the problems, directly ("host unknown") or indirectly (the munging at sun and rutgers). ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
jordan@zooks.ads.com (Jordan Hayes) (08/24/88)
Rahul Dhesi <dhesi@bsu-cs.UUCP> writes:
In any case, there's no need for a.b.c.d.e to be known to
anybody except b.c.d.e, except as an optimization.
One more misconception.
----- BEGIN whatyoureallymeanis
There is no need for a.b.c.d.e to be "known to" anybody (except as an
optimization) except for _the authority for the SOA which contains the
data for a.b.c.d.e_ ... this need not bear any resemblence to that
label. It may in fact be "known as" h.i.j.k ...
----- END whatyoureallymeanis
With the way things are defined (anybody wanna give this guy a set of
the relevant RFC's?), the above statement does not need to be made.
You may as well say "no one needs to know your name except he who gave
it to you, in the place where it's *defined*" ...
/jordandavid@ms.uky.edu (David Herron -- One of the vertebrae) (08/29/88)
In article <12212@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: ... >... Domain-based mailers *cannot* route to unknown sites! >This is the ultimate cause of the problems observed at various gateway >sites, either directly (sun) or indirectly (rutgers, trying to "cover up" >the side effects of sun's attempts at a fix). > >We should require sites using the Internet for mail routing to become >registered in at least the UUCP maps, so that *some* sites can find them. >Otherwise they land in the dead letter room, just like US mail replies. >There just isn't any way to do it otherwise, you can't teach a computer >clairvoyance or telepathy. eh? how is that supposed to improve anything? The maps as-is contain gateways to all the top-level domains, the unofficial domains, and to many second level domains. Thus, you could take out the .uky.edu gateway advertised as being at ukma, and someone on the UUCP network using smail (for instance) would send mail for ukcc.uky.edu to their nearest .edu gateway. Right now their smail would send it to ukma. In either case, ukcc.uky.edu is not announced in the UUCP maps (and likely never will be) yet some random person out in UUCP land knows how to get there -- sort of. Smail is a domain based mailer and can route to unknown hosts. We don't need to register each and every internet host in the UUCP maps in order to do this either. Sorry Brandon -- but I don't like seeing mis-information float around. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- Problem: how to get people to call ...; Solution: Completely reconfigure <---- your mail system then leave for a weeks vacation when 90% done.
david@ms.uky.edu (David Herron -- One of the vertebrae) (08/29/88)
In article <4381@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >of course, it doesn't work like this in the uucp world, where >nonexistant domains are commonplace. (e.g., i tried to send mail to >someone at chinet.chi.il.us -- oops, no such domain.) > > peter geeee ... peter honeyman behind the times ... will the world ever survive this catastrophe :-) the host.city.state.us system exists but is a fairly recent development. There were some application forms which floated through this newsgroup recently if you're interested. It seems to be a *good* *thing* and should make the world more manageable. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- Problem: how to get people to call ...; Solution: Completely reconfigure <---- your mail system then leave for a weeks vacation when 90% done.
allbery@ncoast.UUCP (Brandon S. Allbery) (09/14/88)
As quoted from <10185@s.ms.uky.edu> by david@ms.uky.edu (David Herron -- One of the vertebrae): +--------------- | In article <12212@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: | >We should require sites using the Internet for mail routing to become | >registered in at least the UUCP maps, so that *some* sites can find them. | >Otherwise they land in the dead letter room, just like US mail replies. | >There just isn't any way to do it otherwise, you can't teach a computer | >clairvoyance or telepathy. | | The maps as-is contain gateways to all the top-level domains, the | unofficial domains, and to many second level domains. Thus, you | could take out the .uky.edu gateway advertised as being at | ukma, and someone on the UUCP network using smail (for instance) | would send mail for ukcc.uky.edu to their nearest .edu gateway. | Right now their smail would send it to ukma. In either case, ukcc.uky.edu | is not announced in the UUCP maps (and likely never will be) yet | some random person out in UUCP land knows how to get there -- sort of. +--------------- I said *at least* the UUCP maps. *.uky.edu is an Internet domain, ergo the .EDU nameserver knows about it, so it's reachable. But what happens if you try to send mail to telo1000!bsa? telo1000 isn't in the maps (deliberately; it's unclear what will actually happen, it may have a different name when it's fully set up), and isn't in the Internet name- servers for any domain, so you'd bounce it. Now, if you sent to a more complete address (ncoast!telo1000!bsa) you could do it because ncoast knows about telo1000; but e.g. "sun!telo1000!bsa" would fail because "sun" doesn't know about it. +--------------- | Smail is a domain based mailer and can route to unknown hosts. +--------------- Iff they are either (1) local (i.e. in L.sys/Systems) or (2) in the maps. Smail can't help you find "telo1000" unless you're sending your mail from ncoast. +--------------- | We don't need to register each and every internet host in the UUCP | maps in order to do this either. +--------------- Aha! Your entire message is based on a misunderstanding! I said "AT LEAST" -- that does not mean that the UUCP maps must contain all systems, it means that the UUCP maps are the simplest way to become known to the Internet. Of course, you could do more work and/or shell out $150/year and get yourself listed in an Internet nameserver instead, but (as you said) this is ridiculous for all the UUPC-running DOS boxes, etc. out there. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc "Don't discount flying pigs before you have good air defense." -- jvh@clinet.FI
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (09/15/88)
In article <12546@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >Of course, you could do more work and/or shell out >$150/year and get yourself listed in an Internet nameserver instead, but >(as you said) this is ridiculous for all the UUPC-running DOS boxes, etc. >out there. Why is that? Nobody bitches about shelling out $150/yr to get a telephone number ... -- VE6BBM {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA