Lovstrand.pa@XEROX.ARPA (10/16/85)
> 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. It also means fixing Unix to > comprehend spaces in mailbox names, something that appears impossible > to do (even though every other operating system has). Although I definitely agree with Mark that RealName@Organization is better than RandomUser@SomeLocalHost.Organization, I don't like to rule out the possibility of sending explicitly addressed mail. IF there exist some local organizational space THEN you should be able to explicitly address some random recepient in that space. In the case of Berkeley, they happen to have a bunch of physical machines in their local space, so alright, why not be able to use that? When it comes to choosing between different formats for RealUser, I prefer Lennart.Lovstrand@LiUIDA.UUCP (which is my home address (yes, I *do* know that UUCP is not a "real" domain)) in favor of "Lennart Lovstrand"@LiUIDA.UUCP. I know that both are perfectly legal with respect to RFC822, but the former feels more in the flavor of the format ...and is perfectly simple to use with Unix/Sendmail. ;-) --Lennart (Postmaster@LiUIDA.UUCP when not at Xerox PARC) The previous statements are of my personal opinion and has no connection to those of Xerox Corp.
netinfo%ucbjade.ucb-vax.arpa@BRL.ARPA (Postmaster + BITINFO) (10/16/85)
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 <Crispin@SUMEX-AIM.ARPA>
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 thatmcb@lll-tis-b.ARPA (Michael C. Berch) (10/16/85)
> From: Mark Crispin <Crispin@SUMEX-AIM.ARPA> > . . . > 1) avoid provoking the issue during a transition period . . . > > 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. It also means fixing Unix to > comprehend spaces in mailbox names, something that appears impossible > to do (even though every other operating system has). I'd also avoid provoking the issue of mailbox names (local-parts) during a transition period. Notwithstanding the differences between the right-hand-parts of the two examples given, why is it necessary to deal with the local-part at this point? What is the matter with a symbolic mailbox name? I agree that UNIX mailers should be able to reliably deal with spaces in local-parts, but what does this have to do with doing away with symbolic mailbox names, such as those interpreted by sendmail? We use dozens of them for mailing lists and so forth. As in the netinfo example, they might also be useful for shared "official" accounts. What's the problem? I'd rather send mail to "netinfo" and have it answered, than sent to "Bill Wells" and find out he's on vacation. Michael C. Berch mcb@lll-tis-b.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb
netinfo%ucbjade.ucb-vax.arpa@BRL.ARPA (Postmaster + BITINFO) (10/16/85)
Would MAIL FROM:<@Berkeley.EDU:unknownhost.Berkeley.EDU> be an acceptable short term solution for mail sent from UC Berkeley? ----- Now, in reply to: Date: Fri 11 Oct 85 19:19:13-PDT From: Mark Crispin <Crispin@SUMEX-AIM.ARPA> Cc: header-people@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: +1 (415) 968-1052 Message-Id: <12150399743.19.CRISPIN@SUMEX-AIM.ARPA> Rather than flaming about flaming, lets come up with some solutions. A centrally maintained host table is soon going to become to big to manage effectively. (At Berkeley we expect to have over 3000 "hosts" in the next couple of years.) So the Internet world is moving towards distributed nameservers. General working policy is that the experimental side of the Internet (the ARPANET backbone and friends) develops and debugs the system before it is adopted by the operational side of the Internet (the Milnet backbone and friends). This is the assumption of RFC 921 which planned for completion of the Domain Naming System by 15 July 1985 and decommissioning of the host tables for the DARPA research community (non-DDN) on 15 September 1985. Up to 15 Sep 85 we could have software that assumed the Internet mail system was one mail system. That is no longer true. Read the appropriate documents regarding the status of domains on the Milnet. I would not assume that the DARPA research community gets all the documents about the DDN. (Which documents by the way? DDN newsletter?) Domains have *not* been officially adopted as a naming registry that the entire Internet must use. I am not sure what you are trying to say here. Domain "host" names are being put in both the host table and nameservers for use by the entire Internet. So I must assume you are saying that domain nameservers are not currently operational on the DDN and implementation may, or may not be scheduled for the DDN. You can NOT go sending out headers with non-registered names to Milnet. Here is where we have a problem. First, lets change Milnet to all DDN operational nets and ask how a non-DDN site determines if a host is a DDN host. What about hosts that are on both a DDN net and on a DARPA research community net, how do you determine which type of address to send. The world is not simple anymore. Add another complication, with the implementation of domain name servers the Internet mail system now extends beyond the physical Internet. Second, according to RFC 921 on 15 Sep 85 "the master host table maintained by the NIC need no longer be complete for the DARPA research community. A full table of the DDN hosts will be maintained by the NIC." To me, that means that DARPA research community sites only need to register names of mail domains and their nameservers. Now if NIC deletes all non-DDN hosts from the host table used by a DDN host, how is that host going to know if the return mail domain is registered or not? Somewhere along the line, I think the Internet mail developers forgot to deal with this issue. ... while some part of the network is stuck with the host table as a registration authority the maintainers of software on that network have to continue to support that environment. True, within that part of the network, but not necessarily for the rest of the Internet. What if we follow the original plan and have two logical Internet mail systems, one using host tables and one using nameservers? Is the source routing kludge <@known-nameserver-domain-host:localmailbox@unknowndomain> sufficent, or do we implement Mail Transport Agents on "mail-bridge gateway" hosts that know about both sides of the Internet mail world? Bill Wells postmaster%ucbjade@Berkeley.EDU BITINFO@UCBJADE.BITNET <@Berkeley.EDU:postmaster@ucbjade.Berkeley.EDU> ??
Crispin@SUMEX-AIM.ARPA (Mark Crispin) (10/16/85)
Two suggestions:
1) avoid provoking the issue during a transition period; retain
some set of names that are major mail agents and use those names.
Address other problems as they come up, and otherwise make the software
reliable enough that widespread adoption of domains can be done with
confidence. Attempting to "force" production networks into using
unproven software is a waste.
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. It also means fixing Unix to
comprehend spaces in mailbox names, something that appears impossible
to do (even though every other operating system has).
-------