Hi, Charlie. On Tue, 11 Mar 2003, Charlie Brady wrote: >On Tue, 11 Mar 2003, Andreas Aardal Hanssen wrote: >> >Switching to stdin and abandoning the checkpassword protocol is fine, >> >but doing so means that we cut ourselves off from every one of the >> >dozens of checkpassword implementations available right now. >> No! I think you totally misunderstand. >> Binc launches bincimap-auth-checkpassword. >> Binc talks to bincimap-auth-checkpassword. >> bincimap-auth-checkpassword talks to checkpassword. >> We are _not_ changing bincimap-auth-checkpassword! >> BINC_USERID and BINC_PASSWD, we will use >> 7:andreas,8:password, >> And Binc will write this to it's authenticator's stdin. That's all. >I'm still mystified as to why all this extra (relatively) complex code >exists.
But I hope you agree that we are not changing interoperativity with checkpassword, as I beleive you first feared. >The qmail-popup/qmail-pop3d model, which is cited as an inspiration for >bincimapd, uses two separate programs to provide the POP3 service. >qmail-pop handles the pre-authentication part of the protocol, and >qmail-pop3d handles only the post-authentication part of the protocol. >This design is simple, reliable and secure. I don't have the same Note that the only thing that makes this design secure is if the preauth module is much more simple and restricted than the post-auth code, so that the overall chance of failure in the preauth module is lower than in the postauth module. However, I agree that this is a good design and I will implement it. >confidence that the new bincimap design has these characteristics. Binc does not have priviledge seperation yet, and I have said before that it will be introduced. >One of the reasons that I am here, and I doubt that I am alone, is >mistrust of Mr Sam's "I must reinvent every wheel" approach. I doubt that >we'll see that here, I am a little uneasy. >Andreas, are you wedded to the current authentication scheme? Or might you >be convinced to have the authenticator spawn bincimapd rather than the >other way around. I'm not wedded to the design. I am looking into priviledge seperation. However, Binc IMAP's authenticator is not checkpassword. If we want the authenticator to only support checkpassword and not the stdin-stdout method Binc uses today, then I too see no reason for the daemon not to be spawned by the authenticator. _However_, checkpassword support is simple a bundled stub. The native authenticator behaves differently. By "invoked similarly" I mean that it is spawned through a tcp wrapper. It will support privilege seperation. But I am not convinced that the authenticator should spawn the daemon. >[As I mentioned earlier, Bruce Guenter already has a pre-authentication >imap protocol handler - imapfront-auth from the mailfront package. One >would execute imapd using checkpassword as the authenticator using: Yes - saw this. Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
