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!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!ucbvax!ucdavis!lll-crg!seismo!brl-tgr!tgr!netinfo%ucbjade.ucb-vax.arpa@BRL.ARPA From: netinfo%ucbjade.ucb-vax.arpa@BRL.ARPA (Postmaster + BITINFO) Newsgroups: net.mail.headers Subject: Re: Implementing Mail Domain Addresses and Nameservers Message-ID: <2156@brl-tgr.ARPA> Date: Wed, 16-Oct-85 02:28:01 EDT Article-I.D.: brl-tgr.2156 Posted: Wed Oct 16 02:28:01 1985 Date-Received: Fri, 18-Oct-85 02:06:33 EDT Sender: news@brl-tgr.ARPA Lines: 112 Mark, First I would like to say that I am not flaming but trying to find solutions to a problem that affects all users of the Internet mail system. In reply to: From @MIT-MC.ARPA:CRISPIN@SUMEX-AIM.ARPA Sat Oct 12 11:11:36 1985 Date: Sat 12 Oct 85 10:55:19-PDT From: Mark Crispin Subject: Re: Implementing Mail Domain Addresses and Nameservers To: header-people@MIT-MC.ARPA In-Reply-To: <8510120929.AA09637@ucbjade.Berkeley.Edu> Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-Id: <12150570156.19.CRISPIN@SUMEX-AIM.ARPA> Two suggestions: 1) avoid provoking the issue during a transition period; Which issue? Are referring to the mail addressing problem created by the partial transition to full domain names? (I would prefer to recognize that we have a major network problem and try to find some solutions, rather than closing my eyes to problem and praying that it will go away.) retain some set of names that are major mail agents and use those names. Please explain in more detail. If there is a solution here, I am interested. Address other problems as they come up, Isn't that what I am doing? and otherwise make the software reliable enough that widespread adoption of domains can be done with confidence. I do not have control over any of the software being developped, but I hope the developpers are listening. Attempting to "force" production networks into using unproven software is a waste. Where did you get the idea that I was trying to do this? The local internet and the systems I use at Berkeley are production systems. (By the way I have the same reaction to some of the software that comes out of AT&T and Berkeley's CSRG group. It took one of our system programmers 6 months to debug BSD 4.2 Mail version 2.18 so that it would work in our local mail environment.) As a Naval Reserve communications specialist I am very concerned about anything that degrades service on the DDN. I made two suggestions that should not affect DDN. I am interested in hearing comments on these suggestions. Are they workable? (1) A source routing addressing kludge affecting the MAIL FROM and From: fields which defeats domain addressing between local domains (and between the DARPA research community sites and DDN sites), but permits full domain names within the local mail domain and does not require all local hosts to be registered in the master host table, for example: From: Bill Wells <@Berkeley.EDU:wcwells@ucbopal.Berkeley.EDU> (2) Establishing Mail Transport Agents (Mail Gateways) on the DARPA/DDN "mail bridges" to handle the differences in mail addressing between the two parts of the Internet mail system. That is, instead of the Berkeley mail transport agent adding the source routing, the mail bridge gateways would add the source routing. This would allow the DARPA research community part of the Internet mail system to use nameservers without affecting the DDN. 2) flush mailboxes such as netinfo@ucbjade.Berkeley.EDU which are completely ridiculous to mail to. A more reasonable address would be "Bill Wells"@Berkeley.EDU, which hopefully some reasonable mail user interface can arrive at by sending mail to "Bill Wells"@Berkeley. Of course, this means thinking about the semantics of mailboxes as something other than login user names. Well dreams are nice. But the reality is that even the US Postal Service needs a post office box or street address. This suggestion ignores the fact that