rja@edison.GE.COM (rja) (05/03/89)
Lately I find that sites out in UUCP-only land are doing rude things by way of rewriting my FROM: lines in bizarre ways. When the leave here, the are in the form From: rja <rja@edison.cho.ge.com> When they arrive at the destination they are a mangled mess inside the < > that no site could parse correctly. If the From: line contains a clean RFC 822 domain-name address, PLEASE don't rewrite it. The chances of mail bounce when it isn't touched are small, the chances of mail bounce upon reply when a site tries to stuff a UUCP bang path in there are great. I just wish we could eliminate the entire host1!host2!user@relayhost.domain syntax and the user%relay@host.domain syntax since they seem to be widely implented incorrectly (if one believes that there is a clear "correct" way). If folks would keep some semblance of maps or a smart-host, then a simple user@domain syntax could be used without all this rewriting.... And we thank you for your support... ______________________________________________________________________________ Internet (vastly preferable) : rja@edison.CHO.GE.COM UUCP (if you've got no choice): ...uunet!virginia!edison!rja ______________________________________________________________________________ Bang paths : just say NO !
chip@ateng.ateng.com (Chip Salzenberg) (05/18/89)
According to rja@edison.GE.COM (rja): >Lately I find that sites out in UUCP-only land are doing >rude things by way of rewriting my FROM: lines in bizarre >ways. If only the UUCP sites were the only ones at fault! My most recent problems have been with cs.utexas.edu and Sun.COM, not exactly UUCP backwaters. Let's all chant the Mail Header Mantra: >If the From: line contains a clean RFC 822 domain-name address, >PLEASE don't rewrite it. I couldn't agree more. In fact, I personally would extend this courtesy to "user@host.UUCP"; but I suppose I'm just a reactionary. :-) -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) (05/18/89)
In article <1989May17.194701.16816@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >According to rja@edison.GE.COM (rja): >>Lately I find that sites out in UUCP-only land are doing >>rude things by way of rewriting my FROM: lines in bizarre >>ways. >If only the UUCP sites were the only ones at fault! My most recent problems >have been with cs.utexas.edu and Sun.COM, not exactly UUCP backwaters. Interesting, can your provide examples? Perhaps I can help clean our end up, *IF* we have a problem. Its probably bad form to say this here, and I'll probably end up with more hate mail than I ever need, but I'm going to state this anyway. UUCP (and 'bang addressing') are a really stupid way of doing things. Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me which 'bar' you mean, and I have some hope of delivering it. But then, you were complaining about domain addresses to begin with. Nothing I've said has anything to do with where I work. Jim Jim Thompson - Network Engineering - Sun Microsystems - jthomp@central.sun.com Member of the Fatalistic International Society for Hedonistic Youth (FISHY) "I woudn't recommend sex, drugs, or unix for everyone, but they work for me." - Me (paraphrasing Hunter S. Thompson)
gore@eecs.nwu.edu (Jacob Gore) (05/18/89)
/ comp.mail.misc / jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) / May 18, 1989 / >UUCP (and 'bang addressing') are a really stupid way of doing things. >Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea >which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me >which 'bar' you mean, and I have some hope of delivering it. Take the maps posted to comp.mail.maps. Run them through pathalias. The 'bar' that comes out is bar.UUCP. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
wisner@mica.Berkeley.EDU (Bill Wisner) (05/20/89)
(Jim Thompson) >UUCP (and 'bang addressing') are a really stupid way of doing things. >Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea >which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me >which 'bar' you mean, and I have some hope of delivering it. Pshaw. foo@bar.UUCP is a stupid revolting hack, I'll give you that. But bar!foo is just fine. It's a UUCP address. It's unmistakably a UUCP address. When you see bar!foo the first thing you should think is "that's a UUCP address". And when your mailer sees bar!foo it should think "this is a UUCP address" and act accordingly. So what's wrong with bar!foo?
vern@zebra.UUCP (Vernon C. Hoxie) (05/21/89)
In article <31051@sri-unix.SRI.COM>, jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) writes: > > UUCP (and 'bang addressing') are a really stupid way of doing things. > Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea > which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me > which 'bar' you mean, and I have some hope of delivering it. > Jim: I have been confused for a long time about how to interpret domain names. "Bang" pathes seem quite logical in that they describe the step by step path from one user to another. In fact, bang pathes are used in domain addressing until we get to that weird stuff at the end. Suddenly the logical sequence of names is inverted so that the users name precedes the machine or whatever is inferred. That flip in logic is what makes me think of domain addressing as "stupid". Perhaps you can enlighten some of us who are not exactly in a "domain" as to the virtues of this style addressing. First, my dictionary has one definition of "domain" as "a sphere of influence". I can't see how the .COM on your address has any relevance to the delivery of a message when there are so many .COM's scattered all over the country. In your address, "jthomp@hemaneh.Central.Sun.COM", what are the meanings of the encryptions following the "@" sign? ..and of what concern are they to me so far from your organization. If we are not large corporations or universities, but individuals not affiliated with any defined domain, what addressing should be used? -- Vernon C. Hoxie {ncar,nbires,boulder,isis}!scicom!zebra!vern 3975 W. 29th Ave. voice: 303-477-1780 Denver, Colo., 80212 uucp: 303-455-2670
clutx.clarkson.edu (Drew Derbyshire,,,9143397425) (05/21/89)
From article <1936@edison.GE.COM>, by rja@edison.GE.COM (rja): > I just wish we could eliminate the entire > > host1!host2!user@relayhost.domain > > syntax and the > > user%relay@host.domain But you can't do it by fiat... even IBM can't kill off procotols it hates, and it has (compared to UNIX vendors) a vise-grip on its users. I just rewrote my copy of UUPC to handle the pathing you mentioned above (how? real simple, I guessed!), and you are correct, it is vague. But do you want every PC on the net to register as a proper domain? This could get REAL hairy REAL fast. QUESTION: What is the proper procedure to to register as a UUCP host.domain? A friend said drop mail to sri-nic, but they are internet, not UUCP (or do they do windows too?) Drew Derbyshire Internet: ahd@clutx.clarkson.edu U.S. Mail: 578 Broadway, Apt 6 Voice: 914-339-7425 Kingston, NY 12401
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (05/22/89)
ahd@sun.soe!clutx.clarkson.edu writes:
But do you want every PC on the net to register as a proper domain?
If such PC's are expected to receive either mail or news, yes.
This could get REAL hairy REAL fast.
Not really; nameservers are a concept which scales quite well.
QUESTION: What is the proper procedure to to register as a UUCP
host.domain? A friend said drop mail to sri-nic, but
they are internet, not UUCP (or do they do windows too?)
Ann Westine <westine@venera.isi.edu> is the domain contact for the .us
top-level domain, which is where random, organizationally-disconnected
machines can become registered. The .us domain is subdivided into
state and city subdomains, and machines are thereby registered
geographically. E.g., there is a machine here for which my machines
perform MX service called sydney.columbus.oh.us.
--Karlwisner@mica.Berkeley.EDU (Bill Wisner) (05/24/89)
I'm sure I'll get some help here (you there, Karl?) but here goes: (Vernon C. Hoxie) > I have been confused for a long time about how to interpret >domain names. "Bang" pathes seem quite logical in that they describe the >step by step path from one user to another. In fact, bang pathes are used >in domain addressing until we get to that weird stuff at the end. Suddenly >the logical sequence of names is inverted so that the users name precedes >the machine or whatever is inferred. That flip in logic is what makes me >think of domain addressing as "stupid". The addressing style makes perfect sense. I'm wisner@mica.berkeley.edu, which can be literally taken as "wisner at (the machine) mica.berkeley.edu". That can be further broken down as a machine named mica, which is at Berkeley, which is an EDUcational institution. Bang paths are *not* used in proper domain addressing. UUCP machines will use them to fit the constraints of the transport, but the users at either end of the delivery (the sender and receiver) should never see them. Domain-style addressing is not stupid. It is (opinion follows), if anything, simpler and more "graceful," if you will, than a bang path. > Perhaps you can enlighten some of us who are not exactly in a >"domain" as to the virtues of this style addressing. First, my >dictionary has one definition of "domain" as "a sphere of influence". >I can't see how the .COM on your address has any relevance to the delivery >of a message when there are so many .COM's scattered all over the country. One advantage of domain-style addressing is that you need only address mail to user@host and it will get there. No mucking about with paths or routing or gateways. Another advantage is that domain-style machine names guarantee uniqueness. This is the only mica.berkeley.edu there is. Someone at, say, UCLA could also name his machine mica. He would then have himself a machine called mica.ucla.edu. There are no conflicts involved because both names are different. Having two UUCP hosts named mica, on the other hand, would cause some problems. > In your address, "jthomp@hemaneh.Central.Sun.COM", what are the >meanings of the encryptions following the "@" sign? ..and of what concern >are they to me so far from your organization. hemaneh.Central.Sun.COM is the full, official name of his machine. At a guess, I'd say that the machine is named hemaneh and it's in the Central division offices of Sun Microsystems, which is a COMpany. > If we are not large corporations or universities, but individuals >not affiliated with any defined domain, what addressing should be used? There's a US (United States) domain which works out well for such things. You could, perhaps, register as zebra.denver.co.us.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (05/24/89)
Warning: lengthy technobabble begins...
vern@zebra.UUCP (Vernon C. Hoxie) writes:
I have been confused for a long time about how to interpret
domain names. "Bang" pathes seem quite logical in that they describe the
step by step path from one user to another.
The problem is that !-paths expect the user to know the underlying
infrastructure of how machines move mail from one place to another,
which is a violation of the Principle of Least Astonishment.
("Waddayamean, *I* have to know which 6 systems through which mail
must pass to get to Joe WhatsHisName at ThatSystemOverThere?")
If you, in ?Denver? were to write physical snail mail to me, you
wouldn't address it by stipulating the various post offices through
which it would send, e.g., Denver, via airmail to Columbus, via truck
to OSU campus mail, via deliveryperson to this dept, via
secretary/mail-handler/whomever to my mailbox. You'd be insulted if
you were expected to know that much detail, or had to tell the US
Postal Service people such things. You address it geographically and
organizationally, and you just expect it to Get There.
In fact, bang pathes are used
in domain addressing until we get to that weird stuff at the end. Suddenly
the logical sequence of names is inverted so that the users name precedes
the machine or whatever is inferred. That flip in logic is what makes me
think of domain addressing as "stupid".
All you're looking at there is a difference in which direction to read
an address. !-paths are written left-to-right, whereas strict domain
addresses are written right-to-left.
In the case of a mixed-mode address (that is, containing both ! and
@), think of the network punctuation as operators in a mathematical
expression. By the standards under which Internet hosts work, @ is a
higher-precedence operator than !. So the address
host!user@some.where.edu
means
Tell some.where.edu to hand this to host!user.
In the strictest terms, you, as the writer of such mail, have no
knowledge of exactly what some.where.edu is going to do with it. You
think it's going to do UUCP things once it gets to some.where.edu, but
you might well be wrong - you're just guessing. Nothing left of @ in
a domain address is anybody's business to interpret, except for the
host some.where.edu itself.
Now, in practice, we all "know" that host!user on the end is a
UUCPism, and that some.where.edu will speak UUCP to "host" and expect
"host" to deliver to "user" when the mail gets there. But that's
interpreting a lot more than you're really expected to know.
In a "pure" case, that is, a domain address using @ with no ! or other
punctuation, the syntax
username@host.domain
means
Tell host.domain to give this mail to username.
Note that there is nothing in a domain address which stipulates how
delivery is accomplished. Domains are, at best, organizational or, at
worst, geographical (e.g., the country [".US"] domains). Nothing is
provided indicating how the machines speak to one another to get
there. This is a Good Thing, for exactly the same reasons that you
don't want to tell the Denver postmaster how to get mail to my office.
The problems in knowing the connectivity of 17K hosts in UUCPland are
what led to the creation of the UUCP Project, pathalias, and smail.
The map data published in comp.mail.maps is hacked on by pathalias
into a paths file which describes least-cost paths between Hither and
Yon, so the UUCP user can use "absolute" addresses just like Internet
sites, where connectivity for such things is a question far below the
writer of mail. The pathalias-generated database is used by a mailer
(notably, smail 2.x) which takes, e.g., "osu-cis!karl" and turns it
into a full-blown, complete, UUCP !-path route by which to get between
(in your case) the machine "zebra" and my machine "osu-cis." You
don't have to know the connectivity because the map data, pathalias,
and smail took care of those details for you. Smail also has the
intelligence to look at, e.g., "karl@cis.ohio-state.edu" and turn that
into a UUCP !-path to reach the same place. Again, you need know no
connectivity.
For hosts running IP on the real, physical Internet (as distinct from
the pseudo- and non-physical internet of hosts capable of using this
kind of addressing), questions of routing to reach a domain address
are done in what I'll euphemistically call "real time," by which I
mean that my mailer sees that I've written mail to
"user@some.where.edu" and so it queries a program running on my
systems called a nameserver. My nameserver goes asking the
authoritative "root servers" about where "some.where.edu" is, in terms
of absolute Internet addresses. The root servers return not with the
actual address, but pointers ("NS records," which are pointers to
hosts which perform lower-level nameservice) to the hosts which really
do know all the gut-level details of hosts inside the organizational
entity "where.edu." So my mailer again queries those hosts, again
asking for the absolute address of "some.where.edu," and (one
presumes) such an address is returned by these hosts. Then my mailer
knows where and how to deliver mail, so my mailer connects with the
remote mailer, and delivers the mail via a protocol called SMTP
(simple mail transport protocol).
In the case of a host not physically connected to the Internet (that
is, not reachable with an absolute Internet address), a mailer does
not get back addresses, but rather another type of pointer, called an
MX record. MX records indicate the hosts which have advertised a
willingness to be the Mail eXchanger for the indicated destination.
So if you were to register "zebra" as "zebra.denver.co.us," and I were
to write mail to you, the sequence of events would be approximately:
[a] my mailer accepts the mail from my user agent.
[b] my mailer asks the local nameserver, "How do I get mail
to zebra.denver.co.us?"
[c] the nameserver doesn't know, so it asks the root servers,
"Who's in charge of Colorado?"
[d] root servers return the information, "Venera.isi.edu is
the host in charge of Colorado," via NS records.
[e] my nameserver than asks Venera, "How do I push mail in
the direction of zebra.denver.co.us?"
[f] Venera responds, "Mail addressed to zebra.denver.co.us
should be handed to boulder.colorado.edu," via MX
records.
[g] my nameserver informs my mailer of this answer, and also
caches a copy of the answer in case it's asked again in
the near future.
[h] my mailer requests an SMTP connection with
boulder.colorado.edu, and sends the mail. It is assumed
that the receiving (MX) host knows how to detect the
hosts for which it serves as MX (usually syntactically),
and will then convert the mail to some other transport,
probably UUCP in your case.
[A point to stress: boulder.colorado.edu is not, by any information I
have, performing MX service for anything called zebra.denver.co.us.
I'm just building an example out of the air here.]
[Another point: I know I'm glossing over details. Again, this is an
example only - hold your flames until/unless I make a major gaffe.]
Perhaps you can enlighten some of us who are not exactly in a
"domain" as to the virtues of this style addressing. First, my
dictionary has one definition of "domain" as "a sphere of influence".
I can't see how the .COM on your address has any relevance to the delivery
of a message when there are so many .COM's scattered all over the country.
The top-level domains (gov, com, edu, org, net, mil) are mostly
convenient pigeonhole-able pseudo-entities wherein large numbers of
entities of that general "class" can be placed. Universities are
educational entities, so all universities end up being parked in the
.edu domain. Similarly, commercial entities land in .com, military
entities are known under .mil, and so forth.
Concrete example: I can be addressed as karl@tut.cis.ohio-state.edu.
That means that there is an educational entity known as Ohio State
University, inside of which there is a Computer & Information Science
department. That department owns a machine called Tut. The user
`karl' can be found on that system from time to time. :-)
In your address, "jthomp@hemaneh.Central.Sun.COM", what are the
meanings of the encryptions following the "@" sign? ..and of what concern
are they to me so far from your organization.
Again, reading right to left for increasingly precise definition:
com: This is a commercial entity
sun: The commercial entity is called "sun."
central: An internal designation, probably for the
central or home offices of the company.
hemaneh: The name of the machine at which jthomp
can be expected to be found.
Hostnames are *always* case-insensitive: Sun.COM == sun.com == sUn.CoM
== SUn.coM == ...
If we are not large corporations or universities, but individuals
not affiliated with any defined domain, what addressing should be used?
There are geographical top-level domains. In particular, there is a
.us domain, under which are state and city subdomains, wherein
organizationally-disconnected machines can become registered. You
will have to find a real Internet site (using IP and nameservers and
the whole schmeer) willing to be your domain forwarder, that is, to
provide MX service to you. Once you have secured such services from
one such entity, you can request registration. The person in charge
of the .us domain is Anne Westine <westine@venera.isi.edu>. There is
a form to be filled out (electronically will do just fine), and
shortly thereafter the Internet nameservers will be given the
knowledge of your system. At that point, you can advertise your
full-qualified domain name (FQDN) in mail and news From: lines, and
everyone should be able to reach you. You should, of course, also
email a new form to the UUCP project so that updated data showing your
domain name is known to all the UUCP universe's pathalias data.
[Corrections to any of the aforementioned "major gaffes" will surely
be forthcoming now...:-]
--Karldce@Solbourne.COM (David Elliott) (05/24/89)
In article <160@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: > Perhaps you can enlighten some of us who are not exactly in a >"domain" as to the virtues of this style addressing. First, my ... > In your address, "jthomp@hemaneh.Central.Sun.COM", what are the >meanings of the encryptions following the "@" sign? ..and of what concern >are they to me so far from your organization. Think about it this way: When you send a physical (as in paper, envelope, and stamp) letter, you don't tell the post office how to deliver it. When I send a letter home, I don't write on it "Send to Denver, then to Atlanta, then to Raleigh, then to Chapel Hill, then to 125 Booth Rd", I just write down the final address, and the post office figures out how to get it there. Postal addresses are unique. The same goes for a phone conversation. I don't tell the phone company how to route the call, I just dial a phone number and the system automatically connects me. Phone numbers are unique. By using a domain address, you are effectively asking for the same type of service that the post office and telephone company (I did say "type", and not "level" ;-) provides. Domain addresses are unique. You don't really need to know what hemanth.Central.Sun.COM means any more than you need to know where 125 Booth Rd. in Chapel Hill, NC is. All you need to know is that on all of the network served by this type of addressing, jthomp@hemanth.Central.Sun.COM is a unique mail address, and that no correctly-working mail forwarder will confuse it with another jthomp on some other machine. The other advantage is that it hides changes from people who don't really care about the topology of the network. It means that I don't have to know that to get to one of my friends in CA, I have to say nbires!ncar!ames!mips!ultra!rmg, and can instead send directly to rmg@ultra.com. Either way it will get there now, but if one of these sites dies, or if a pair quits talking to each other, I don't have to worry. -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce
bill@twwells.uucp (T. William Wells) (05/24/89)
In article <24763@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes:
: > If we are not large corporations or universities, but individuals
: >not affiliated with any defined domain, what addressing should be used?
:
: There's a US (United States) domain which works out well for such things.
: You could, perhaps, register as zebra.denver.co.us.
I'm registered as twwells.com, even though there is no commercial
activity going on here. I chose that over twwells.ftl.fl.us because I
didn't want to have to change my site name were I to move. In any
case, it is very simple to get registered.
---
Bill { uunet | novavax } !twwells!billfr@icdi10.UUCP (Fred Rump from home) (05/25/89)
In article <160@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: >In article <31051@sri-unix.SRI.COM>, jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) writes: ->> ->> UUCP (and 'bang addressing') are a really stupid way of doing things. ->> Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea ->> which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me ->> which 'bar' you mean, and I have some hope of delivering it. ->> > I have been confused for a long time about how to interpret >domain names. >I can't see how the .COM on your address has any relevance to the delivery >of a message when there are so many .COM's scattered all over the country. > In your address, "jthomp@hemaneh.Central.Sun.COM", what are the >meanings of the encryptions following the "@" sign? ..and of what concern >are they to me so far from your organization. Hear, hear - I'm sure there are many of us who would like a logical explanation for Vernon's questions. In my address from uunet (fred@cdin-1.uu.net) I wonder whether I'm in domain uu or net or what? And since we have a lot of customers out there, to whom we assigned site names but nothing, else should they be in our own little domain even so they are all separate entities? Fred Rump -- This is my house. My castle will get started right after I finish with news. 26 Warren St. ...{dsinc bpa uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 or INTERNET: fred@cdin-1.uu.net or icdi10!fr@icdi10.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
mark@cbnews.ATT.COM (Mark Horton) (05/31/89)
In article <160@zebra.UUCP> Vernon C. Hoxie writes: >In article <31051@sri-unix.SRI.COM>, Jim Thompson writes: >> >> UUCP (and 'bang addressing') are a really stupid way of doing things. >> Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea >> which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me >> which 'bar' you mean, and I have some hope of delivering it. > > I have been confused for a long time about how to interpret >domain names. "Bang" pathes seem quite logical in that they describe the >step by step path from one user to another. In fact, bang pathes are used >in domain addressing until we get to that weird stuff at the end. Suddenly >the logical sequence of names is inverted so that the users name precedes >the machine or whatever is inferred. That flip in logic is what makes me >think of domain addressing as "stupid". Ah, a true religious debate. If we can refrain from damning the blasphemers for a few moments, and look at the technical issues, it will become clearer. Vernon points out the difference in left-to-right and right-to-left addressing styles. Bangs are left-to-right (first!next!..!last!user) and domains are right-to-left (user@local..org.country). There is well established precedent for both: telephone numbers are left-to-right, and postal addresses are right-to-left. Which is best? On pure technical grounds, it doesn't matter. However, when you get mixtures of the two, bad things happen. This is why standardization is crucial. Hybrid addresses like foo!bar@mumble.com can be (and are) interpreted both ways, often wrong. Life is further complicated by the UK, which has a sideways notation user@country.admd.org..local. In networking, there are three key concepts: names, addresses, and routes. A "name" is a high level, user guessable way to identify a person, machine, or other entity. For example, "Mark Horton". Names may be ambiguous, especially when abbreviated "M Horton". Names can be made unambiguous by adding more information. "Mark Randolph Horton who works for AT&T in Columbus Ohio and whose SSN is 1234567890" An "address" is a medium level, unambiguous way to identify *where something is*. For example, "Room 234, 1234 Main St, Columbus Ohio, USA". Addresses depend on the underlying technology, and one entity can have several addresses, e.g. postal, latitude/longitude. A "route" amounts to giving directions to get to an address. "Get on I-70 eastbound, drive to Columbus and take the 4th street offramp, turn north on 4th, turn east on Main, drive until you see a building with 1234 on it, park the car, go in the side door, up the stairs to the 2nd floor, down the B hallway to room 234." Routes tend to be different, depending on where the entity following the directions is starting from. Routes are usually tied to the underlying technology. Various computer entities that might have names, addresses, and/or routes include people, mailboxes, machines, modems, terminals, and so on. For email mailboxes, since mailboxes are often described by a person or login and a machine, there is sometimes a mixture of these three descriptions for both people and machines. Bang paths are routes for machines. If the last entity in the bang path is a login name, it becomes a route to get to a person's mailbox. Dotted IP addresses, like 192.11.2.1, are addresses for machines. Datakit dialstrings, such as oh/cbh/cblpf, are also addresses, although they are nicer because they use character strings instead of numbers. Domains, like cblpf.att.com, are names for machines. It is possible to map a machine name cblpf.att.com into a machine address, like 192.11.2.1 or oh/cbj/cblpf, and from there into a route like att!cblpf. cblpf is also a machine name, although it's likely to be ambiguous. Mailboxes may have an address (e.g. a login on a particular machine). Sometimes a name server can provide a mapping from names to addresses. The AT&T post database will map "mark.horton" into "cblpf!mark", for example. Thus, you can get various mixtures of descriptions in email targets: ucbvax!att!cblpf!mark route mark@cblpf.att.com address @ named machine, e.g. address mark.horton@att.com name on named domain, e.g. name All three of these forms will work, although the first one only works if you have a connection to ucbvax (or if your machine can fake it.) In general, users usually prefer names to addresses, and addresses to routes. routes are easier for computers to deal with than addresses (a mapping is required), and addresses are easier than names (two mappings may be needed.) There are other reasons to prefer names to addresses, and addresses to routes. Names tend to follow people around when they change addresses. (When I moved from cbosgd to cblpf, my name stayed the same.) Replies to names and addresses are easy: just leave the text alone. If you've seen some of the stuff mailx/Mail has to do to bang paths on carbon copies to get replies delivered, you'll appreciate the simplicity of names and addresses. The replying machine has to look at the header (possibly broken by intermediate machines) and guess what the path on a Cc: line meant to the sender. Names and addresses are sometimes longer than routes, just like full phone numbers are longer than extensions. Sometimes people prefer to type the route if they know it, and it's shorter. This is when it's a good idea to have an aliasing mechanism for even higher level names that are local to a user: $ cat .mailrc alias frank frank.n.stein@att.com $ mailx frank Names, addresses, and routes will always be around. Names need to be mapped into addresses, and addresses need to be mapped into routes, internally to the machine. But the world is steadily moving away from routes (which were implemented first) through addresses (which have been around for some time) to names (which are just now starting to get serious use) as the preferred means of sending email to people. There are, however, so many different standards and dialects, that there is much confusion in the meantime. Each standard and dialect has a large cult of faithful followers. Just like religions. Mark Horton (no, I don't use the Bourne-again shell)
taylor@cs.glasgow.ac.uk (Mr Jem Taylor) (06/01/89)
In article <24642@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes: >Pshaw. foo@bar.UUCP is a stupid revolting hack, I'll give you that. But >bar!foo is just fine. It's a UUCP address. It's unmistakably a UUCP address. > I'm sorry, but I can't agree with any of this. "bar!foo" has the same semantic content as "foo@bar" ; I believe it to be both permissible and necessary to convert one to the other merely to move a message between two connected systems if the standard notation is one on the first and the other on the second. If you wish to be able to communicate with a system such as ours which uses domain names (not the domain name system RFC88n), then you must use a domain name such as "foo@bar.uucp", or, in your notation, "bar.uucp!foo" otherwise I cannot send back. The problem is that few niave (ie, single environment, including many Unix gurus) people seem to acknowledge the need for globally valid names to be stamped when a message moves between systems. You can have local names and local domain expansion if you want it; you cannot expect me to have knowledge of your local domain, whereas you can expect me to recognise the name of the domain which encompasses yours. >When you see bar!foo the first thing you should think is "that's a UUCP >address". And when your mailer sees bar!foo it should think "this is a >UUCP address" and act accordingly. I suggest that you should recognise the name "bar" and 'complete' it (in the terminology of the ARPAnet Domain Name System) by adding the name of its enclosing domain, regardless of the notation originally used. The uk-sendmail sendmail.cf writing package generates sendmail.cf files which do this, regardless of the format in which names are presented. Afterwards, it routes messages to the correct relay and converts all addresses to the notation that the relay understands. -Jem Taylor. -- Arpa:taylor@cs.glasgow.ac.uk \ J.A.Taylor, Computing Science, Janet: taylor@uk.ac.glasgow.cs \ University of Glasgow, Uucp: mcvax!cs.glasgow.ac.uk!taylor \ GB-GLASGOW G12 8QQ
rang@cpsin3.cps.msu.edu (Anton Rang) (06/03/89)
I'm sure there are others better qualified than I to answer this, but here's an attempt at a quick explanation. > In my address from uunet (fred@cdin-1.uu.net) I wonder whether I'm in >domain uu or net or what? You are in the domain uu.net, which is a subdomain of the net domain. "net" is the domain of non-Internet networks (more or less, someone can probably clarify this) and "uu.net" is the domain of the UUCP network. > And since we have a lot of customers out there, to whom we assigned site >names but nothing, else should they be in our own little domain even so they >are all separate entities? I'm not quite clear about what you mean here. Domain names should reflect some sort of hierarchical organization. If they are customers of yours, but not part of your organization itself, they should have their own domains (probably under "com" if they are companies). +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
rick@uunet.UU.NET (Rick Adams) (06/03/89)
In article <3254@cps3xx.UUCP>, rang@cpsin3.cps.msu.edu (Anton Rang) writes: > You are in the domain uu.net, which is a subdomain of the net > domain. "net" is the domain of non-Internet networks (more or less, > someone can probably clarify this) and "uu.net" is the domain of the > UUCP network. That comes as a major surprise to us! We thought it was our company domain. (Or do we own the UUCP network now?) --rick
rang@cpsin3.cps.msu.edu (Anton Rang) (06/03/89)
In article <56591@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: In article <3254@cps3xx.UUCP>, rang@cpsin3.cps.msu.edu (Anton Rang) writes: > You are in the domain uu.net, which is a subdomain of the net > domain. "net" is the domain of non-Internet networks (more or less, > someone can probably clarify this) and "uu.net" is the domain of the > UUCP network. That comes as a major surprise to us! We thought it was our company domain. (Or do we own the UUCP network now?) --rick <red face> "The domain of the UUNET Communications Services company, which provides many UUCP sites with a domain-style address." Better? Anton (more of an Internet person :-) +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
ade@clark.edu (Adrian Miranda) (09/12/90)
I posted this once before, but never got a response. We have a neighbor who insists on rewriting valid From: lines on mail that is headed our way. That is, if the From: line contains user@domain, this site will turn it into site!domain!user. Apparently, they feel that any site they talk to with uucp could not possibly deal with an internet style address. Since we are running smail3, there is no need to modify the From: line, but my complaints have been ignored. What I am wondering is, should I try to turn these From: lines back into user@domain? I was thinking of using a perl script to intercept incoming mail from this site. Does this seem reasonable, or should I just leave it alone? Adrian Miranda uunet!clark!ade or ade@clark.edu