On Mon, 10 Mar 2003, Dale Woolridge wrote: > On 10-Mar-2003 12:54 Charlie Brady wrote: > | > | That's probably very similar to this: > | > | http://www.superscript.com/ucspi-ssl/install.html > > Only insofar as they want to provide (nearly) the same functionality. > It's certainly much easier to scrutinize the patch.
No, both are built on tcpserver - one as an explicit patch, the other as a "new" package which used tcpserver as a starting point. > | The problem with both options (for me at least) is that there are > | licensing problems. There is already enough confustion about Dan > > Sure, but the licensing problems don't affect bincimap. They affect our use of bincimap, which I believe is what we are discussing here. However, we digress... > | Sure, but that's a separate, and easier, issue. Using a wrapper such as > | stunnel is simple in those cases. > > Absolutely. I see now that you're actually interested in having STARTTLS > supported, just not in bincimap, preferring a post-auth bincimap and > some other layer to provide STARTTLS, like imap-auth or some such thing. Yes. In particular, I'm interested in the privilege separation capabilities of Scott Gifford's patch, and more flexible authentication capability. It's also a Good Thing if none of bincimap ever runs as root. > On the other hand, bincimap at least has the option of disallowing plain > auth without tls/ssl. That's an RFC 2595 requirement: Clients and servers which implement STARTTLS MUST be configurable to refuse all clear-text login commands or mechanisms (including both standards-track and nonstandard mechanisms) unless an encryption layer of adequate strength is active. The RFC seems to be confused about whether a TLS capable server can support cleartext authentication: An IMAP server MAY advertise that the LOGIN command is disabled by including the LOGINDISABLED capability in the capability response. ... An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections. An IMAP client which complies with this specification MUST NOT issue the LOGIN command if this capability is present. So, how does the server implement "LOGINDISABLED" if it doesn't advertise the capability in the capability response? > As far as I can tell, it won't be able to do > that unless you put something else in the chain to give it the hint. If local policy required encryption, then you would set up the process chain so that bincimap wasn't ever executed until TLS had been negotiated and the client successfully authenticated. -- Charlie
