Re: RFC-1204: Message Posting Protocol (MPP)

Einar Stefferud <Stef@ics.uci.edu> Tue, 19 February 1991 06:30 UTC

Received: from dimacs.rutgers.edu by NRI.NRI.Reston.VA.US id aa09153; 19 Feb 91 1:30 EST
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24054; Tue, 19 Feb 91 01:19:37 EST
Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24050; Tue, 19 Feb 91 01:19:32 EST
Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14758; Tue, 19 Feb 91 01:19:23 EST
Received: from nma.com by nrtc.nrtc.northrop.com id ad13311; 18 Feb 91 22:17 PST
Received: from odin.nma.com by nma.com id aa00618; 18 Feb 91 22:02 PST
To: ietf-smtp@dimacs.rutgers.edu, Dave Crocker <dcrocker@nsl.dec.com>
Cc: David Herron <david@twg.com>, yeh@netix.com, Wai-Hung David Lee <dlee@netix.com>
Subject: Re: RFC-1204: Message Posting Protocol (MPP)
In-Reply-To: Your message of Mon, 18 Feb 91 11:35:36 -0800. <9102181935.AA02724@netix.com>
Reply-To: Stef@ics.uci.edu
From: Einar Stefferud <Stef@ics.uci.edu>
Date: Mon, 18 Feb 1991 22:02:08 -0800
Message-Id: <15281.666943328@nma.com>
Sender: stef@nma.com

It is important to note, though RFC1204 does not point this out, that
MPP is designed to provide a SPLIT-MUA POSTING service that
corresponds to the "SPLIT-MUA" DELIVERY services of MH POP3, in the
same operational context as POP3.

POP3 supports a remote MUA that is not co-located on the same host as
its MTA, and needs what X.400(88) calls a MessageStore (MS) server to
take delivery of incoming mail for later pickup by the recipient's
MUA, which may be offline for various periods of time.

Think of MPP as supporting a SPLIT-MUA POSTING process, with the
compose function on one host, and the rest of the posting process on
another host, with the MPP in between.

It does not need full SMTP.  It is deliberately intended to be less
than SMTP.  As David Lee pointed out, the MPP server may be
implemented with ALIAS address resolution, and all the rest of the
posting functions that are normally implemented in POST (e.g., MH
post).  One way to implement is to feed MPP messages to MH POST.  MPP
is not concerned with supporting all the address validation of SMTP.

For those who are interested, in X.400(88), the MessageStore-MUA mail
pickup relationship (corresponding to POP3) is supported with the P7
protocol, and Posting is supported with P3, which roughly corresponds
to SMTP, with some measure of authentication of the originator.

MPP is rather more pragmatic (and simple) than P3, in that it allows
more functions to be implemented on the POSTING SERVER than does P3.

P3 includes most of the P1 functionality, which is the full MTA-MTA
transfer protocol, and thus forces too much functionality to remain on
the MUA host, which then must make itself look much like an MTA,
though it is really just a poor little MUA that wants someone to post
its mail.

The authors of MPP did not want to make the error of letting MPP do
too much of SMTP.  After all, to get all of SMTP, use SMTP.

On this part of MPP I agree with the authors.  MPP is simply designed
to be a small gap filler for a functional arrangement that enables a
network of PC based MUAs to get by with only one POSTING server and
one POP3 server on a LAN.  In the process, it provides at least as
much security as does POP3 popwd, BUT NO MORE.  In fact, it uses the
same popwd as its passwd.

The main problem with MPP is that it is not very well explained.  It
is also rather loosely specified, in part because it is an incomplete
description of what a single specific implementation does, rather than
a specification for building implementations.

Best...\Stef