ajax
|
|
IMAP mail server
| 
Nov 25 10:07 UTC 1996 |
I like the basics of Jan's "mail partitioning" proposal (item 145),
but think using an IMAP (Internet Message Access Protocol) server is
also worth considering. This is similar to Jan's suggestion in many
respects, but doesn't go quite as far in partitioning Grex from the
mail host. It results in a slightly more transparent user interface,
so things will operate more like they do now, but at a cost of carrying
more of the CPU load on Grex.
I'll explain how it works, then the advantages, the disadvantages,
and a bit of IMAP technotrivia.
How it works
------------
It would be wired up the same way as in Jan's suggestion, with a
separate mail host using a limited portion of the Internet link. You
could do this with two Internet connections, or with one Internet
connection and a router to control the data rate to the mail host.
Here's one way of doing it:
10 Mbps 128 Kbps ____________
+------+ Ethernet +-------------+ ISDN ( )
| grex |-------------+--| isdn router |------/ /---) Internet (
+------+ | +-------------+ (____________)
57.6 Kbps |
+------+ Serial +-------+
| mail |---------| router|
+------+ +-------+
In fact, as I suggested with Jan's proposal, it might be best to
run both Grex and the mail host without limiting the mail host's
network use for a while, to see how the bandwidth utilization
shakes out.
In addition to the same physical layout, mail delivery between Grex
and the outside world would also be the same: a mail transfer agent
running on the mail host would establish connections with other mail
hosts, communicating through the limited-bandwidth serial line so
that it wouldn't drown out Grex's other traffic.
But while the wiring and inter-host delivery is the same, user
access is different. To read their mail, users would run client mail
programs on Grex much as they do now. The mail clients would fetch
messages from the mail host, rather than the Grex's local disk.
(Though depending on the client, it might move them from the mail
host to Grex's local disk, and read them from there).
Advantages of the IMAP approach
-------------------------------
(1) You can run mail client programs on Grex just like you do now,
with no need to telnet to another system. This would be fairly
transparent to the user.
(2) The network bandwidth going to the outside world from the mail
host can be limited, just as with a telnetable mail host.
(3) Mail processing, delivery, and communications with other mail
hosts on the Internet is done on the mail host, not on Grex,
which frees up a big chunk of CPU/memory resources currently
done on Grex (at least that's the theory :-).
Disadvantages
-------------
(1) Grex has many mail clients, but only pine offers built-in IMAP
support (elm might, but the IMAP versions may be unsupported or
incomplete). To use other mail clients, a utility called
"imapmove" would be needed to move messages from the IMAP host
and append them to a local mail spool file on Grex, where mail
clients like "mh" and "mail" could process them as usual.
I think this could be made pretty invisible to the user, with
scripts that automatically move the messages when the mail
clients are invoked. One difference is that commands to reread
the message list from within the mail client, to see if new
messages arrived since the mail client started, would require
an added command run by the user. This is a somewhat obscure
feature, though, so it wouldn't affect that many people.
(2) Picospan, newmail, and lynx, which notify users when new mail
arrives while those programs are running, wouldn't provide that
notification. Solutions would be modifying those programs, or
having people run a background process that periodically runs
an IMAP-compliant chkmail (one is available) and updates their
spool file when new mail is found.
(3) People would be logging into Grex and running a mail client
program, which can be real memory hogs, so Grex's CPU speed
would still be affected as people read their mail. Jan's
suggestion of having a separate host where people read mail
totally eliminates CPU usage when Grexers read their mail.
(Unless people telnet from Grex to the mail host, in which
case they'll use a pty, and some CPU/memory for their login
shell and telnet client).
Grex would still need a mail transfer agent to move sent
(outbound) mail from grex to the mail host, even when the
mail is going from one Grex user to another. That also uses
some of Grex's CPU resources, but this would happen using
Jan's partitioning system as well.
IMAP Trivia
-----------
Free text-based Unix mail clients supporting IMAP:
> Name Mime? Source Status
> ---- ----- ------ ------
> MS No UWashington Released; MM-like basic mail utility
> Pine 3.95 Yes UWashington Released
> Elm No Mark J. Bailey In development? <root@knuth.mtsu.edu>
> Elm 2.4PL23 No Chris Taylor In development? <ChrisT@cck.cov.ac.uk>
IMAP utilities included in ftp.cac.washington.edu/mail/imap-utils.tar.Z:
> chkmail Checks for new mail on an IMAP server
> mtest IMAP test client; highly portable, good for testing
> imapmove Moves messages from IMAP inbox to local file
> imapcopy Copies messages from IMAP inbox to local file
> mbxcvt Converts local or IMAP mailbox to another format
> mbxmove Moves messages between mailboxes (more general than imapmove)
> mbxcopy Copies messages between mailboxes (move general than imapcopy)
A basic difference between IMAP and POP is that POP downloads all
the messages from a central mail host to a "local" machine, while IMAP
downloads only the message headers and specific messages as requested
by the "local" mail client. In Grex's case, the mail client isn't
really local (unless you're in the Pumpkin), and for clients that don't
have built-in IMAP support, it would actually operate fairly similarly
to POP.
See http://www.imap.org for more information on IMAP.
|
