I've taken a liking to the name IMAPdir for this new Maildir structure being proposed
here. I'm using it in my notes below to refer to the structure-formerly-Maildir++.
On Thu, Mar 13, 2003 at 05:34:57PM +0100, Andreas Aardal Hanssen wrote:
> Everyone. Summing up some of the recent threads, how does this sound:
>
> 1) Maildir structuring for Binc IMAP changes.
This looks good. I too am a fan of INBOX defaulting to $IMAPdir/INBOX by default but
having the bincimapd-postauth take in at least two parameters, the location of their
IMAPdir and the location of the INBOX, which if it isn't a fully-qualified path is
assumed to be a mailbox in $IMAPdir. Thus, the following would correspond to what you
described as your default:
... bincimapd /home/user/mail INBOX
While this would be for an external INBOX setup:
... bincimapd /home/user/.mail /home/user/.Maildir
And for someone using an old checkpassword implementation::
... bincimapd /home/user/Maildir
Thus $IMAPdir/INBOX (or $IMAPdir/InBoX, etc.) is unselectable unless it is the actual
INBOX per the command line, or left as the default. In case three, '.' is used as the
INBOX and Maildir/INBOX would just be left unselectable.
As for switching the path separator, I see no reason to do this but if someone is
willing to write it, it doesn't seem to break things.
> 2) Binc Invocation changes
> The invocation chain will function just like qmail-popup and its
> friends.
Excellent. I would suggest creating a separate src/ directory for the binc-imapup
code. But I'm more paranoid than most.
Unless I'm forgetting something, the only command line parameters the daemon needs are
the IMAPdir name and the optional INBOX Maildir, which the checkpassword chain will
have to append in the same way the old style checkpassword appends the Maildir. As I
mentioned above, it ought to be smart enough to treat a non absolute path as the name
of an IMAP maildir. This allows easy IMAP toaster construction.
The treating if . as the INBOX iff new/cur/tmp exist is a good idea because that
behavior is necessary to allow existing checkpasswords to work directly. They only
call their final program with the POP box which is the IMAP equivalent of the INBOX.
> 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.
The only (potential) problem I see is that the CAPABILITY command in the imapup code
must return all the capabilities of the postauth daemon. Most (all?) of the
capabilities seem to be related to preauth/auth activity so this isn't a big deal, but
we might want to be sure and have a configuration option in the imapup config along
the lines of 'capability append'.
Of course the chroot activity will be more or less up to the particular checkpassword
implementation. If bincimapd acceped '/' as the name of the mail store, then one
could even write a checkpassword chain link that takes its fully qualified path
parameters, finds the longest common substring, chroots to it and then execs its next
stage with rewritten paths. But that's a bit of overkill.
C=)
--
--------------------------------------------------------------------------
Better the hard truth than the comforting fantasy. -- Carl Sagan
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
A presumption on your part does not constitute an obligation on my part.
