Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MH and IMAP (was: Linux-Outlook (ouch) question)



On Fri, 5 Apr 2002, at 4:46pm, John Abreau wrote:
> Speaking of MH-based systems, has anyone heard of an MH-compatible
> back end that can talk to an IMAP server?

  Ah, yes.  Paul Lussier and I have had this discussion.

  Basically, MH is both more and less than a MUA.  It includes a general
concept, a mail storage format specification, and a set of tools that work
with said format.  MH's big deal is that messages are files, and mail
folders are directories.  You can then apply various tools -- existing as
well as MH-specific -- to them.  Basically, it applies the Unix Philosophy
to email.  Neat-o.

  You can write an IMAP server that understands the MH storage format easily
enough.  The problem is, your nifty MH mail folders become just another IMAP
server at that point.

  Now comes the clincher.  MH is both more *and less* than an MUA.  There is
no single "back end" you can add IMAP support to.  The whole point of MH is
that mail is in the filesystem.  So MH goes "poof", and you need to use a
different MUA (one that speaks IMAP).

  If you follow this to its logical conclusion, there are two ways to
approach remote access to an MH mail store:

  One is a traditional remote filesystem mount.  NFS or SMB or whatever.  
You mount the filesystem containing your MH store on your remote host, and
then you can use it just like your always do.  Two potential problems here:  
One is that this kind of remote filesystem is usually not done over a WAN
like the Internet, due to a long list of reasons: Security, latency,
security, performance, security, reliability, security, etc.  The other is
that NFS locking, traditionally, sucks.  Things could get ugly if new mail
came in while you were accessing your inbox.

  The second approach is more... interesting:  You implement an IMAP client
as a filesystem driver.

  As weird as that sounds, it has a number of advantages.  You eliminate all
the issues surrounding a full remote filesystem.  IMAP is more light-weight
than a full remote filesystem.  You only expose an email protocol on the
server-side.  You can take advantage of existing IMAP authentication and
encryption mechanisms.

  Perhaps most interesting of all, though, is that this would let you use MH
with *any mail server that speaks IMAP*.  IMAP is the "lingua franca" of
email.  All the various Unix mail formats have IMAP servers for them.  Most
commercial, proprietary systems do as well -- MS Exchange, Novell GroupWise,
Lotus Notes, etc.  I am sure anyone who prefers MH would love to be able to
apply it to their corporate Exchange server.

  Implementation of this idea is left as an exercise to the reader.  :-)

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org