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
----------