dovecot - Feb 2003 - bincimap

hi,
what do you tyhink about it? especially the faq comment about dovecot?
http://www.bincimap.andreas.hanssen.name/

-- 
   Levente                               "Si vis pacem para bellum!"

[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.

On Tue, Feb 04, 2003 at 02:54:47PM +0100, Andreas Aardal Hanssen
wrote:
> I can change the words in the FAQ if you feel offended by it, but
you'll
> have to address points individually. I never made remarks about your
> personal code conventions, and I never claimed that my server "focuses
on
> security" in the extent that Dovecot does.
> 
> If you want to discuss our different designs, please do it seriously,
> point for point, and don't just troll around like this.
Sorry, I just got a bit disappointed after reading the the web page first.
Your lines of code comparisions just seemed to imply that your server does
everything that others would but with only a fraction of code. There was
also something about Dovecot's design being too complex, so I thought you
might have solved those problems more elegantly.

When you write something from scratch, I think it's a good idea to design it
so that it's superior to existing implementations in at least some ways, not
just make a clone with slightly different coding style. If all you wanted
was a clone with some changes (and better maintainer), forking the project
would be much smaller job.

Well, here's some design thoughts:

Maildir implementation could be hidden behind a class to access it. That
would keep the ugly details hidden from the rest of the code, as well as
allow easily implementing other mail storages.

Restricting yourself to only plaintext authentication doesn't sound very
good plan.

Separating the pre-login process from post-login process would probably be a
good idea to keep their functionality completely separated. It would also be
easier to audit the pre-login code if you knew exactly what there is.
After logging in, you could just exec() the post-login process.

Don't use sprintf().
> Actually I don't get why you guys CC'd me personally on this. If
you have
> anything in particular you want to discuss you can post it to the mailing
> list.
I just thought you'd rather want to see it now than months later in google.
I know I would. I didn't think it was really relevant to your mailing list,
but if you say so..