dovecot - Feb 2003 - Re: [bincimap] Re: Re: bincimap

On Mon, 17 Feb 2003, Andreas Aardal Hanssen wrote:
> >> It even recently included a POP server. What's the reasoning
there?
> >Someone wanted it so it'd be easy to run both POP3 and IMAP servers
> >without having to configure them twice. I don't see any harm in it
> >anyway, it took only few hours to write, it's optional and
doesn't take
> >much space in sources.
>
> Here's where I would say - there are hundreds of working POP3 servers
> around, both in closed and open source, so adding a POP3 server to the
> Dovecot project just introduces more lines of code where bugs may appear
> ;).
Here is what -I- would say:

I use mbox on all my servers which I have absolutely no intention of
changing despite the issues concerning file locking inherent in the whole
mbox format.  So please, --NO-- attempts to convince me to go to maildir.

My take is that if I am going to use an IMAP server, it would be VERY nice
if a POP3 server also came bundled with it.  Dovecot's having both IMAP
and POP3 servers is great because they will likely use the same
file-locking schemes (in fact, probably even share the same locking
settings).

That way if I inadvertently start up a POP3 session while I am connected
via IMAP, if they use identical locking mechanisms, I don't screw up my
mailboxes should I inadvertently tell my system that I want to delete the
messages from my mailbox.

Basically, if you open via IMAP using a server with a diffent locking
scheme while your hung POP3 session is still running AND you modify your
mailbox, you are screwed.  Especially if that mailstore is NFS-shared,
which is always a dicey proposition.

Additionally, the number of mbox POP3 servers which Do Not Suck(R) is
rather low right now.  Timo finally introduced an mbox IMAP server which
definitely Does Not Suck, notably it allows for multiple clients accessing
the same mbox mailstore, something previously only offered by Cyrus and
perhaps maildir ("perhaps" only because I do not use maildir).

Not to mention, quite frankly, most mbox POP3 implementations suck pretty
badly anyway. :P

--Ian.

On Mon, 2003-02-17 at 12:14, Ian R. Justman wrote:
> Additionally, the number of mbox POP3 servers which Do Not Suck(R) is
> rather low right now.  Timo finally introduced an mbox IMAP server which
> definitely Does Not Suck, notably it allows for multiple clients accessing
> the same mbox mailstore, something previously only offered by Cyrus and
> perhaps maildir ("perhaps" only because I do not use maildir).
I don't actually understand why UW imapd doesn't allow it. It needs to
be able to deal with unexpected mbox changes anyway, so why allow only
one IMAP session for it? Or maybe it deals with unexpected changes just
by killing the IMAP connection? I'd have to try some day.

Few days ago I was also wondering how UW imapd even knows how to kill
the older connection. It seems that it writes PID to
/tmp/.<device>.<inode>. When another IMAP process tries to access
the
same mbox it sees the file, sends SIGUSR2 to the PID inside it and waits
for a while to see if the lock file goes away. Strange.

Hi, Ian. Cross-posting discussions like this is usually not appreciated by
those who subscribe to both foras, so I'll limit it to the Dovecot list.

On Mon, 17 Feb 2003, Ian R. Justman wrote:
>On Mon, 17 Feb 2003, Andreas Aardal Hanssen wrote:
>My take is that if I am going to use an IMAP server, it would be VERY nice
>if a POP3 server also came bundled with it.  Dovecot's having both IMAP
>and POP3 servers is great because they will likely use the same
>file-locking schemes (in fact, probably even share the same locking
>settings).
I agree with you.

But any shared mailbox format that makes assumptions on the type of
locking used by other accessors, and does not provide a standard locking
mechanism bundled with the format specification, is b0rken. But nobody
ever claimed that mbox was anything else, did they? ;) mbox is yesterday's
format, and the only reason people cling to it is for convenience and "if
it works, don't fix it".

Today we can exploit concurrency and rapid access in ways that were
unthinkable back when mbox was designed. It's only natural that the old
and worn fall by the swords of the young and strong. :-)
>Basically, if you open via IMAP using a server with a diffent locking
>Additionally, the number of mbox POP3 servers which Do Not Suck(R) is
>rather low right now.  Timo finally introduced an mbox IMAP server which
This I don't agree with. Most existing POP3 servers are quite ok, and
one POP3 Maildir server that is excellent and bug free since 1998,
qmail-pop3d, is quite a piece of art.
>Not to mention, quite frankly, most mbox POP3 implementations suck pretty
>badly anyway. :P
This I do agree with. Don't confuse POP3 servers in general with mbox POP3
servers. The root, the source of the evil is the storage format mbox.

Now I will not claim that Maildir is indefinitely much better, but it's
almost, but not quite, much much better than mbox.

With Maildir there's no need to lock the depository when deleting or
delivering mails (even on NFS), but you can't store (append) a message
with a timestamp nor with flags without breaking consistency, and servers
have to search for lost messages when an external client changes a flag.

With mbox you have to rewrite the entire mailbox after expunging message
#1, and exclusive access is required when doing so. With no indexes,
mboxes also need to be more or less parsed on every login - I understand
that Dovecot has done some smart stuff here, but that's a workaround for
one of the big headaches of a crappy storage format.

Nobody with their wits intact would come up with something as pathetic as
the mbox storage format in 2003. That's _my_ personal opinion on this
matter.

Now Binc IMAP does not support this format, but that's not because I
don't want it to. Rather, I'd like to investigate neat ways to make it
work just like Timo has with Dovecot. But rather than breathing fresh
air into the wrinkled nostrels of one of the Internet age's uglier
artifacts, I'd like to find a way to move all users away from mbox and
into a new mailbox format. One box to rule them all. ;)

btw, Flames are happily accepted. :-)

Andy

-- 
Andreas Aardal Hanssen
http://www.andreas.hanssen.name/gpg