Hi, Charlie :-)

On Wed, 12 Mar 2003, Charlie Brady wrote:
>To give some more points of reference about some of the issues we are
>discussing, I took a look at dovecot (http://freshmeat.net/projects/dovecot/)
>Dovecot supports preauthentication:
>...
>[EMAIL PROTECTED] dovecot-0.99.8.1]$ ./src/imap/imap
>* PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND
>UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED] Logged in as
>charlieb
>...

Dovecot supports almost everything that you throw to the author. It's a
monolithic monster, something Binc will never be. I know Dovecot and
Courier-IMAP support loads of extensions and native support for LDAP,
PostgreSQL and its brotherhood, but my main goal with Binc is to get its
design "perfect", then support only IMAP4rev1 with no extensions, then
make it easy for the community to write both extensions and new backends.

I don't want Courier and Dovecot's history of bugs. :(

>You can create top level (peer of INBOX) folders:
>You can't create a subfolder of a folder
>But you can create a subfolder of INBOX
>You can create a folder heirarchy;
>But once a directory is a container for subfolders, it can't be a folder:

Funny. I hope we will find a consistent scheme for Binc. I'd like Binc to
support

  * Top level mailboxes
  * Submailboxes of INBOX
  * Unlimited submailboxes of top level mailboxes
  * Mailboxes that can contain both mail and submailboxes

>Here's where the mailstore is laid out:

Interesting. Seems .imap is a special folder that contains meta data.

>-rw-rw----    1 charlieb charlieb     1608 Dec  1  2002 .imap.index
>-rw-rw----    1 charlieb charlieb    10264 Mar 12 18:00 .imap.index.data
>-rw-rw----    1 charlieb charlieb     2576 Mar 12 18:00 .imap.index.log
>-rw-rw----    1 charlieb charlieb     1556 Mar 12 18:00 .imap.index.tree

The indexes are quite interesting in Dovecot. Among other features, their
implementation prevents the server from storing UIDVALIDITY at all across
sessions, or at least it's been like that for a while.

>/home/charlieb/mail/INBOX:
>total 8
>drwxrwx---    2 charlieb charlieb     4096 Mar 12 18:13 .
>drwx------    5 charlieb charlieb     4096 Mar 12 18:14 ..
>-rw-rw----    1 charlieb charlieb        0 Mar 12 18:13 foo
>[EMAIL PROTECTED] charlieb]$
>The above doesn't match the documentation, which says:
> We support Courier-compatible Maildir++. INBOX is the ~/Maildir directory,
> all the other folders named as ".<folder>.<subfolder>.<etc>" under it,
> any directories not starting with a dot are simply ignored.".

foo looks like an empty mbox, can't verify that though since it is truly
empty.

>I have my doubts about INBOX as well:
>001 select inbox
>* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
>* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
>permitted.
>* 0 EXISTS
>* 0 RECENT
>* OK [UIDVALIDITY 1899586815] UIDs valid
>* OK [UIDNEXT 1] Predicted next UID
>001 OK [READ-WRITE] Select completed.
>002 logout
>* BYE Logging out
>002 OK Logout completed.
>[EMAIL PROTECTED] charlieb]$ ls ~/Maildir/cur | wc -l
>   5826
>[EMAIL PROTECTED] charlieb]$

Looks like some misconfiguration..

>I couldn't find any documentation about how to run dovecot - the INSTALL
>file only says how to build it. From reading design.txt, it seems that a
>daemon running as root accepts connections, and spawns multiple
>communicating processes to service them. These processes do login+SSL,
>auth and imap respectively.

I understand that the preauth module always streams SSL data to its
respective child if the client enters SSL mode.

I really don't like the native TCP stuff in Dovecot. Courier-IMAP is much
better there, although FWICS it can't do anything that other wrappers
can't do.

>I find it interesting that yet another IMAP server author has created
>their own network connectivity and authentication infrastructure. The
>dovecot author has broken things down into pieces, but it looks like
>those pieces may be tied together in such a way that you need to take the
>whole package.

I predict that Timo will have a good time fixing bugs in his 50000++ lines
of C code. Since he added a POP server to the project I guess he's got
even more lines! Seems Timo likes to add whatever seems fun and "easy" to
write.

I hope Timo will not do exactly what Courier-IMAP did and let the project
grow into a complete MTA.

My vision :) is that we can have

   - loadable C++ backend modules
   - loadable extension support (have no idea how this would work)

I'd like the contributor page to grow full of software following the
general ease of writing extensions to this server. That will allow me to
focus on keeping the "kernel" Binc IMAP server stable and free from bugs,
while each author of the different backends and extensions can help
support those extensions.

I want the number of lines in the Binc "kernel" to be as low as possible
without having to put for-loops on one line and removing all comments.
Small, easy, pretty algorithms. Aaah.. ;)

Andy :-)

PS: Feel safe that Binc IMAP will _never_ include a POP3 server ;)

-- 
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP    | Nil desperandum

Reply via email to