Xref: utzoo comp.mail.uucp:3142 comp.mail.misc:1916 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.mail.uucp,comp.mail.misc Subject: Re: rewriting FROM: lines Message-ID: Date: 23 May 89 21:41:07 GMT References: <31051@sri-unix.SRI.COM> <160@zebra.UUCP> Sender: news@tut.cis.ohio-state.edu Followup-To: comp.mail.uucp Organization: OSU Lines: 191 In-reply-to: vern@zebra.UUCP's message of 20 May 89 20:23:13 GMT 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 . 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...:-] --Karl