On Fri, 14 Mar 2003, Caskey Dickson wrote: > I've taken a liking to the name IMAPdir for this new Maildir structure > being proposed here.
Wouldn't "directory tree" be an adequate term? > 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 Be careful about the use of absolute paths. It's not impossible to consider that there would be a chroot done before bincimapd gets to run (as you've noted below, I see). > 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. Any checkpassword which does not pass all arguments is incompatible with DJB's definition (from http://cr.yp.to/checkpwd/interface.html): "If the password is acceptable, checkpassword runs prog. prog consists of one or more arguments." > > 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. This is only true if TLS is not negotiated. If TLS is negotiated, any notion the client has of capabilities must be discarded. From RFC 2595: Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. > 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'. That could be useful. > 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. The rewriting wouldn't be necessary, since the same entity is contructing the command pipeline and writing the arguments to bincimapd. The calculation of "longest common substring" can be done at "compilation" time. :-) -- Charlie
