UW-IMAP, mbox, MH, horse beating

Tom Buskey tom at buskey.name
Tue Oct 21 21:49:00 EDT 2003


p.lussier at comcast.net wrote:
> In a message dated: Tue, 21 Oct 2003 19:23:03 EDT
> bscott at ntisys.com said:
> 

I used to use MH and exmh myself.  I remotely access my email most of 
the time & I find IMAP better then direct access to the disk.  (That's 
the protocol issue).  I've converted my MH folders into mbox and then 
MBX format.  Yes, mbox offers better performance under UW-IMAP then MH!

> 
>> Oh?  I thought UW-IMAP supported mh mailboxes.  Or is your use of
>>"correctly" especially significant here?

Sequences, and what not.  Because UW-IMAP doesn't support sequences with 
MH mailboxes, it needs to reread all the files in the folder. 
Performance is then worse then mbox.

> 
> It sorta, kinda, but not really does.  The problem is that MH uses 
> index files (called sequences) to keep track of things like which 
> files are read, unread, etc.  UW-IMAP supposedly can access the 
> message store, but it doesn't update sequences properly, and I'm not 
> sure if it can deal with sub-folders either. (MH, being file/
> directory based can have a theoretically infinite depth)

It can deal with subfolders as long as they have a different name then 
their parent.  I've had some problems with UW-IMAP and subsubfolders in 
MH, mbox and MBX format.

>> Actually, both.  :)  I had thought your objection to IMAP was that using a
>>traditional IMAP client would lose all the benefits of the mh style of mail
>>usage.  I also thought that an IMAP server that could handle mh folders was
>>already available.
> 
> 
> AFAIK, there is no existing client or server capable of dealing with 
> MH.  In order to do so would require a significant amount of work on 
> server.  I'm not sure how much work on the client side would need to 
> be done.  Since, really, the client could just issue standard IMAP 
> commands, and the server could translate those into MH commands on 
> the backend and just spew the e-mail back down the IMAP pipe to the 
> client.
> 
> As long as the IMAP server on the back end would need to know how to
> deal with MH messages, folders, and sequences (among other things) on
> the server side, it would just have to know how to translate/map this 
> back to the client via IMAP.

What Paul wants is an IMAP server that deals with MH folders like 
UW-IMAP deals with mbox.

Hear me out here.  If you read through the UW-IMAP docs/history/etc one 
of the design goals was to let people logged into the server to 
*continue to access mail locally*.

That's why pine (also from UW) can deal with mail folders accessed 
through an IMAP server and mbox folders accessed directly through a 
filesystem server.  So the IMAP server is written with the idea that 
some other program is mucking with the files it's serving up to remote 
clients.

Every other IMAP server that I've looked at assumes IMAP is the only way 
mail is read.  The IMAP server only has to worry about the MDA adding 
messages.  Nothing is in the mail store reading or deleting mail.

Given that UW-IMAP's goal is allowing local and remote access, it's 
curious they came up with MBX format.  Unlike mbox, it's binary and (as 
far as I know) there are no local clients that can access it.  Well, the 
  UW-IMAP utilities can convert to/from it, but that's about it. 
There's a utility called dmail that delivers to MBX folders (like 
rcvstore in MH) from procmail.  If there is a corruption, you can't just 
fire up vi on the folder either.




More information about the gnhlug-discuss mailing list