First, after re-reading the entire thread, I seem to recall that there is someway to do this using the userdb auth module. As I recall, you can give a user separate smtp, imap, and pop passwords. If you simply change the passwords to imap to something they don't know, they won't be able to log in.
Second, I assumed an approach to using certs for authentication would rely on the crypto aspects of certs, not a byte for byte comparison of them in a database. I could be wrong about this as I've never done it with Courier. However, it seems what you want to feed to Courier is the list of trusted root certs used to sign the user's client certificate. The TLS libraries will do their magic crypto stuff to determine if the client cert is actaully valid, and if so allow the connection to proceed. Therefore there is no lookup of the client cert in a database. This seems to be the intention of TLS_TRUSTCERTS and TLS_VERIFYPEER in /etc/imap-ssl. btw... are there MUA's that support client-side certificates with IMAP, POP, and/or ESMTP? -andy bronto wrote: > > OK, I've found the info on SSL support at > http://www.inter7.com/courierimap/INSTALL.html. I've confirmed that > I already have SSL support included and the imapd-ssl deamon (as well > as popd-ssl) are started at boot time. I've also confirmed the > existence of the self generated cert. > > To test, I tried logging into imap with a known (previously working) > user. As expected, it generated an error. My mail client (Eudora > Windows) advised my that the cert was untrusted and that the domain > didn't match the server (which is true; it's a virtual domain) and > that I could add it to my list of trusted certs. I did. Trying > again, Eudora now just fails to log in. It simply says "operation > failed:". Reading my maillog, there is the entry: > > imapd: Connection, ip=[::ffff:10.1.18.64] > imapd: starttls: accept: error:140943E8:SSL > routines:SSL3_READ_BYTES:reason(1000) > > Which is undecipherable to me (pun intended). I have been using > MySQL for authentication, and there is no evidence of a query in the > logs. I assume that this is where the problem is; that SSL > authenticates against actual unix users? Is this true? I really > didn't want to have user accounts for all of the email accounts. > > Also, just to make sure I understand the methodology of allowing pop > for everyone but imap for some, am I going to just run imapd-ssl, and > not imapd, and popd but not popd-ssl?
smime.p7s
Description: S/MIME Cryptographic Signature
