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!mcb@lll-tis-b.ARPA
From: mcb@lll-tis-b.ARPA (Michael C. Berch)
Newsgroups: net.mail.headers
Subject: Re: Implementing Mail Domain Addresses and Nameservers
Message-ID: <2158@brl-tgr.ARPA>
Date: Wed, 16-Oct-85 02:29:25 EDT
Article-I.D.: brl-tgr.2158
Posted: Wed Oct 16 02:29:25 1985
Date-Received: Fri, 18-Oct-85 02:07:43 EDT
Sender: news@brl-tgr.ARPA
Lines: 29

> 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