Thoughts on RFC1204 (MPP)

[Dave Crocker <dcrocker@xxxxxxxxxxx>]

This is a curious document.  Its primary purpose is in the realm of
security.  This is a widely-acknowledged, wide-open hole in the current
email architecture.  My own experience says that you do not solve basic
problems with patchwork solutions.  The current proposal is strictly
patchwork.  What is the point of plugging one hole when there are so
many others?  Further, it is not clear to me that it plugs it very well.

I am unaware of any security review for this proposal.  Has one been
done?

The document says that it is Experimental, yet refers to the its
"standardization state."  This is a non sequitor.  Something that is
Experimental is quite explicitly NOT on the standards track.

The document states that adding personal computers ... "requires an agent
(message posting server)..."  Yet the term 'message posting server' is
new to me.  What standard email architecture is it part of?  If it is
a new concept, then it needs considerably more elucication.

The document refers to this as the 'Netix Message Posting Protocol.'
While I thoroughly laud the participation of the authors in the Internet
technical community, Internet working groups generally do not promote
proprietary work.  Application of a corporate name to the name of the
protocol seems to make the spec proprietary.

The spec is a subset of SMTP, with the addition of a USER command,
somewhat similar to FTP.  It has no RCPT TO addresses.  The spec does
not describe how to handle addresses, tho this was elaborated in a note
to this discussion group, later today.  However, the spec says nothing about this
fundamental point.  The explanation sent later today appears to assume
that personal aliases are expanded prior to posting but that
'registered' aliases and lists are not.  I gather, also that
recipient lists are derived from the To, CC, and Bcc lists.  What about
others, such as Resent-To?  This whole topic needs quite a bit of
discussion, yet is entirely absent from the spec.

The spec suggests returning a 250 OK for unrecognized user names, "...
as an attempt to prevent the message posting server from releasing
too much information..."  This policy differs substantially from the
normal service that users get on typical systems.  The normal approach
is to fail after the PASS is accepted and further to impose some 
long time delay before allowing the next USER attempt and, further,
to limit the number of such attempts.

Why has a different scheme been proposed?

In some, the document seems to try to solve a problem rather incompletely
and with a spec that has some large holes.

I believe that the goal is laudable, but would wish that the work were
integrated into the emerging Security Area IETF efforts.

Dave

P.S.  In reality, there are no email-related semantics that appear
to be part of this spec.  It simply hands an email object to a server,
for REAL email semantic processing.  As such, I fail to understand how
the proposal is superior to simpe use of FTP, which the additional hack
of having the ftp server know a special destination file name, so that
all messages STORed into /dev/email (or whatever) in fact get posted.
In fact, a very, very common style of message posting, from the very
earliest days, has been the creation of a file in a standard location
or with a standard name.  Use of that approach seems to me to be superior
to the use of yet-another-new-protocol.  Protocols are expensive to
develop, certify, etc.  

D/