First, programs like bincIMAPd which normally run on behalf of a user should never run as root, even accidentally. In the first version of my password stub, I assumed that bincIMAPd still required root privileges and would drop them as soon as possible (which is standard practice). So, I didn't set the user or group id's and, later, the daemon created the mailbox with owner root.
As a general security principal, it would be a good idea for the daemon to refuse to run as root.
Second, security conscious programs should not rely on the current working directory (cwd), they should use absolute paths to their configuration and data files (this, too, is standard practice). It just never occurred to me that a server would assume a valid working directory instead of setting the path itself from /etc/password or, at the least, from the HOME variable.
On an insecure system it would be relatively easy to subvert CHECKPASSWORD in order to silently read mail belonging to someone else, especially since the program is stored by default in /bin instead of /sbin. I'm not saying this is likely, and I'm not going to give any clues on how to do it, but it is possible. Making these two fairly minor changes would completely eliminate two well-known classes of potential attack.
Even so, I'm happy to have found bincIMAP. It neatly fits our needs much better than the other well known IMAP servers. Thank you, Andreas, for all your hard work.
Ivan M. --
------------------------------------------------------------------------ [EMAIL PROTECTED]
It is better to trust in the Lord than to trust in man. (Ps. 118:8) ------------------------------------------------------------------------
