netinfo%jade@ucb-vax.ARPA (Postmaster + BITINFO) (10/30/85)
In reply to:
From @MIT-MC.ARPA:GEOFF@SRI-CSL.ARPA Tue Oct 29 00:06:43 1985
Date: 28 Oct 1985 23:17-PST
Sender: GEOFF@SRI-CSL.ARPA
Subject: Re: Mail to UC Berkeley hosts
From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
Cc: Header-People@MIT-MC.ARPA, MRC@SIMTEL20.ARPA
Cc: Postmaster@UCBVAX
Message-Id: <[SRI-CSL.ARPA]28-Oct-85 23:17:44.GEOFF>
In-Reply-To: <8510282352.AA28981@ucbjade.Berkeley.Edu>
First of all. Let's stop the shouting match. Shouting at me
(postmaster@ucbjade) is not going to solve anything.
I do not control the Internet gateway software at Berkeley,
"postmaster@ucbvax.Berkeley.EDU" does.
netinfo@jade.berkeley.edu, that's dumb thinking.
Sorry, but what is dumb? Certainly not full domain names which the Internet
has been working towards for years. (Read the RFC's for more information.)
Unfortunately, sites in the DARPA research community are caught in the
middle. One side we are being told to use full domain names (which
by the way we have been using within the BERKELEY.EDU mail domain for
years while we have waited for the rest of the Internet to get their act
together.) On the other hand, when UCBVAX switched to full domain names
names as mandated in RFC 920 and RFC 921, we found that even though RFC 921
was published in October 1984, software developers did not meet the scheduled
dates for implimentation of nameservers, and did not recognize the problems of
having part of the Internet using the nameservers and part using host tables.
Also sites have been slow in registering their new domain names.
The DARPA research community's shift to full mail domain names is based
on the following from RFC 921:
15 Jul 85 Implementation of the Domain Naming System Completed
The goal is to complete the switch over to the domain style names
and the use of the servers by this date. All programs that
translate host name to Internet addresses should now use
procedures based on the use of the domain style names system of
resolvers and servers and the distributed data base.
15 Sep 85 Decommission Host Table
At this point the master host table maintained by the NIC need no
longer be complete for the DARPA research community. A full table
of the DDN operational hosts will be maintained by the NIC.
15 Oct 85 DDN Plan for Domains Name Service
The DDN PMO may establish a plan for the future support of name to
address translations in the DDN community.
Note the actions scheduled for 15 Jul 85 and 15 Sep 85. I interprete
the actions that were scheduled to apply to all Internet mail hosts,
not just the sites in the research community. For example, if the
research community hosts are deleted from the master host table, how
are other sites on the Internet going to know what they are unless
they use a nameserver? My interpretation of the 15 Oct 85 was that
this refers to MILNET and other non-research sites changing their
names from @something.ARPA to @something.MIL, etc. Unfortunately,
some non-research sites interprete this to mean that they do not
have to switch over to using software that uses nameservers. Note
that the issue of switching to using nameservers is separate from
the issue of changing @something.ARPA to one of the new top domain
name addresses.
do you honestly expect every single user on the Internet to know
about your local routing hacks thru user%host@ucbvax.Berkeley.EDU
or ...@Berkeley.EDU or ...Berkeley.ARPA?? Really!?
You must be a newcomer to the net, for years UC Berkeley has been using
the % hack and until recently, our "From:" line addresses had the format:
<user%host@ucb-vax.ARPA>. One solution for Berkeley, MIT, Columbia,
and other sites having hosts in their mail domain is to go back to
using the % kludge address, but this solution is in conflict with
RFC 921 which call for a "complete the switch over to the domain style
names". (See how the research sites are caught in the middle again.)
heck, i couldn't even reply to your message because your
...@jade.berkeley.edu host isn't registered in the NIC. Foo!
Now for a legal issue. The 26 research hosts out of 300 plus hosts
at Berkeley that are registered are systems involved with ARPA grants
or other computer science research. Most of the users on these systems
are hopefully legal users of the US Defense Communications Agency Internet.
Most of the users on other systems at Berkeley are not. Host administrators
are suppose to restrict access to the USDCA Internet. How can we do that if we
register all hosts at Berkeley in the Internet host table? The answer is
(with current software) we can't.
Nameservers offer a method of registering hosts as mail only sites and
permit hosts which are in the local mail domain, but not on the physical
Internet, to be addressed. The host table restricts the mail domain to
hosts on the physical Internet.
Even with nameservers we have a problem. At Berkeley, the Berkeley
Internet is interconnected with the UCSF Internet. There are no "US
Government Business Only" restrictions between these nets. We want full
network services between these nets, but need to have mail only to
other "government" nets. So we can even put them in the nameserver
as mail only sites. I do not think anyone has come up with a
solution to this problem yet. In fact, the domain naming scheme does
not offer a solution for EDU sites. How do you determine which hosts
we are to restrict access to. (Actual we do not want to restrict access
but the only guidance I have seen is the DDN directory which says to
restrict access.) Perhaps that policy should be rewriten identifying
specific domains (eg. GOV, MIL) or specific nets (eg. MILNET).
what do you think someone like Bob Kahn or some other money bags
source on a MILNET host is going to do when he can't reply to
messages originated by hosts like yours at UCB which isn't
registed in the NIC's host tables (and doesn't know about your
special address "hack")??
I am flustrated by not being to use an automatic reply feature too.
Damn it, why don't you just register your hosts with the NIC and
make it easy for yourself, your correspondents and the rest of
the net??
See legal issue above. Of course I could ask the opposite question,
why don't you switch to software that uses a nameserver as mandated
by RFC 921? (No need to reply to that, I have already seen all the
answers to that earlier in this discussion.)
i seem to be gaining increased appreciation every day for SMTP
servers on hosts which *reject* incoming mail from hosts they
doesn't know about. SRI-CSL will join the ranks as soon as i
field one question from a user on how do they reply to a message
from one of your unknown hosts.
-------
I think the Internet world needs to recognized that the Internet Mail
world extends beyond the physical Internet.
I think we can declare RFC 921 a failure and recognize that having
part of the Internet using not using full domain names and a host table
and the other half using full domain names and nameservers is not
going to work. So it looks like it is back to % sign address kludges and
"no progress" in the implimentation of distributed domain servers
and full domain names until the whole internet starts using name servers.
I think some practical ideas for how to test out the name server
software with out a "complete shift" to full domain names is in order.
Also a revision to RFC 921 is needed.
Bill Wells
postmaster%ucbjade@Berkeley.EDU
PS. For those of you who want to do more reading about domains,
is a list of references.
-----------
RFC "Request for Comments" reports from the DDN Network Information
Center, SRI International, Menlo Park, CA are available to Internet
hosts by FTP from the ARPANET host SRI-NIC, and to CSNET members as
either electronic messages or paper copies from the CSNET CIC
<cic@csnet-sh>.
[1] RFC 822 "Standard for the Format of ARPA Internet Text Messages",
David H. Crocker, August 13, 1982. (Replaces RFC 733.)
[2] RFC 920 "Domain Requirements", J. Postel, J. Reynolds, October
1984. This memo restates and refines the requirements on
establishing a Domain first described in RFC-881. It adds
considerable detail to that discussion, and introduces the limited
set of top level domains.
[3] RFC 921 "Domain Name System Implementation Schedule - Revised",
Jon Postel, October 1984. (Updates RFC 897.)
[4] RFC-881 "The Domain Names Plan and Schedule", J. Postel, November
1983.
[5] RFC 882 "Domain Names - Concepts and Facilities", P. Mockapetris,
November 1983.
[6] RFC 883 "Domain Names - Implementation and Specification", P.
Mockapetris, November 1983.
[7] RFC 733 "Standard for the Format of ARPA Network Text Messages",
David H. Crocker, John J. Vittal, Kenneth T. Progran, D. Austin
Henderson, Jr., 21 November 1977.
[8] 921ISO, "Codes for the Representation of Names of Countries",
ISO-3166, International Standards Organization, May 1981.leiner@RIACS.ARPA (Barry Leiner) (10/30/85)
Bill, You have it basically correct. However, let me once again (see my note of a few weeks ago) try to explain what is supposed to be happening. 1. ALL hosts on the internet have to be able to deal with domain style names if they want to be able to talk with anyone else. Therefore, there should not be a part of the internet that uses a host table and not full domain names. 2. Hosts that rely on using the host table may not have the capability of communications with all hosts (particularly some of those that rely on host tables rather than domain servers). This is mainly due to limitations of the host table paradigm and is the main reason for going to domain servers in the first place. 3. The NIC is doing what they can to mitigate the effects of (2). However, they clearly are not going to be successful in achieving full capability between all hosts using domain servers and all hosts using host tables. Therefore, once the "research" community has proven the concept of domain servers, I would anticipate many if not most of the remaining sites will switch to using domain servers. 4. In the meantime, users that are on hosts that rely on host tables and that want to communicate with sites that are not in the host tables really have no option other than to push their system developer/maintainer to put in place domain nameserver capability. Hope this helps. Barry ----------
jad@purdue.ARPA (John A. Dilley) (10/30/85)
Well, looks like this one was able to be replied to. Good. So how about if some diligent persons on the Internet implement and debug name servers, and then pass the source to other sites? With any luck, the (already overworked) sys.admins will be able to bring it up without too much trouble; not nearly as much as having to implement it all themselves, which admittedly is quite a task. I suspect that there are enough sites short of manpower to keep this thing from getting off the ground on schedule. Am I right, or are there [research community] hosts that just don't *want* to convert? For now, of course, the undesirable '%' kludge *must* be used. It's nice that Cal is so far ahead of the game that they've had domains working locally for years. But as we've seen you can't force it on the Internet, even if it should be out there and working weeks ago (according to RFC 921). Is it possible for those who are with it to help out those behind? If we could do this it might even convince the DDN people that it can be done smoothly, and that our national defense systems won't be out to lunch for a month cause nobody can look up hosts ;-) Of course there are serious problems to be worked out (some local ones which you pointed out, and others)... I know that research community is stuck in the middle, it's not their fault, etc. etc. How can we help get this worked out? We don't need any more finger pointing, name calling, or blame shifting. We do need working electronic communication networks. -- jad -- John A Dilley ----------
don.provan@cmu-cs-a.ARPA (10/30/85)
I think it's safe to say that Mr. Goodfellow has been active in the network long enough to know about Berkeley's "%" hack. How long have *you* been around that you aren't aware of how long Mr. Goodfellow's been around? At any rate, he isn't concerned about mail he receives. He's concerned about mail his users receive, even the ones that have been around many years but don't happen to read lists like this. In fact, I think it's insulting to try to trivialize this problem to a claim that "any smart person should know how to do it. Don't you?" As to the legal aspects, you obviously are failing completely on that score. You've already allowed a piece of mail to go out from an unauthorized user. Now you claim that, since that user is unauthorized, an authorized user should not be allowed to reply? Get your head out of your. If you've taken steps to prevent access without a name, it shouldn't matter whether or not I have a name. If you haven't taken such steps, then it doesn't matter whether or not I have a name, since I can use a number. But to try to claim that mail sent out should be allowed to have illegal names because the sites are illegal shows some sort of brain damage. I'd say that schedule is obsolete. That doesn't mean the project's been dropped, it just means it's behind schedule. If I were you, I'd be more concerned with providing good service than with standing on a soap box.
cak@purdue.ARPA (Christopher A. Kent) (10/31/85)
This is, I hope, not just a further contribution to the shouting match, but rather an attempt to examine "what's so" about the situation with nameservers, the lack of them on DDN hosts, and Berkeley's headers. First, some bottom line assertions/facts: * Berkeley is sending mail that cannot be replied to. * There is a solution to this that does not require the % hack. * MILNET/DDN hosts aren't required to run domain-based mail. I don't think anyone will argue with the first point -- Berkeley hosts are sending out mail from sites that aren't in the NIC's host table, and there are many hosts that rely on this host table as their only method of mapping from name to Internet number, and *are not required to do otherwise.* Therefore solutions of the form "why don't you switch to software that uses domain namesolvers" are not acceptable. A solution to the problem is for Berkeley to register hosts that are going to originate Internet mail with the NIC. (Please note that I make a distinction between Internet and internet -- Internet is the DARPA-funded collection of networks; internet is any collection of interconnected networks, not necessarily restricted to those running the IP family of protocols.) The argument made by Bill Wells against this was that there are 300 or more hosts on the Berkeley internet, and that many/all of the users on those hosts are not authorized users of the DARPA Internet, so he doesn't want to register all those hosts. I couldn't agree more. But the next step must also be taken -- if the users aren't authorized, don't let their mail (or packets) leak into the Internet. Do whatever you like in your internet or any internets to which you are connected, but observe the ground rules of being part of the Internet. Admittedly, this is not easy in the 4.2 world, because the software isn't set up to do it. We at Purdue are in a similar situation, and have two partial solutions: networks that are comprised entirely of non-authorized hosts don't get routing information about anything outside of our internet. Hosts that have a mix of authorized and non-authorized users have software that checks each user's authority to send packets off-internet (to be specific, there's a group "arpa" and if you are authorized, you're in it; there's a table of nets in the kernel that are off-limits to non-members.) It's ugly, but it works. I, too, would prefer not to have to restrict access. But that is one of the rules of the game, and it can't just be wished away. We must abide by it. This doesn't cover all the cases -- unfortunately, mail addressing formats are rich enough that relaying is possible, and it doesn't always get caught. People here are working on changes to sendmail to allow these cases to be trapped automatically; until then, we are vigilant and pounce on violators. Saying "users need to know how to turn netinfo@jade.BERKELEY.EDU into netinfo%jade@BERKELEY.EDU" is just plain unfriendly, and not a workable solution. I don't think I need to say more about it. On to the third point. DARPA research internet hosts are required to convert to using domain names and domain namesolvers. The DDN/MILNET hosts aren't. The implementation schedule in RFC921 has slipped a bit. Those are a few more facts of life for the time being. Rather than throwing up our hands and saying "it won't work unless everyone runs domain namesolvers", why not take this on as a challenge -- see what we can do to make it all work within the rules? Cheers, chris ----------
netinfo%ucbjade@ucb-vax.ARPA (Postmaster + BITINFO) (10/31/85)
In reply to: Date: Wed, 30 Oct 85 12:40 EST From: don.provan@a.cs.cmu.edu Message-Id: <30Oct85.124052.DP0N@A.CS.CMU.EDU> .... But to try to claim that mail sent out should be allowed to have illegal names because the sites are illegal shows some sort of brain damage. Where did you get the idea that I was saying that? The point that I was trying to make was that RFC 921 put use in the position of implimenting one set of addresses on one part of the internet mail system, and another set on the other part of the internet mail system, without separating the the mail system into two separate functioning parts. This has cause several problems. One solution I offered earlier was to logically separate the two system and have mail gateway(s) between the two which would put full domain addresses in messages going to the non-nameserver side into an form acceptable to the side of the mail system using host tables. One method to do this is to source route the addresses going to host table sites with the @domain-address of the mail gateway (which would be registered in host table). Does anyone have any comments on using this method to test out the nameservers on the research side of the house without interferring with the operational side of the house? Bill Wells postmaster%ucbjade@ucbvax.Berkeley.EDU
netinfo%ucbjade@ucb-vax.ARPA (Postmaster + BITINFO) (10/31/85)
Good news. I have been advised by a mail systems guru at UCBVAX that UCBVAX is now sending out mail from hosts not in the NIC host table in the format: user%host@Berkeley.EDU At least that solves the short-term problem for the sites still using the NIC host tables. Bill Wells postmaster%ucbjade@Berkeley.EDU
netinfo%ucbjade@ucb-vax.ARPA (Postmaster + BITINFO) (11/02/85)
I am not soapboxing. But it is interesting to note that when I asked for solutions, I received "flaming" messages; and when I tried to help a remote user with mailing to Berkeley, I got blasted. I think all of us are flustrated by problems caused in part by different interpretations of RFC 921. I am also concerned about the mail that my users are receiving or not receiving. I also recognize the changes happening on UCBVAX which cause problems to the mail system are hurting the users at Berkeley more than they are the rest of the net. Believe me, I get it from both sides because I am the primary person at Berkeley answering users' questions about network mail. Enough said about that. --------- Now on to solutions. A) In regards to: <@nic-host-table-domain-address:user@unknown-domain-name> or <@ucbvax.Berkeley.EDU:user@unknown-host.Berkeley.EDU> One solution I suggested for fixing UCBVAX's "From" lines was to do source routing, however I received a reply from software implimenter that all hosts had to be registered in because his software validated both sides of the colon in a source routed address. Unfortunately, this restriction presents a problem for sites that have more than one type of network. (Here at Berkeley we have hosts linked by local IP nets, UUCP, HASP, and Berknet links. Columbia has their CCnet. LBL/SLAC have sites on the PhysNet DECNET) It is not possible for non-internet nodes to be registered in the host table since they do not have an Internet network address. I prefer source routing to the % sign addressing kludge, so I suggest that domain name validation only be do on the first @domain-name in the "route" part of source routed address. This change would greatly help mail gateways to other networks that do not support Internet domain address, for example: <@wiscvm.wisc.edu:user@node.BITNET> or <@CS.NET:user@host> B) Although the mail only entry in nameserver data base can be used to identify the internet gateway for a non-internet host, I would also like to be able to tag certain internet hosts as not being able to receive mail to prevent SMTP process from being attempted. And then use an mail only entry to specify the mail route to be taken. I am not sure if the first is currently possible, the latter can be accomplished through requiring MTA programs to check for mail only records in the nameserver first. This is important for us and other sites that have low speed IP links so that mail traffic can be routed not to fill up a narrow channel and degrade other network services across that channel. For example, a site may want to give better service to "ftp" and route mail traffic via an alternate route. Bill Wells postmaster%ucbjade@ucbvax.Berkeley.EDU
Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow) (11/02/85)
Bill Wells: Being equally concerned as you are with the mail your users are receiving or not receiving (and their ability to reply or not to reply), i'm appreciative the fix recently (re-?)installed at UCB allowing me (as well as my users) to reply to messages like yours. A hearty thanks for the prompt action taken (in spite of flames). Yours in new and better ARPANETing, (since '73), g
Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (11/04/85)
Chris, watching the discussion from the side I think that your major problem is that you (using the RFC protocols) are trying to solve two problems: 1 - aid in routing matters 2 - impose political restrictions In (1) you will certainly get a situation that is easier to manage when we see more names of the form Don.Provan@A.CS.CMU.EDU, the more levels in the naming hierarchy the higher degree of freedom to implement msg transportation rules for real INTERnetworking. But there is a drawback that is soon (if not already) going to show up: your host tables will grow immensely if you everywhere are required to retain all the information everywhere. Given that you could consider CMU (as an example) infrastructure as an internal matter there would not be a need for you at Purdue to know more than the ADDRESS of CMU.EDU, further distribution is a matter of CMU (as in the case John-Doe%A.CS@CMU.ADU). Comparison with the %-convention reveals that the @-sign should neither have to be that holy, could be interchanged with a dot and there we would have a simpler name structure. Problem (2) is (if I haven't completely misunderstood everything) being imposed (or intended to be) by the fact that all legal hosts should be in some specific host table, thereby disallowing non-registred ones. This can work as long as the number of hosts is small enough, but again (considering workstations etc) is rapidly growing. I agree completely with you that it should be a responsibility of the gatewaying host that grants or denies certain accesses, distribution being the key-word. Finally, I assume that you all know about the CCITT activities on Directory Systems? Two of the members in that Special Rapporteur group are Jim White and Dave Crocker, a fact that should guarantee that experiences and requirements from the DoD Internet environment are considered. I am rather optimistic about that they can come up with a Recommendation that could be universally useable, just WE ALL make sure to give contributions in appropriate ways in time. Cheers, Tommy