greid@adobe.com (Glenn Reid) (06/01/89)
In article <6982@cbnews.ATT.COM> mark@cbnews.ATT.COM (Mark Horton) writes: >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. ...and a large amount of other helpful, true stuff. I read this message and essentially agreed with everything Mark said. But then a thought started brewing in my mind. A thought that is rooted in the fact that a lot more of my mail has been bouncing recently than ever before. A thought that embraces heterogeneity, anarchy, shifts in the political winds, backbones, byte limits, and real worlds in general. A thought that makes me question whether you can really "solve" this problem. Let's say you start with a fully qualified name and address, like Joe_User@Host.Domain.NETWORK. This can then be resolved into an actual route by a mail router that finds the appropriate stuff in its tables, and the mail can be delivered to Joe_User. However, it seems that 30% of the time, Joe_User cannot reply to the mail, because the routing is sometimes non-deterministic and may in fact not be reversible. The "From:" and other lines in the mail are almost certainly rewritten by partially damaged software along the way. Also, my name and address may not be in his host table, or my router doesn't know about JANET or the domain for New Zealand or whatever. So the mail bounces. The bangity!bangity!user stuff is pretty crude, but it was very reliable in terms of reversing the path and getting mail returned to the sender. That's valuable, in my opinion. And sorely missed in today's world. Glenn Reid Adobe Systems
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (06/01/89)
greid@adobe.com writes:
The bangity!bangity!user stuff is pretty crude, but it was very
reliable in terms of reversing the path and getting mail returned to
the sender.
I respectfullly disagree. I refer you to the footnote in my previous
posting regarding non-reversability of paths going through my archive
machine osu-cis as used by anonymous UUCP accessors. Bidirectional
links are *not* universal. They never have been.
--Karlstevea@laidbak.UUCP (Steve Alexander) (06/01/89)
In article <882@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: > >The bangity!bangity!user stuff is pretty crude, but it was very >reliable in terms of reversing the path and getting mail returned to >the sender. That's valuable, in my opinion. And sorely missed in >today's world. > >Glenn Reid >Adobe Systems Well, when I started using this stuff (about 7 years ago), the network was much smaller, so that may be why it used to seem better. As others have pointed out, it's typically only mixing addresses that generate the confusion. The more hosts and networks that get added, the higher the chance that something won't get where it's going. But even in ``the good old days,'' there were links that didn't work consistently, whether they were unidirectional, or news-only. -- Steve Alexander, TCP/IP Development | stevea%laidbak@sun.com Lachman Associates, Inc. | ...!sun!laidbak!stevea
art@felix.UUCP (Art Dederick) (06/01/89)
In article <882@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: >The bangity!bangity!user stuff is pretty crude, but it was very >reliable in terms of reversing the path and getting mail returned to >the sender. That's valuable, in my opinion. And sorely missed in >today's world. I agree and why in the h___ did it have to change? If it isn't broken, don't fix it. Art D. felix!art
mark@cbnews.ATT.COM (Mark Horton) (06/02/89)
In article <882@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: >The bangity!bangity!user stuff is pretty crude, but it was very >reliable in terms of reversing the path and getting mail returned to >the sender. That's valuable, in my opinion. And sorely missed in >today's world. That's why RFC976 says that there's supposed to be BOTH a return address or name and a return route in the header: From cblpf!mark <date> remote from att From: mark@cblpf.att.com (Mark Horton) The remote from is ugly, but necessary for upward compatibility. By the time it arrives in your mailbox, it probably looks like From att!cblpf!mark <date> From: mark@cblpf.att.com (Mark Horton) As a rule, you can reply using either the From_ line (the route) or the From: line (the address or name.) Mail/mailx, for example, uses r for one and R for the other (possibly flipped.) The return route is also needed for upward compatibility, as well as redundancy and troubleshooting. Most of the time, you can just reply using the From: line and get the right result. Every once in awhile something is broken in the header you get, and you get a broken From: line and have to reply using the From_ line. For example, mail through sun (and some other places) arrives looking like From: sun!dasnet!user and since I'm not directly connected to sun, the reply bounces. (Some sites smart-host to figure out who sun is, our software doesn't.) There is still much turmoil in the email world. There are lots of broken mailers out there. And while the world is clearly building momentum around RFC822 domains and getting its act together to support them, X.400 and X.500 are starting to build critical mass. Throw billing into the picture (who is going to pay for the mail from random UUCP sites into the commercial X.400 world?) and the whole picture gets a lot messier. Gives all us postmasters something to do to earn our paychecks. Mark
wisner@mica.Berkeley.EDU (Bill Wisner) (06/03/89)
(Mark Horton) >As a rule, you can reply using either the From_ line (the route) >or the From: line (the address or name.) Mail/mailx, for example, >uses r for one and R for the other (possibly flipped.) The return >route is also needed for upward compatibility, as well as redundancy >and troubleshooting. Eh? Last I used mailx, the difference between r and R is that one replies to the sender only and one replies to everyone named in Cc:s as well as the sender. It always used the From_ return route. To reply to the address given in a From: line I'd have to edit the address manually. Of course, mailx has many more problems than that, and I was happy to punt it..
mrm@sceard.COM (M.R.Murphy) (06/03/89)
In article <7050@cbnews.ATT.COM> mark@cbnews.ATT.COM (Mark Horton) writes: [much stuff deleted so that I can ask a question about what's bugging me...] >Most of the time, you can just reply using the From: line and get >the right result. Every once in awhile something is broken in the >header you get, and you get a broken From: line and have to reply >using the From_ line. For example, mail through sun (and some other >places) arrives looking like > From: sun!dasnet!user >and since I'm not directly connected to sun, the reply bounces. >(Some sites smart-host to figure out who sun is, our software doesn't.) > Ours does figure out who sun is, but that's not my problem. That's a relatively well-formed rewrite. Not meaning to pick on sun specifically, I continue, why rewrite the From: anyhow? In all this thread I haven't seen any reason for rewrite of From:. I now reason by analogy, which may be specious, but why not. Suppose I address a postal card. And, somewhere on the card, I put From: Mike Murphy 544 South Pacific Street San Marcos, CA 92069 USA and I send it to somebody in East Nowhere. Not picking on East specifically:-) The Postal Authorities may change the To address or the route or whatever, so long as they deliver it to the addressee, I'm satisfied. They do that here with a neat little yellow sticker where the ink smears. They may want to pencil in a suggestion that my From: return address stinks and the addressee may want to try another route. They would normally do that when said addressee tries to respond and they return to sender (read as bounce) the mail. Then the responder can try again if they want to spend another stamp. But, and this is finally the point, I think that it borders on rude for them to mung my From: address just because they happen to have a marking pen. Even more so when they fix it real good so the responder can't respond, eh? --- Mike Murphy Sceard Systems, Inc. 544 South Pacific St. San Marcos, CA 92069 mrm@Sceard.COM {hp-sdd,nosc,ucsd,uunet}!sceard!mrm +1 619 471 0655
rsalz@bbn.com (Rich Salz) (06/03/89)
In article <882@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: >The bangity!bangity!user stuff is pretty crude, but it was very reliable ... In <99688@felix.UUCP> art@felix.UUCP (Art Dederick) writes: >I agree and why in the h___ did it have to change? If it isn't >broken, don't fix it. If it worked, than all the sites that are moving domainist would be sticking with bang paths. There's no conspiracy, no organization that can force UUCP sites to do anything. It's just that individual sites, in large numbers, are finding the domain scheme a better way to do things than an explicit-route scheme. I'm explaining this poorly, but if you think about the lack of formal structure in UUCP-land and the changing world, than it seems obvious that we're seeing Darwinism in action. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
brian@ucsd.EDU (Brian Kantor) (06/05/89)
Network Working Group Craig Partridge
Request for Comments: 974 CSNET CIC BBN Laboratories Inc
January 1986
MAIL ROUTING AND THE DOMAIN SYSTEM
Status of this Memo
This RFC presents a description of how mail systems on the Internet
are expected to route messages based on information from the domain
system described in RFCs 882, 883 and 973. Distribution of this memo
is unlimited.
Introduction
The purpose of this memo is to explain how mailers are to decide how
to route a message addressed to a given Internet domain name. This
involves a discussion of how mailers interpret MX RRs, which are used
for message routing. Note that this memo makes no statement about
how mailers are to deal with MB and MG RRs, which are used for
interpreting mailbox names.
Under RFC-882 and RFC-883 certain assumptions about mail addresses
have been changed. Up to now, one could usually assume that if a
message was addressed to a mailbox, for example, at LOKI.BBN.COM,
that one could just open an SMTP connection to LOKI.BBN.COM and pass
the message along. This system broke down in certain situations,
such as for certain UUCP and CSNET hosts which were not directly
attached to the Internet, but these hosts could be handled as special
cases in configuration files (for example, most mailers were set up
to automatically forward mail addressed to a CSNET host to
CSNET-RELAY.ARPA).
Under domains, one cannot simply open a connection to LOKI.BBN.COM,
but must instead ask the domain system where messages to LOKI.BBN.COM
are to be delivered. And the domain system may direct a mailer to
deliver messages to an entirely different host, such as SH.CS.NET.
Or, in a more complicated case, the mailer may learn that it has a
choice of routes to LOKI.BBN.COM. This memo is essentially a set of
guidelines on how mailers should behave in this more complex world.
Readers are expected to be familiar with RFCs 882, 883, and the
updates to them (e.g., RFC-973).
Partridge [Page 1]
RFC 974 January 1986
Mail Routing and the Domain System
What the Domain Servers Know
The domain servers store information as a series of resource records
(RRs), each of which contains a particular piece of information about
a given domain name (which is usually, but not always, a host). The
simplest way to think of a RR is as a typed pair of datum, a domain
name matched with relevant data, and stored with some additional type
information to help systems determine when the RR is relevant. For
the purposes of message routing, the system stores RRs known as MX
RRs. Each MX matches a domain name with two pieces of data, a
preference value (an unsigned 16-bit integer), and the name of a
host. The preference number is used to indicate in what order the
mailer should attempt deliver to the MX hosts, with the lowest
numbered MX being the one to try first. Multiple MXs with the same
preference are permitted and have the same priority.
In addition to mail information, the servers store certain other
types of RR's which mailers may encounter or choose to use. These
are: the canonical name (CNAME) RR, which simply states that the
domain name queried for is actually an alias for another domain name,
which is the proper, or canonical, name; and the Well Known Service
(WKS) RR, which stores information about network services (such as
SMTP) a given domain name supports.
General Routing Guidelines
Before delving into a detailed discussion of how mailers are expected
to do mail routing, it would seem to make sense to give a brief
overview of how this memo is approaching the problems that routing
poses.
The first major principle is derived from the definition of the
preference field in MX records, and is intended to prevent mail
looping. If the mailer is on a host which is listed as an MX for the
destination host, the mailer may only deliver to an MX which has a
lower preference count than its own host.
It is also possible to cause mail looping because routing information
is out of date or incomplete. Out of date information is only a
problem when domain tables are changed. The changes will not be
known to all affected hosts until their resolver caches time out.
There is no way to ensure that this will not happen short of
requiring mailers and their resolvers to always send their queries to
an authoritative server, and never use data stored in a cache. This
is an impractical solution, since eliminating resolver caching would
make mailing inordinately expensive. What is more, the out-of-date
RR problem should not happen if, when a domain table is changed,
Partridge [Page 2]
RFC 974 January 1986
Mail Routing and the Domain System
affected hosts (those in the list of MXs) have their resolver caches
flushed. In other words, given proper precautions, mail looping as a
result of domain information should be avoidable, without requiring
mailers to query authoritative servers. (The appropriate precaution
is to check with a host's administrator before adding that host to a
list of MXs).
The incomplete data problem also requires some care when handling
domain queries. If the answer section of a query is incomplete
critical MX RRs may be left out. This may result in mail looping, or
in a message being mistakenly labelled undeliverable. As a result,
mailers may only accept responses from the domain system which have
complete answer sections. Note that this entire problem can be
avoided by only using virtual circuits for queries, but since this
situation is likely to be very rare and datagrams are the preferred
way to interact with the domain system, implementors should probably
just ensure that their mailer will repeat a query with virtual
circuits should the truncation bit ever be set.
Determining Where to Send a Message
The explanation of how mailers should decide how to route a message
is discussed in terms of the problem of a mailer on a host with
domain name LOCAL trying to deliver a message addressed to the domain
name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
correct domain names. Furthermore, LOCAL is assumed to be the
official name for the host on which the mailer resides (i.e., it is
not a alias).
Issuing a Query
The first step for the mailer at LOCAL is to issue a query for MX RRs
for REMOTE. It is strongly urged that this step be taken every time
a mailer attempts to send the message. The hope is that changes in
the domain database will rapidly be used by mailers, and thus domain
administrators will be able to re-route in-transit messages for
defective hosts by simply changing their domain databases.
Certain responses to the query are considered errors:
Getting no response to the query. The domain server the mailer
queried never sends anything back. (This is distinct from an
answer which contains no answers to the query, which is not an
error).
Getting a response in which the truncation field of the header is
Partridge [Page 3]
RFC 974 January 1986
Mail Routing and the Domain System
set. (Recall discussion of incomplete queries above). Mailers
may not use responses of this type, and should repeat the query
using virtual circuits instead of datagrams.
Getting a response in which the response code is non-zero.
Mailers are expected to do something reasonable in the face of an
error. The behaviour for each type of error is not specified here,
but implementors should note that different types of errors should
probably be treated differently. For example, a response code of
"non-existent domain" should probably cause the message to be
returned to the sender as invalid, while a response code of "server
failure" should probably cause the message to be retried later.
There is one other special case. If the response contains an answer
which is a CNAME RR, it indicates that REMOTE is actually an alias
for some other domain name. The query should be repeated with the
canonical domain name.
If the response does not contain an error response, and does not
contain aliases, its answer section should be a (possibly zero
length) list of MX RRs for domain name REMOTE (or REMOTE's true
domain name if REMOTE was a alias). The next section describes how
this list is interpreted.
Interpreting the List of MX RRs
NOTE: This section only discusses how mailers choose which names to
try to deliver a message to, working from a list of RR's. It does
not discuss how the mailers actually make delivery. Where ever
delivering a message is mentioned, all that is meant is that the
mailer should do whatever it needs to do to transfer a message to a
remote site, given a domain name for that site. (For example, an
SMTP mailer will try to get an address for the domain name, which
involves another query to the domain system, and then, if it gets an
address, connect to the SMTP TCP port). The mechanics of actually
transferring the message over the network to the address associated
with a given domain name is not within the scope of this memo.
It is possible that the list of MXs in the response to the query will
be empty. This is a special case. If the list is empty, mailers
should treat it as if it contained one RR, an MX RR with a preference
value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
MX). In addition, the mailer should do no further processing on the
list, but should attempt to deliver the message to REMOTE. The idea
Partridge [Page 4]
RFC 974 January 1986
Mail Routing and the Domain System
here is that if a domain fails to advertise any information about a
particular name we will give it the benefit of the doubt and attempt
delivery.
If the list is not empty, the mailer should remove irrelevant RR's
from the list according to the following steps. Note that the order
is significant.
For each MX, a WKS query should be issued to see if the domain
name listed actually supports the mail service desired. MX RRs
which list domain names which do not support the service should be
discarded. This step is optional, but strongly encouraged.
If the domain name LOCAL is listed as an MX RR, all MX RRs with a
preference value greater than or equal to that of LOCAL's must be
discarded.
After removing irrelevant RRs, the list can again be empty. This is
now an error condition and can occur in several ways. The simplest
case is that the WKS queries have discovered that none of the hosts
listed supports the mail service desired. The message is thus deemed
undeliverable, though extremely persistent mail systems might want to
try a delivery to REMOTE's address (if it exists) before returning
the message. Another, more dangerous, possibility is that the domain
system believes that LOCAL is handling message for REMOTE, but the
mailer on LOCAL is not set up to handle mail for REMOTE. For
example, if the domain system lists LOCAL as the only MX for REMOTE,
LOCAL will delete all the entries in the list. But LOCAL is
presumably querying the domain system because it didn't know what to
do with a message addressed to REMOTE. Clearly something is wrong.
How a mailer chooses to handle these situations is to some extent
implementation dependent, and is thus left to the implementor's
discretion.
If the list of MX RRs is not empty, the mailer should try to deliver
the message to the MXs in order (lowest preference value tried
first). The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable. Note that
multiple MXs may have the same preference value. In this case, all
MXs at with a given value must be tried before any of a higher value
are tried. In addition, in the special case in which there are
several MXs with the lowest preference value, all of them should be
tried before a message is deemed undeliverable.
Partridge [Page 5]
RFC 974 January 1986
Mail Routing and the Domain System
Minor Special Issues
There are a couple of special issues left out of the preceding
section because they complicated the discussion. They are treated
here in no particular order.
Wildcard names, those containing the character '*' in them, may be
used for mail routing. There are likely to be servers on the network
which simply state that any mail to a domain is to be routed through
a relay. For example, at the time that this RFC is being written, all
mail to hosts in the domain IL is routed through RELAY.CS.NET. This
is done by creating a wildcard RR, which states that *.IL has an MX
of RELAY.CS.NET. This should be transparent to the mailer since the
domain servers will hide this wildcard match. (If it matches *.IL
with HUJI.IL for example, a domain server will return an RR
containing HUJI.IL, not *.IL). If by some accident a mailer receives
an RR with a wildcard domain name in its name or data section it
should discard the RR.
Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
a alias and the alias is listed in the MX records for REMOTE. (E.g.
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
can be avoided if aliases are never used in the data section of MX
RRs.
Implementors should understand that the query and interpretation of
the query is only performed for REMOTE. It is not repeated for the
MX RRs listed for REMOTE. You cannot try to support more extravagant
mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX
for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
but this does not mean that UNIX.BBN.COM accepts any responsibility
for mail for .IL).
Finally, it should be noted that this is a standard for routing on
the Internet. Mailers serving hosts which lie on multiple networks
will presumably have to make some decisions about which network to
route through. This decision making is outside the scope of this
memo, although mailers may well use the domain system to help them
decide. However, once a mailer decides to deliver a message via the
Internet it must apply these rules to route the message.
Partridge [Page 6]
RFC 974 January 1986
Mail Routing and the Domain System
Examples
To illustrate the discussion above, here are three examples of how
mailers should route messages. All examples work with the following
database:
A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG
A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG
A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG
A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP
B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG
B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG
B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP
C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP SMTP
D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG
D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP
In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
query, it learns that A.EXAMPLE.ORG has three MX RRs. D.EXAMPLE.ORG
is not one of the MX RRs and all three MXs support SMTP mail
(determined from the WKS entries), so none of the MXs are eliminated.
The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
lowest valued MX. If it cannot reach A.EXAMPLE.ORG it can (but is
not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
responding, it can try C.EXAMPLE.ORG.
In the second example, the mailer is on B.EXAMPLE.ORG, and is again
trying to deliver a message addressed to A.EXAMPLE.ORG. There are
once again three MX RRs for A.EXAMPLE.ORG, but in this case the
mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
B.EXAMPLE.ORG). It is left only with the RR for A.EXAMPLE.ORG, and
can only try delivery to A.EXAMPLE.ORG.
In the third example, consider a mailer on A.EXAMPLE.ORG trying to
deliver a message to D.EXAMPLE.ORG. In this case there are only two
MX RRs, both with the same preference value. Either MX will accept
messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
and if that delivery fails should try the other MX (e.g.
C.EXAMPLE.ORG).
Partridge [Page 7]
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (06/09/89)
In article <882@adobe.UUCP>, greid@adobe (Glenn Reid) writes: >The bangity!bangity!user stuff is pretty crude, but it was very >reliable in terms of reversing the path and getting mail returned to >the sender. That's valuable, in my opinion. And sorely missed in >today's world. You forget about gateways. How would you send mail to someone on some private network that had to be routed thru an internet gateway? And do you REALLY expect the return address to work? I have had to put in several special rules to take mangled DECnet, internet, local, and UUCP addresses into some reasonable internal form so that pure UUCP sites can, I hope, use some of the return paths. I hope I got all of the cases right, but I still find the most goddawful mangled addresses, say bitnet to UUCP to internet to GE DECNET. I recall one so bad that I had no idea what host the message came from. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP
ulmo@ssyx.ucsc.edu (Brad Allen) (06/10/89)
> I agree and why in the h___ did it have to change? If it isn't > broken, don't fix it. Three things: - It is better to plan ahead than to wait for problems in my book. - Number of UUCP hosts was increasing, so the number of names and the size of the data to keep track of them has gotten too big for most hosts to handle. - The ARPAnet (now the Internet) predates UUCP, is more official than UUCP, ran into these problems (even worse than UUCP did) before UUCP did, and fixed these problems independently of what UUCP did. There are also more Internet hosts than UUCP hosts. Now, it is standard. Remember, fitting into Internet is current trend. Next is ISO. At least with Internet, UUCP is pretty viable, but with ISO UUCP is just going to be plain silly if it works at all. I think the general concensus is "If you want to stay in the dark ages, you have that right."
s160057@castor.ucdavis.edu (What? Me worry?) (06/11/89)
>- Number of UUCP hosts was increasing, so the number of names > and the size of the data to keep track of them has gotten too big > for most hosts to handle. This still is the case. I'm in favor of limiting the number of map entries each organization / person is allowed, to say two or three. The maps files are *not* meant for LAN information, regardless of what the readme file says. There is limited namespace in UUCP's flat world.. >- The ARPAnet (now the Internet) predates UUCP, is more official than UUCP, > ran into these problems (even worse than UUCP did) before UUCP did, > and fixed these problems independently of what UUCP did. > There are also more Internet hosts than UUCP hosts. Now, it is standard. Yet, in this domain-oriented world, the UUCP maps keep tabs on things I consider as important as routing - responsibility, connectivity.. >Remember, fitting into Internet is current trend. Next is ISO. >At least with Internet, UUCP is pretty viable, but with ISO UUCP is just >going to be plain silly if it works at all. You should distinguish between Internet machines, connected with TCP/IP, and machines using registered domains. Few if any .us machines exist on the Internet (I cannot think of any). I think one of the major problems is an inability of small, independent operators to connect to the Internet. Personally, I don't think ISO has a snowball's chance in the United States. At the rate domains are being adopted, things can only get better. "Once an entrenched domainist, always an entrenched domainist.." >I think the general concensus is "If you want to stay in the dark ages, >you have that right." However our machines will retain the right to bounce your mail.. UUCP in its current state is broke. It's up to all of us to fix it. "I'm all lost in the supermarket.." - The Clash / s160057@castor.ucdavis.edu