Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!cak@purdue.ARPA From: cak@purdue.ARPA (Christopher A. Kent) Newsgroups: net.mail.headers Subject: Re: Mail Domain Names: Host table vs. Nameservers Message-ID: <2632@brl-tgr.ARPA> Date: Wed, 30-Oct-85 16:09:55 EST Article-I.D.: brl-tgr.2632 Posted: Wed Oct 30 16:09:55 1985 Date-Received: Sun, 3-Nov-85 07:17:04 EST Sender: news@brl-tgr.ARPA Lines: 68 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 ----------