12 Approaches not covered by this memo (LAN Mail Protocols)
Description
This article is from the LAN Mail Protocols FAQ, by John Wobus jmwobus@syr.edu with numerous contributions by others.
12 Approaches not covered by this memo (LAN Mail Protocols)
* Proprietary protocols
* file sharing
* APIs
* X.400
* Web
Vendors can invent their own protocols similar to those listed above,
and some have.
LAN e-mail can also be implemented using file sharing, e.g. using NFS
to allow separate Unix workstations to share the same mail spool area
just as if it were mail being stored on one system, or using Novell's
SMF (Simple Message Format) in a Novell file server. If the
applications are written so that they are careful to lock files
correctly, then this works. An advantage is that any network file
protocol can be used and the e-mail application can be somewhat
independent of the file protocol. For example, Unix systems could use
either AFS or NFS. Pegasus is a PC & Mac application that uses Novell
file service to do something similar. Specifications for client-server
interaction consist of the file service protocol along with the server
directory structures & conventions used for storing e-mail.
A very popular approach with commercial vendors is the use of APIs.
The client talks to the server using an API (Applications Programming
Interface), i.e., a set of subroutine/procedure library call
definitions for a library providing subroutines/procedures to send,
receive, and manipulate e-mail. With the use of any remote procedure
call mechanism, the client can be located on a different computer from
the server. This allows some mixing and matching of RPC mechanisms,
underlying protocol stacks and APIs: e.g., a vendor defines an API,
and it can be run over IPX or TCP/IP, in each case over the protocol
stack's RPC mechanism. There are a number of APIs now being pushed by
vendors: MAPI (Microsoft); VIM (Lotus); AOCE (Apple). These API's have
been the basis for numerous mail-enabled applications: e.g. a word
processor that allows you to send or receive documents through e-mail
simply uses one of these APIs allowing it to communicate with any
server supporting the same API. Specifications for client-server
interaction consist of the protocol stack up to the RPC protocol, then
the API itself.
Note that though the API approach in combination with remote procedure
calls allows one to implement client-server e-mail without the use of
the protocols covered by this document (IMAP, POP, etc), that there is
no theoretical reason why such APIs can't be used in an IMAP or POP
environment. The necessary software would be a "driver" or piece of
"middleware" that provides the APIs calls to mail-enabled applications
and uses POP, IMAP, or whatever over a LAN to reach a server. The
advantages/disadvantages of such an approach as compared to the use of
RPCs is open to debate. UniPalm's Mail-IT is an example of client
software that provides MAPI within the client and uses POP3 to access
the server.
X.400 is the message transport defined for use between
telecommunications vendors and customers by the international
consortium of national standards bodies known as ISO. It roughly
corresponds to TCP/IP's SMTP and RFC822 header format. A consortium of
X.400 vendors (XAPIA) have developed an API for X.400 applications
called CMC.
Mail servers are now available that offer e-mail through normal web
interfaces, i.e. HTTP & HTML. In this case, your web browser is your
client. Potentially, a server could be built that allows reading from
any web browser software. Some kind of authentication is necessary.
Another trend is web servers that act as POP-to-web gateways or
IMAP-to-web gateways. The client is still just a browser: perhaps a
JAVA-enhanced interface is offered, perhaps not. If the server has a
mail store, it is acting as a whole mail system and if it can receive
SMTP mail, requires no other server. But suppliers of mail services,
wanting their systems to be universal, can have them pick up mail from
a POP server or an IMAP server, perhaps at the client's discretion. In
the case of IMAP, the server can be written so as to leave stored mail
on the IMAP server, or it can support both "remote" and "local"
folders, in this case, "local" meaning on the web server rather than
the IMAP server. Web-based e-mail has a lot of appeal: since a browser
is sufficient as a client, the clients are already deployed much more
widely than any specific e-mail client. Some organizations may well
try to offer a mail-specific client for on-site use and web access to
the same mail store for remote access.
Continue to:
My Books
