On Thu, 6 Feb 2003, Roland Chan wrote: >I've found that Binc is broken in a non-chrooted environment.
I know, it is. I will be creating a list of known bugs and a todo list pretty soon. >1) Various bits of meta data (subscribed folders, uidvalidity data etc) are >stored in files that are referred to in different ways: >- sometimes as "/filename" (which only works under chroot) >- sometimes as "/path/to/imap-folder/filename" (which also only works under >chroot) >- sometimes as "/absolute/path/from/filesystem/root/filename" (which works >all the time, so long as it's before the chroot) >- sometimes as "filename" (may or may not work at all) Very inconsistent, I agree. >It would probably be a good plan to either remove non-chrooted use as an >option or make the choice of filesystem names more consistent. Personally, >I'd prefer to have the option of not running with chroot so that I don't >_have_ to run checkpassword as root (since I'm not a getpwnam kind of guy). Absolutely. Non-chroot will be fixed. >Therefore I think that the most consistent approach would be to refer to >filenames as ./path/to/filename and only open user-specific files after any >chroot or chdir (see below). Yup. :-) >2) There also isn't a chdir into the directory supplied by checkpassword in >a non-chrooted environment. Yup. :-) >Also: There's a getpwnam in bincimap-auth-checkpassword.cc. Surely that's a >waste of time at best (it's completely breaks any virtual user scenarios). >By design, shouldn't binc let checkpassword will handle authentication and >authorisation? It's dead code, that's for sure. Gone now. >The idea of forcing TLS doesn't appeal to me, as I believe it's up to the >system owner to determine policy. It's easy enought to disable, but it sure >would be nice if the "clear text passwords in unencrypted connections" flag >worked. My belief is that the endpoints of any connection are the weakest Yes, that's a known bug. Have you tried adding the deprecated flag "--debug" as an option to bincimapd? It should do the exact same job. >points, not the network in between, and that TLS and SSL are therefore less >useful than taking precautions with the data storage (by encrypting it, for >instance). But that's just me. :) Actually, forcing TLS is going to be mandatory in the next revision of IMAP (IMAP4rev2). Clear text authentication is going out of the protocol. The reasons for this are many. >Otherwise, Binc seems to be a pretty reasonable IMAP server. A larger memory >footprint than courier-imap, but it feels a bit faster, whatever that means. Pine users are particularily happy with Binc over Courier, because the idle activity (STATUS, NOOP, CHECK etc..) it quite fast. Larger foot-print than courier, but hey - it's the year 2003. :-D We should be allowed to use the memory people have on their machines to provide a better service. >Not needing GDBM/BDB libraries is also nice. I suppose the memory footprint >may be able to be reduced by adopting the DJB-style 'qmail-popup' and >'qmail-pop3d' separation, but that's a whole new can of worms. >Roland There's a whole lot of work that can be done with reducing the memory footprint, and it's on my todo list. Thanks for the input. Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
