Everyone. Summing up some of the recent threads, how does this sound:
1) Maildir structuring for Binc IMAP changes.
All mailboxes are free to be placed wherever we want. It is
recommended, but not required, to store all mailboxes under
one filesystem folder. I'll use ~/mail/
as an example. All Maildirs are leaves and have the following
structure:
mail/INBOX/
mail/INBOX.subfolderofinbox/
mail/INBOX.subfolderofinbox,sub/
mail/arootfolder/
mail/arootfolder.subfolder/
INBOX is obviously a special case here. Taking Dale's
suggestions into consideration, if mail/ itself (or ~) is a
Maildir, then this is used in place instead of INBOX and
it's logged as a notice to the administrator because
the mail/INBOX/ folder will then be ignored. The preferred scheme
is to _not_ have mail/{cur,new,tmp} but mail/INBOX/{cur,new,tmp}.
Typically, mail delivery (.qmail or rc or similar) must be
instructed to deliver to the INBOX maildir in this new
structure. Where this is not possible, a symlink from ~/mail/INBOX
to ~/Maildir should do the trick.
Also, we change the delimiter, which under no circumstance can
be a dot '.'. This is to ensure compatibility with Maildir. Ex-
Couriers will get this funny output from LIST:
tag LIST "" "*"
* LIST (\UnMarked) "/" "INBOX"
* LIST (\UnMarked) "/" ".work"
* LIST (\UnMarked) "/" ".Sent/2002"
This means we have backwards compatibility with Maildir++. The
special case is that the first dot is actually interpreted as
part of the folder name, and not as a meta symbol. The '.' is
still used to represent the seperator in the file system. It
will not be allowed in Binc to _create_ a folder that contains
a '.'. Our internal delimiter is "/". Can anyone see any reason
to have the delimiter configurable, or is it reasonable to
assume that nobody wants a "/" in their folder name that does
_not_ represent the hierarchy delimiter (an assumption that gives
us tidier code).
What is the benefit of doing this?
* Root level mailboxes
* Submailboxes of root mailboxes and INBOX
* Superior and inferior (sub)?mailboxes can all be selectable
(and contain mail).
* All while _still_ being compatible with Maildir++. :-)
* It is possible, but optional, to chroot into this
structure or any parent dir.
* We are not restricted to have only Maildir mailboxes in this
structure. An entry might as well be an mbox. LIST can detect
the mailbox type.
Who's up for giving this structure a name? Something with generic
standard multilevel/type mailbox depository structure?
2) Binc Invocation changes
We introduce privilege seperation. Binc will consist of a native
bincimap-up stub which uses only a fraction of the daemon code.
The stub will initially give up almost all privileges and will only
handle pre-authentication code. Since it uses only existing code,
this will not add much to the total lines of code in the project.
The invocation chain will function just like qmail-popup and its
friends.
3) Authentication changes
We remove the (sob) native authenticator support and go for a
checkpassword interface only. This means we still support
pluggable auth modules because nearly all authenticators have been
written in a checkpassword style, and if not, they are quite easy
to write.
Comments please, comments! :-D
Andy
