> On 02 Feb 2016, at 15:15, Haravikk <[email protected]> wrote: > > That definitely seems promising! Though I’m a little uncomfortable about > having to apply a patch to make it work.
I'll add those patches to future releases, at least once I verify that they work. > However it’s got me curious; could I do something similar by defining a > second IMAP protocol? Since the protocol !smtp option can enable client > certificates for only some protocols, it seems like if I could copy (or > symlink) the IMAP protocol into a second IMAPS protocol then I could possibly > create the exception using protocol !imap !smtp, could something like that > work? Of course I don’t know enough about how dovecot’s protocol modularity > works, so I’m not sure what this would involve exactly, but if it could avoid > the need for patching it might be a nice way to achieve the same goal. Interesting idea. I guess that could work, except that imap-login binary is hardcoded to send "imap" as the protocol to auth process. In theory you could write a wrapper service between imap-login and auth that changes the imap to imaps, but that's not trivial.. Maybe the protocol name could be made configurable via another command line parameter. It would at least simplify the service changes. > >> On 2 Feb 2016, at 12:44, Timo Sirainen <[email protected]> wrote: >> >> >>> On 02 Feb 2016, at 14:19, Timo Sirainen <[email protected]> wrote: >>> >>> On 02 Feb 2016, at 13:09, Haravikk <[email protected]> wrote: >>>> >>>> So I still haven’t found a way to require client certificates only for >>>> port 993/IMAPS while leaving unencrypted IMAP open for local, trusted, >>>> services. >>>> >>>> Is there really no way to do this? I just found out how to do the same >>>> thing for postfix (turns out it’s fairly easy, just a matter of adding the >>>> settings in the right parts of master.cf instead of main.cf), allowing me >>>> to restrict client certificate verification to port 587 (I don’t accept >>>> port 465) without interfering with incoming mail server connections on >>>> port 25. >>> >>> If you really want to do it, you could do it something like this (not >>> tested - probably needs some additions/changes): >> >> Oh, except now you have two auth master processes, so the final userdb >> lookup would have to go to the right auth process. This requires the >> attached patch. After that you can do: >> >> # no 993 port for this imap-login >> service imap-login { >> inet_listener imaps { >> port = 0 >> } >> } >> >> # create a duplicate 993 service >> service imap-login-ssl { >> executable = imap-login -P imap-ssl login-ssl >> chroot = login >> user = $default_login_user >> # add other settings similarly as to service imap-login >> inet_listener imaps { >> port = 993 >> } >> } >> >> service imap-ssl { >> executable = imap -S auth-master-ssl >> unix_listener login/imap-ssl { >> user = $default_login_user >> } >> } >> >> # create a separate auth master process for port 993 >> service auth-ssl { >> executable = auth -o auth_ssl_require_client_cert=yes >> # add other settings similarly as to service auth >> unix_listener login/login-ssl { >> mode = 0666 >> } >> unix_listener auth-master-ssl { >> } >> } >> >> <multi-auth-master.diff>
