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

Shannon Yeh <yeh@netix.com> Wed, 20 February 1991 00:03 UTC

Received: from dimacs.rutgers.edu by NRI.NRI.Reston.VA.US id aa18649; 19 Feb 91 19:03 EST
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20883; Tue, 19 Feb 91 18:47:01 EST
Received: from NETIX.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20870; Tue, 19 Feb 91 18:46:50 EST
Received: from localhost.netix.com by netix.com (4.1/SMI-4.0) id AA00642; Tue, 19 Feb 91 15:40:49 PST
Message-Id: <9102192340.AA00642@netix.com>
To: Stef@ics.uci.edu
Cc: Dave Crocker <dcrocker@nsl.dec.com>, ietf-smtp@dimacs.rutgers.edu, David Herron <david@twg.com>, Wai-Hung David Lee <dlee@netix.com>
Subject: Re: RFC-1204: Message Posting Protocol (MPP)
In-Reply-To: Your message of "Tue, 19 Feb 91 14:41:31 PST." <15790.667003291@nma.com>
Date: Tue, 19 Feb 1991 15:40:45 -0800
From: Shannon Yeh <yeh@netix.com>

Thanks, Stef. I am watching what's going on here everyday, and my name does 
exist in the smtp mailing list. When we prepared the rfc draft, we tried to
make it as simple as possible (I originally tried to name the protocol as
"Simple Message Posting Protocol (SMPP)".). Because we did not like to 
break SMTP itself. 

As of the security, it can, and only can be provided by physically isolating 
the toys (Do not let them touch it). Otherwise, any type of security protocol 
can be fouled by hackers who can be previleged users. So, what we are trying
to do is to provide a RELATIVE security mechanism, mostly for END users.

shannon
-------

 > I expect that Shannon and David (the authors) will get themselves on
 > this mailing list ASAP, and I will assure that they get copies of
 > everything for which they are not visibly shown in the TO/CC.
 > 
 > Your message seemed to be directed to me, so I will reply, though
 > comments from the authors are certainly appropriate.
 > 
 > I agree that the text in RFC1204 is inadequate.  I did not review it
 > prior to its approval as an RFC.  I had nothing to do with the RFC
 > other than to consult on the broad issues of how such a service should
 > be implemented, in conversations with a student (David Lee).
 > 
 > I think MPP has a proper framework, in that it is a POSTING companion
 > to the POP3 POSTOFFICE service, and fits exactly into the long
 > exisitng POP3 framework.  I don't think we should stop filling the
 > gaps in that framework.
 > 
 > Has anyone issued a decree that such work stop?  In short, must all
 > work stop at all levels other than the current high level work on
 > security, even though gaps in old frameworks may still exist?
 > 
 > I also described how this is useful in the POP3 framework on a LAN,
 > where an MUA could use MPP for posting, without needing an full
 > implementation of SMTP (and I can now add FTP to the list of things we
 > did not want to include).  I am not at all sure how FTP might be used
 > for the POSTING SERVICE in anything other than a very awkward way to
 > achieve the "remote posting service" that is sought.
 > 
 > So, I see two issues to be resolved:
 > 
 > 1.  Should this work be stopped because it is out of bounds in terms
 > of a new security framework concern, or is a little gap filling OK?
 > 
 > 2.  If it is OK to work on MPP, what should be done to send the
 > authors off to fix it.  Of course, some useful comments have already
 > been collected, in this exchange.
 > 
 > Best...\Stef