Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pacbell!pbhyf!rob
From: rob@pbhyf.PacBell.COM (Rob Bernardo)
Newsgroups: comp.mail.elm
Subject: Re: RFC 987, 1026
Message-ID: <4833@pbhyf.PacBell.COM>
Date: 15 Mar 89 19:52:35 GMT
References: <1611@raspail.cdcnet.cdc.com>
Reply-To: rob@pbhyf.PacBell.COM (Rob Bernardo)
Organization: Pacific * Bell, San Ramon, CA
Lines: 25

In article <1611@raspail.cdcnet.cdc.com> steve@raspail.cdcnet.cdc.com (Steve Schonberger) writes:
+Are there any plans to extend elm to support RFC 987 and 1026?  Those
+are the documents that suggest a format for gatewaying between RFC 822
+mail (what elm is designed for) and x.400 mail.  Most of the differences
+aren't real significant, so it probably wouldn't requre a lot of change
+to elm.  It would be neat to have the best RFC 822 mailer also be the
+best x.400 mailer.  (I'm assuming that if it were used in x.400 mode it
+would be operating with a system agent that took the readable equivalents
+of all the x.400 headers, rather than the binary junk.)  What's everyone
+think of this idea?

I'm only getting the gist of what you're getting at, not being familiar
with the RFC's mentioned. Since you're talking about gatewaying between
RFC 822 and x.400 mail, wouldn't that be the responsibility of the
mail transport agent rather than the user interface program?

Btw, I know that "mail transport agent" is the technical expression
used to refer to such programs as rmail, sendmail, etc. What is
the equivalent technical expresion used to refer to the user
interface programs (e.g. mailx, elm, mh)?
-- 
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email:     ...![backbone]!pacbell!pbhyf!rob   OR  rob@pbhyf.PacBell.COM
Office:    (415) 823-2417  Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301  R Bar JB, Concord, California