jordan@ucbarpa.berkeley.edu (Jordan Hayes) (04/21/86)
Larry McVoy <larry@geowhiz.UUCP> writes:
Colons: Is there some reason why these sites can't accept
the normal uucp sequence?
Most likely they aren't a uucp site ... berknet uses colons, and there are
other forms that use them as well ... if you run uucp, why should you
worry about it?
Atsigns: Why don't these sites register as normal uucp sites?
tsk tsk ... if you want to take the craziness out of the addressing
syntax of UUCP, then pathalias has no job to do and there is no need for
the maps -- get a grip -- these are not little convenience programs
that can be written without the advanced knowlege of whats out there ...
If you're trying to write some addressing software, consider all
the possibilities -- don't just clean up the maps, because then they
are of very little use.
I, myself, don't use the stuff, but lots of people (it may be argued
even that too many people) depend on the functionality of that software.
Remember, UUCP is the little guy on the block, and we all gotta play
fair ... if you're looking for genocide, you won't kill off the
atsign race ... we may starve you to death first
Although I notice you have an account on the arpanet out of wisc ...
Domains: This is just obnoxious. There exist routers which will
forward stuff from one domain to the next, lets not
clutter up the uucp maps with this garbage.
You must be a mathematician ... "there exists a solution, so were done!"
I remember high school when I could *use* things like
+ Proof by Inspection
"See! It works! Just plug in 17 and remove this expression..."
+ and Proof by distraction
"LOOK! THE QUEEN! (scamming takes place here ...)
domained addresses like the form foo!bar.baz.edu!mumble!joe are just as
valid as anything else -- if there are dots, and they don't mean
anything to you, you can justpass them along and be a good citizen,
right?
Berkeley is by far the worst offender with 272 out of
389 such names and they are just aliases for the uucp
names. Can't this stuff go someplace else?
Sorry, Berkeley doesn't run UUCP on it's internal ethernets (unlike
*some* University of California ... or maybe that's almost gone now,
right, Rich?), so the ucb* name is NOT a uucp name, just an easy way
to scam a unique name for sites like "topaz" which is pretty
popular these days ... see, wwe just tack on the ucb to make
"ucbtopaz" and then we're okay ... the mailers on campus are very
generous as to what they will accept for a machine name ...
See, but everyone on the net here has access to news via NNTP, so there
needs to be a way for the pigeons who use pathalias to get mail to these
people who don't happen to have an account on ucbvax, mostly for
news replies.
Some people believe in the philosophy of being liberal with what
they accept ... maybe you could learn something here.
By the way, just to clear up the present confusion about how to reach
internal Berkeley hosts, you can use the following syntax.
Example: user "joeblow" on machine "gadzooks" at Berkeley ...
UUCP: ...!ucbvax!ucbgadzooks!joeblow
ARPA: joeblow%gadzooks@Berkeley.EDU
As a matter of fact, you can even combine these to get a UUCP path of
UUCP: ...!ucbvax!gadzooks.Berkeley.EDU!joeblow
Summary: The uucp maps are for UUCP PATHS! Don't fill them with
domain aliases.
You'll be very lonely without the rest of the world. I wish you luck.
/jordan
(not *even* a signature line here!)mark@cbosgd.UUCP (Mark Horton) (04/22/86)
In article <404@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: >Colons: Is there some reason why these sites can't accept the normal > uucp sequence? If they are unix sites, there is no excuse, I > have a stub which will solve the problem in about 20 lines of > code. I'd be happy to pass it on. Colons generally are there because of Berknets or ACSnet, although I think Australia doesn't publish the ACSnet data on the UUCP map. Since Berknet went out when 4.2BSD came out, most sites running a Berknet are probably doing so for historical reasons (they don't have the resources to convert, as they are busy doing something else) and even a 20 line fix would be too much effort. Some of the publications may occur because the author doesn't understand the intent of the UUCP map - chances are that most posted Berknet sites really shouldn't be on the map at all. >Atsigns: Why don't these sites register as normal uucp sites? I see lots > of junk like ....!bigname_here!%s@little_name. Come on, what's > the problem? Of course, this is dangerous, and RFC976 specifies the safe way to use atsign semantics in bangs: ...!bitname_here!little_name.!%s Chances are most such places will convert once smail is posted. However, again, local names like little_name probably don't belong on the UUCP map. >Domains: This is just obnoxious. There exist routers which will forward > stuff from one domain to the next, lets not clutter up the uucp > maps with this garbage. Berkeley is by far the worst offender > with 272 out of 389 such names and they are just aliases for > the uucp names. Can't this stuff go someplace else? It's important to have domains in the map, but the intent is to decrease the size of the map by having only a single entry for each organization (or each major gateway into the organization.) Thus, Berkeley really only needs an entry for ucbvax, and maybe ucbopt. I agree that the huge entries like ucbvax has are not needed, and just contribute to the overall size of the map. >Summary: The uucp maps are for UUCP PATHS! Don't fill them with domain > aliases. Fill out the stupid maps & send them in. I think what you mean is that we only need info for ucbvax, but we need both ucbvax for UUCP, and Berkeley.EDU for domains. The simple entry ucbvax="Berkeley.EDU" ucbvax ihnp4(DAILY), seismo(DAILY), ... is enough, this tells us that to get to brahms.Berkeley.EDU one need only send to ucbvax!brahms.Berkeley.EDU!%s, without even storing an entry for brahms in the database. This is the whole point of domains, a small database is all you need. Anything ending in Berkeley.EDU can be sent to ucbvax for further forwarding. It's a bit unfair to pick on Berkeley here, since Erik Fair is aware of the problem and working on it. But others are beginning to pick up on this example, and it's bloating the map and causing more name collisions. So please, some guidelines: (a) Don't publish local nets. Put them in your path.local file for your local use, but don't put them in the published entry for the world. (b) As soon as you have an RFC976 compliant system in place, only publish one entry for your organization (two or three if you have that many gateways.) Arrange for that machine to forward all your mail to the proper place internally. (c) If you have small internal machines, please try to hide them. Ideally, your mail and news should appear to come from your gateway. (d) The UUCP map is for UUCP data. We aren't interested in BITNET, ARPANET, CSNET, etc. Just places that can be reached via the ! notation. If this includes other transports, fine. We put out one file (path.top) which lists the top level domains and how to get there. Mark Horton
avolio@decuac.UUCP (Frederick M. Avolio) (04/23/86)
jordan@ucbarpa.berkeley.edu (Jordan Hayes) writes: > By the way, just to clear up the present confusion about how to reach > internal Berkeley hosts, you can use the following syntax. > Example: user "joeblow" on machine "gadzooks" at Berkeley ... > UUCP: ...!ucbvax!ucbgadzooks!joeblow > ARPA: joeblow%gadzooks@Berkeley.EDU > As a matter of fact, you can even combine these to get a UUCP path of > UUCP: ...!ucbvax!gadzooks.Berkeley.EDU!joeblow gadzooks.Berkeley.EDU works from UUCP but *not* from the ARPA Internet??? Shouldn't the ARPA address be similar to the UUCP as in joeblow@gadzooks.Berkeley.EDU ? What's with the %? (I know why it is there and what it means. But why aren't things changing for the better?) -- Fred @ DEC Ultrix Applications Center INET: avolio@decuac.DEC.COM UUCP: {decvax,seismo,cbosgd}!decuac!avolio
fair@styx.UUCP (Erik E. Fair) (04/25/86)
In article <899@decuac.UUCP> avolio@decuac.UUCP writes: > >gadzooks.Berkeley.EDU works from UUCP but *not* from the ARPA >Internet??? Shouldn't the ARPA address be similar to the UUCP as in > > joeblow@gadzooks.Berkeley.EDU ? > >What's with the %? (I know why it is there and what it means. But why >aren't things changing for the better?) OK, time for a quick course in ``Reality, Internet Style.'' In bang land, when you use ucbvax!foo.berkeley.edu!luser, who's doing the interpretation of that funny host name with the dots? Why, ucbvax of course. Now, in internet land, when you use luser@foo.berkeley.edu, who does the interpretation of that dotted name? The host you're on. Ooops... There are two ways to deal with a host name on the internet: 1. look it up in your copy of hosts.txt (maintained centrally by the Network Information Center (NIC), which you FTP from SRI-NIC.ARPA when it changes) 2. ask your friendly, local domain server about it. Why are there two methods, when one would do? Well, we're in process of converting from method one to method two. Or rather, some of us are. You see, there are two major communities in the ARPA Internet: The ARPANET and the MILNET. The ARPANET is a research network where researchers play with networking ideas and are allowed (within reason) to play hob with network configuration, protocols, traffic, etc. The MILNET is a production computer network (i.e. high reliability, availability, stable, etc.). Those of us on ARPANET are required to convert to domains. Those of us on MILNET are expected to watch, and follow the ARPAnauts later on when the Defense Data Network Program Management Office (DDN-PMO) specifies a schedule for conversion. What's this domain stuff anyway? Well, there are several thousand hosts on the ARPA Internet, and it's getting to be a pain for the NIC to maintain a master host table. The idea behind domains is that every organization maintains its own section of the host table, and tells the rest of the world about it (upon request) through a `domain server.' Neat huh? A giant distributed database. Thank DARPA that we have 56Kbaud trunk lines... But those MILNET people aren't doing that yet... and what about all those hosts that Berkeley, and MIT, and CMU, and Stanford, and ... that haven't been registered with the NIC in the master host table? We have the technology, we can reply: `%' (which is to say, we hide unregistered hosts in the `local-part,' giving: luser%unreg-host@berkeley.edu that way those sites that don't use the domain server yet (and therefore can't ask berkeley about them) have never heard of this funny host (but have heard of Berkeley.edu) can look up the host name to the left of the @ in the hosts.txt file and get mail there). That percent hack has to stay until either: 1. ALL hosts on the internet are registered in the NIC host table. 2. we *all* convert to domainism. Number 1 is unlikely to happen, since the NIC is already overloaded. Number 2 will happen, eventually, if domainism isn't a total flop. So far, it works OK. It should be noted that domainism is a very fundamental change from the old ways of doing things, and that they're still working out the bugs. hope this was clear, Erik E. Fair styx!fair fair@lll-tis-b.arpa ucbvax!fair fair@ucbarpa.berkeley.edu
brian@sdcsvax.UUCP (Brian Kantor) (04/25/86)
Gatewaying between networks is a bag of worms - especially when the networks have completely different semantics for mail addresses - not just syntax differences, but the addresses MEAN DIFFERENT THINGS! For example: a simple internet address (e.g., brian@sdcsvax.ucsd.edu) is just that: the destination (or at least the intermediate destination) of a mail message. No route is necessarily implied. But a uucp address (e.g., ucbvax!sdcsvax!brian) is also a ROUTE to the destination. When we at UCSD move a message from uucp to the internet, we do so by rewriting the from address into the local-part of the address and adding us as the domain part. So a return address of 'bang!crash!jam' will appear in the From: line of the message on the internet as 'bang!crash!jam@sdcsvax.ucsd.edu'. The semantics are preserved if all the internet hosts obey RFC822, which essentially says to evaluate and satisfy the domain part (right of the @) before doing anything with the local part (left of the @). In the other direction, from the internet to uucp, we translate the internet domain address to a banged form, and prepend our host name in the normal uucp manner. So mail heading out to a uucp host from an internet host will have a nice uucp-readable return address, but one that preserves the semantics of the internet address. Most uucp mailers will not care, but a few with 'smart routers' can look ahead down the address and optimize - especially if they themselves are on the internet. So we'll put an address out on uucp that looks like this: if the original message came from the internet with a From: line of wombat@seismo.css.gov, we'll send out the message via uucp with a return address line of "From seismo.css.gov!wombat remote from sdcsvax" and "From: sdcsvax!seismo.css.gov!wombat". And we understand those addresses when we get them back from uucp hosts. Additionally, to support a kludge, we take addresses of the form "...sdcsvax!user@host" and drop the "...sdcsvax!" part, to yield "user@host". This fixes up stuff from uucp hosts that goes to the internet. Ah, but what about our hidden local hosts (a hundred or so of them)? Well, on the internet, we hide them in the local part of the address - as "user%hiddenhost@sdcsvax.ucsd.edu". On uucp, its not possible to hide it, but we have to make sure that the outgoing name doesn't conflict, so we use our full domain name for the host; this gives a uucp return address like "sdcsvax!hiddenhost.ucsd.edu!user". Since no uucp map nor table is going to have an entry for "hiddenhost.ucsd.edu" unless WE advertise it, this works well. We could even have a local host called "ihnp4", although that would be really stupid to do. It would be ok, though, as the return address on mail from our local stupidly-named host would then be "sdcsvax!ihnp4.ucsd.edu!stupid", which is legitimate. We won't do that particular one, but how many host names on campus MIGHT conflict nationwide if we didn't use this scheme? This scheme isn't perfect. It fails miserably on malformed addresses, on RFC822 explicit-route addresses, and the like. We don't see many of those, so I've not taken the time to do it "right". Yet. So the moral of the story is - we're trying to accomodate wholly different types of addresses in gatewaying mail. There are ways to do it that cause a minimum of disruption on the outside. It isn't simple. I'm open to suggestions on ways to do this better. And just wait until we get connected to MFENET and Bitnet! Gadzooks! Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA +1 619 452-6865 decvax\ brian@sdcsvax.ucsd.edu ihnp4 >--- sdcsvax --- brian ucbvax/ Kantor@Nosc