Re: [Exim] Mail storage formats/ POP/IMAP/webmail daemon/etc…

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Dave C.
Date:  
À: Peter Galbavy
CC: Juha Saarinen, Nigel Metheringham, Tom Samplonius, Michael J. Tubby B.Sc. G8TIC, exim-users
Sujet: Re: [Exim] Mail storage formats/ POP/IMAP/webmail daemon/etc..
Ok, I think I've decided that MBX format seems to be the best compromise
(delivered directly by exim to /home/$user/INBOX), and we had already
looked at the pop/imap proxy mapping to some number of mailstore
machines, so is probably the way we are going to go.

MBX allows for concurrent access, which would prevent the 'mailbox
locked' problem that a lot of our users seem to currently get when they
get knocked offline while in the middle of POPping their mail..

I still need to figuyre out which webmail client will be the most
efficient and functional. IMP is the most well known, but I beleive it
abuses IMAP badly (eg, it opens and closes the IMAP session MANY times
for each function - whereas IMAP is designed to be opened and stay that
way for an entire session). Obviously the stateless nature of the web is
going to exacerbate this anyway. I would *love* to find one that would
access the MBX folder directly, but havent had any luck so far.

I appreciate everyone's input so far.




On Tue, 3 Apr 2001, Peter Galbavy wrote:

> > The actual report (as opposed to a reference to it - useful when
> > geocities goes down for an hour or so) is at
> > http://www.courier-mta.org/mbox-vs-maildir/
> >
> > Its interesting reading... would be even more interesting for large
> > sites if courier cached some of the metadata.
>
> The problem is that the benchmark compares mbox and maildir formats. I
> suspect that the results would be very different if the default format were
> mbx.
>
> I am not trying to say maildir is bad - I have chosen it for our new service
> purely because I can use it with NFS for a many-to-many server environment.
> I would love to see some independent benchmarks like the ones dome above.
>
> Peter
>
>


--