Hi, Brian, On Wed, 9 Jul 2003, Brian Candler wrote: >I've got a couple of questions which I couldn't find answered in the FAQ: >1. bincimap uses a 'checkpassword' interface, and looking at DJB's > definition, it seems it just passes a username and password down a pipe. > Does this mean that bincimap doesn't support SASL authentication? > The documentation talks about disabling cleartext password mechanisms > for non-TLS connections, which seems to imply that some non-cleartext > mechanism must be available.
Today, only PLAIN and LOGIN are supported authentication mechanisms next to the good old login command. The hint in the documentation is there to imply that there may be other mechanisms available, but there aren't any at this point (with SSL/TLS, one rarely needs other mechanisms). When the stable reaches 1.2.x, more features like will be added, either as modules or with native support, but it will most likely be seperately maintained. >2. In the definition of IMAPdir, it says "One entry in an IMAPdir folder is > a candidate for a mailbox". As an example, a file called "work" is shown > as an mbox file, which maps to IMAP folder "work" > So, how does this mechanism distinguish between mbox files, and metadata > files like 'bincimap-subscribed', 'bincimap-uidvalidity' etc? When the depot object scans for mailboxes, it has a chain of responsibility where every registered mailbox type gets a shot at identifying the depot entry. The only supported mailbox today is Maildir, and it will reject bincimap-subscribed and accept, for instance, work/ if it's a Maildir. The advantage of this is that NNTP support (or support for any backend) will be easy to plug in, and the entry in the depot can then for example be a configuration file with host, port, username and password. This would allow us to support backends as loadable modules. Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something | than to do it poorly."
