[bit.listserv.pmdf-l] Message-Router channel, requirements

tinkelman@CCAVAX.CAMB.COM (Bob Tinkelman) (02/03/90)

A month or so ago, I posted a query regarding MRchan, a PMDF
Message-Router-channel that we had written here at CCA, and were in the
process of enhancing.  I asked for input as to what features were
desirable/necessary.  I received an encouraging number of replies, some of
which lead to extended mail discussions of some of the issues and tradeoffs
involved.  In my original posting I promised to compose a summary of the
responses.  There certainly appears to  be sufficient interest to post it
to the list.  So here it is.

First, a couple of the respondents were interested only in a full RFC987
compliant X.400-to-RFC822 gateway.  [Presumably, they're now interested
in an RFC1138 compliant gateway.]  We are *not* doing this.

To review, what we are trying to do is to write a PMDF-channel/MR-user-agent
which, together with PMDF, implements an RFC822-to-MailBus gateway with the
following basic properties:

1. Universality.  For any given legal 822-To-address, there should be a
   way for that address to be specified on the MR-side of the gateway.
   Similarly for the other direction.  [This does *not* say that your
   particular mailer will let you type it!  It says only that it is a
   legal 822 address (on the 822 side) or a legal Message Router route (on
   the MR side).]

2. REPLYability.  Mail passing in either direction across the gateway
   should be REPLYable.  With no special effort on the part of the mail
   sender, the gateway should transform any legal From-address on one side
   into a legal From-address on the other via an invertible mapping, so
   that a recipient of the mail can use the From-address as a To-address
   in replying to the originator.  [Like point 1 above, there is the
   proviso that you your mailer must let you enter the address.  For
   example, if you have an 8 character limit on what you can type, ...]

3. Domain names.  Postmasters should be able to configure the gateway so
   that mail on the Internet side addressed to name@host will get delivered
   to a specified MailBus accessible system.  In addition, mail coming from
   that MailBus system should be delivered on the Internet side with a
   From-address in the domain form, name@host.  [Our scheme requires the
   postmaster to specify, in PMDF.CNF, the correspondence between domain
   name and MR-route on a per-host basis.  These specifications are *not*
   required for Universality or REPLYability.]

I had asked about the interest in using MRchan as a `bridge' between MRs on
different DECnets.  Only one or two respondents had an interest in this.

Two people brought up the issue of encoding binary files (like WK1 format
Lotus 123 spreadsheets) before transferring them from the MR side to the
PMDF side.  We hadn't given this any thought.  Presumably it would be of
use only in configurations where we were bridging isolated MailBus
networks.  Or (please tell me) is there any standard out there for using
UUENCODE (or something else) and marking the mail header so that a
recipient mail system can recognize that the mail has to be UUDECODEd?
One person suggested a mail header of the form ``X-Encoded: Uuencode''.

I asked about the inverse configuration - using a MailBus network as a
transport between two PMDF sites.  This would be a little strange.
Nobody expressed any interest.

I asked about the issue of handling the general tree-structure of MR
messages.  Nobody seemed to want anything more than a conversion of these
to flat text files with human readable separators (like a line of dashes
and the text ``Attachment'').  Nobody seemed to require that an originator
on the Internet side be able to compose a mail message which would be
delivered, on the MR side, with multiple message parts.

I had asked about integration with DEC's Distributed Directory Service.
Nobody seemed interested in this.

Nobody who responded used DEC's MailBus Monitor software.

Most everyone who responded used Message Router only for ALL-IN-1.

I would like to thank everyone who responded to my original posting.
We are not yet ready to send out software to beta-test sites.  (Real work
continues to interfere with progress.)  I'll send further mail where we
are.  If anyone else is interested in being a beta-test site, please send
me mail describing your configuration.  Also, any other/further feedback
would be helpful and most welcome.
--
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830
bob@ccavax.camb.com  or ...!uunet!ccavax!bob