[dovecot] Re: bincimap

[Timo Sirainen]

[oh well, let's cc the author as well]

On Tue, 2003-02-04 at 13:43, Farkas Levente wrote:
> hi,
> what do you tyhink about it? especially the faq comment about dovecot?
> http://www.bincimap.andreas.hanssen.name/

That's interesting. Haven't noticed it before. Author's name is actually
familiar from imap mailing list :) Initial impressions:

It uses C++, so why is it still using sprintf() in a few places, just
waiting to be exploited? That alone actually makes me question his "C++
security experience" (well, that's not C++ exactly..). The ones in COPY
and APPEND handling actually can cause buffer overflows if host has long
enough hostname.

Says it's a replacement for Courier IMAP, and the design looks that way
too. Currently at least maildir-specific (there was some empty mbox dir
though) and without any kind of smart indexing, meaning it's quite
likely close to Courier's performance.

I don't really get his comments about TCP wrappers. Meaning that I do
network I/O instead of letting inetd handle it? That's only minimal part
of the code and I'd say it has near-zero possibility for any security
related problems, or any kind of all really. Well, of course doing it in
inetd allows /etc/hosts.deny and such.

I guess his server runs as root until user is authenticated. That
requires that all IMAP commands check properly that they're not run
before authentication, that everything that is run before authentication
must have perfect security or attacker can get roots. SSL communication
is likely also done as root.

That's very different from Dovecot's design, where login process has
been designed so that even in case of a security flaw (eg. SSL library),
there's no way for the attacker to do _anything_ before being properly
authenticated (chrooted, non-privileged user, only access to communicate
with auth process via pipe but no way to get other users' passwords or
anything). Post-login SSL communication is also done by the same login
process, so that exploiting SSL library bugs even then won't do any
good.

It wouldn't be too difficult to allow Dovecot to be run from inetd, but
I don't think there's much point. It's certainly less secure since it
initially requires roots.

Hmm. What else .. I would have expected C++ code to be more .. prettier.
It's 10k lines count may be partially because of C++ and using lex
instead of writing own parsers, but I think it's mostly because it
doesn't really do much. Plaintext authentication + maildir + IMAP4rev1
is pretty much what it does now, without anything special in design or
implementation (except for being C++). Very much like Courier or UW
imapd.