Xref: utzoo comp.emacs:5345 gnu.emacs:463
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!jr@bbn.com
From: jr@bbn.com (John Robinson)
Newsgroups: comp.emacs,gnu.emacs
Subject: Re: RMAIL file ---> UNIX mail file
Summary: Babyl predates berkmail; look to X400
Message-ID: <36061@bbn.COM>
Date: 15 Feb 89 22:22:45 GMT
References: <425@talos.UUCP> <69658@ti-csl.csc.ti.com> <434@talos.UUCP>
Sender: news@bbn.COM
Reply-To: jr@bbn.com (John Robinson)
Followup-To: gnu.emacs
Organization: BBN Systems and Technologies Corporation, Cambridge MA
Lines: 59
In-reply-to: kjones@talos.UUCP (Kyle Jones)

In article <434@talos.UUCP>, kjones@talos (Kyle Jones) writes:
>In article <69658@ti-csl.csc.ti.com>
>  Paul Fuqua gives reasons for RMAIL's use of BABYL files:
>
>> 1.  Compatibility with Babyl, the ITS/Twenex Emacs mail-reader, which
>> brings with it compatibility with lispm mail-readers.  (Wasn't Babyl's
>> ancestor named Rmail?)
>
>But isn't GNU Emacs primarily targeted at UNIX systems?  Specifically
>the BSD-like system that GNU will eventually be?  No UNIX system that
>I know of uses BABYL format mail files.

Emacs started with no rmail code, but it was easy to steal it from
elsewhere, namely the existing implementation on some random lisp
machine, which happened to be using Babyl format.  This is not an
endorsement of that, or an anti-endorsement of Berkeley mail; it just
happened.  Yes, Babyl's predecessor on ITS/Twenex was named rmail.
The grandaddy of them all was called readmail, and its buddy was
sndmsg.

At a more general level, GNU emacs' target is GNU, alias "GNU's not
Unix".  I suspect the mail "standard" for GNU is not settled yet.  If
a package were available under the FSF terms and conditions, and it
happened to have good functionality, and it happened to use Babyl
format and not Berkeley mail, I have no doubt what GNU Unix would
offer.  Given the tahoe effort, though, Berkeley may already be
available under the right terms, so perhaps FSF would like to change
over.

>	 If I were writing RMAIL again I wouldn't have it use the
>BABYL format at all, even internally.

I doubt anyone else would either, but I suspect Babyl/rmail predates
GNU emacs.

>At one point I attempted to rewrite the existing RMAIL to use the
>RFC822 message format but was confounded by the fact that the BABYL
>file dependencies are scattered throughout.  I now believe rewriting
>it from scratch would be the most expedient solution.

If you step back (again), you would look around for more modern models
of how mail ought to be done (independent of whether it is accessed
from inside emacs, or what machine is hosting the service).  This
would lead you to X.400, an international standard set that provides
for electronic mail.  The implementation model is like what we are
running on machines here at BBN - MMDF is the mail delivery agent, and
MH is the mail user agent.  Separating these groups of functions is
crucial.  In emacs, mh-e is an interface (front-end, really) to the MH
user agent software.  In principle, you could write all the support
directly in elisp, but mh-e doesn't use that approach.

The internet is working out a transition plan for X.400.  At some
point it will supplant RFC822.  There will be gateways between the two
for quite a long time.

I have redirected followups to gnu.emacs.
--
/jr
jr@bbn.com or bbn!jr