NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/vmsnet/networks/tcpip/multinet/1861

Internet Message Format | 1992-07-31 | 3.4 KB

Path: sparky!uunet!sun-barr!cs.utexas.edu!sdd.hp.com!swrinde!network.ucsd.edu!mvb.saic.com!tgv.com!info-multinet
From: [e-mail] (Ned Freed)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: Client/server email implementations?
Message-ID: <[e-mail]>
Date: 31 Jul 92 21:16:52 GMT
Organization: The INFO-MULTINET Community
Lines: 53
X-Gateway-Source-Info: INTERNET
X-Return-path: <[e-mail]>
X-RFC822-From: Ned Freed <[e-mail]>
X-VMS-To: IN%"[e-mail]"
X-VMS-Cc: IN%"[e-mail]"
Nntp-Posting-Host: Mvb.Saic.Com

The simple answer to your question is simple: there is no "best"
client-server protocol, and hence there is no "best" set of clients and
servers.

Let's start with the candidate protocols: POP2, POP3, IMAP2, IMAP3, and
X.400-P7. Of the two IMAPs, one is essentially dead; it was something of
an "unauthorized" variant. Of the two POPs, the only reason for maintaining
the old one is for compatibility with old clients; the two are slightly
incompatible.

So now we're down to POP, IMAP, and X.400-P7. Of these, POP has as its
design base a slight mailbox model, where mail messages can reside in
folders on the client, on the server, or both. This forces various choices
in the protocol that aren't really appropriate for different models. IMAP,
on the other hand, is strictly a mail reading/filing/deleting protocol. No
attempt is made to support a split mailbox model at all. X.400-P7 is an
interesting protocol in some ways, but it is hopelessly mired in the OSI
framework (much more so than, say, X.400-P1 or X.400-P2, which arguably could
be used over non-OSI networks without much work). As such, X.400-P7 is only
appropriate in an OSI network mail environment. I think using it to
operate on SMTP-based message stores is just plain silly. (The issue of
using IMAP or POP to get at an X.400-based message store is far from silly,
however, and I don't want to deal with this issue here.)

So, in essence what it all boils down to is that you should choose your
protocol based on what mailbox model you use. Now, this is not always
feasible -- in particular, IMAP clients are in relatively short supply,
so you may end up using POP where IMAP is a more natural fit.

MIME support brings up complexities of its own. In POP, for instance, there
is no real MIME support issue, since a split mailbox model essentially
operates on a message-entity basis, and that's all the protocol has to
know about. IMAP, on the other hand, is the sort of protocol that should
allow reading of selected MIME parts of a message, and indeed it does
just that.

Now let's talk about implementations. The problem here is that once you
pick the hardware platform you're going to support and the model you'd
like, there is generally very little flexibility left in terms of choosing
a client or a server. There are a couple of servers for VMS, but that's
pretty much it. Similarly, there are a couple of clients for the PC or
Mac or whatever, but generally not more than a couple. My best advice
here is to decide on the model and try to pick software that supports it
best. You won't have very many options to choose from.

Oh, I have omitted discussion of protocols like PCMAIL from all this. There is
a small lingering remnant of use of these protocols, but as far as I know
nobody is developing them further. So, despite the need to hold onto these
protocols as informational entities, they are obsolete insofar as new
installations go.

                Ned