IMAP debate

[bscott at ntisys.com]

On Tue, 28 Oct 2003, at 3:28pm, invalid at pizzashack.org wrote:
> As for Cyrus, I don't know enough about its implementation details to
> really distinguish it from maildir.

  It is somewhat similar in concept to mh and maildir, in that a
mailbox-is-a-directory, and a message-is-a-file.  Various persistent indexes
and lists are part of the format.  It is also designed around certain
assumptions (a single, global, unified namespace for all mailboxes;  
mailboxes do not need to be association with Unix users; support for
multiple disk partitions within the unified namespace) which may not be
immediately evident.

>>> Data corruption happens.
>> 
>> That is not an acceptable attitude for many.  Nor should it be, IMO.  
> 
> In principle I would agree, but be practical: we're talking about e-mail
> here.

  Yes, indeed.  And for many companies, including many of our clients, 
e-mail is their single most mission critical application.

> We're also talking about a disk failure.

  Well, I wasn't.  I'm talking about any kind of system crash.  I expect
disks to be protected by RAID.  But we've all seen even the best-designed
systems crash; that why we have journaling filesystems in the first place.

> So in any event, restoring from back-ups will be NECESSARY.

  Um, no.  A properly designed system (one that employs journaling
techniques) should be proof against this.  Such techniques are even readily
applicable to existing formats like mbox.

> I still think this really isn't an issue worth worrying about.

  I think it is, and I don't have the option of just dismissing it, as you
do.

>> Microsoft Exchange, for example, deals with this particular problem very
>> well, by using a journaled database for storage (Exchange has a host of
>> other problems, of course, but that's not the point I'm making here).
> 
> Perhaps so, but that feature may also be part of the cause of some of
> those other problems you mentioned.

  As I said, that's not the point I'm making.  FWIW, I don't think the
database format is why Exchange is such a pig.

> As a side note, I'm curious: how do those users retain only the last 6
> months of e-mail?  Is that a feature their client provides?

  No, they just sort their inbox by date, and clean out the last X number of
messages periodically.  I've encountered a few different people who do this.  
I suspect it's not all that common.  I'm pretty sure the "never delete
anything; everything in my inbox" mentality is much more common.

>> and you still have locking issues for mail delivery (which can be
>> significant with a big inbox).
> 
> You need to lock, but so long as you don't allow REMOTE access to the
> mail spools (i.e. NFS), this just isn't a big issue.

  Oh, I also forgot to mention that mbox doesn't support simultaneous shared
access, which is one of the more useful features of IMAP, and something that
businesses will make extensive use of, given the chance.

>> Maybe, with the right code, mbox can be made to suck a lot less, but it
>> still seems like you're trying to improve upon a bad idea to me.  Why
>> bother?  :-)
> 
> Three reasons:

  One.

>   - backward compatibility

  This I see as the big one.  And it *is* a big one.  As it happens, for our
customers, we use IMAP pretty much exclusively, so backward compatibility in
the mailbox format (for MUAs running on the mail server) is pretty much a
non-issue.  But that's not the case for many.

>   - many people still LIKE mbox, for various reasons

  That's not a reason.  That's an assertion that there are reasons.

>   - I still say that there's nothing inherently wrong with mbox...
>     only with how people implemented it and use it.

  That's not a reason.  It's a reiteration of your assertion.

> It has lasted 30 years and is still in widespread use, despite
> availability of a number of "better" alternatives.  It can't be all THAT
> bad.

  The longevity of something has little to do with how good or bad it is.  
(Examples: COBOL.  IBM mainframes.  BASIC.  MS-DOS.  MS-Windows.)

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