blacklistd support for dovecot
Aki Tuomi
aki.tuomi at open-xchange.com
Thu Sep 20 09:35:39 EEST 2018
On 20.09.2018 00:48, Kurt Lidl wrote:
> Greetings all!
>
> I ported the NetBSD blacklistd support into FreeBSD a while ago
> (FreeBSD 11.x timeframe). I also added support to several of the
> system daemons there, so they could all talk to a centralized daemon
> (blacklistd).
>
> One of the third party apps that I added support to was sendmail - that
> works pretty well.
>
> So I'm now finally turning my attention adding blacklistd support to
> dovecot (which is the imap daemon that I use).
>
> I did an implementation to an earlier version, and that worked OK, at
> least for non-encrypted access to the imap server. However, the
> encrypted access (TLS) doesn't work right.
>
> To authenticate a network connection, the daemon must pass the fd of
> the remote connection over a unix domain socket to the actual
> blacklistd daemon. The blacklistd daemon will then call getpeername()
> on the connection, so it can determine the remote connection endpoint,
> rather than just having to believe some made-up set of data that is
> passed to it from process on the local machine.
>
> Christos Zoulas' talk on blacklistd is here:
> https://www.youtube.com/watch?v=fuuf8G28mjs
>
> Anyhow -- the problem I've run into is that there doesn't seem to be
> any way to get access to the fd of the socket that holds the raw
> connection to the client when TLS encryption is active. It looks like
> the only connection I get is to the proxy process.
>
> Is there any guidance that someone can give with how to implement this?
>
> Thank you.
>
> -Kurt
Hi!
Dovecot retains the fd for *-login process due to SSL not being such
easy to move between processes. If you want to add blacklistd support,
you'd have to patch the login process to send the original fd to
blacklistd and check result.
Aki
More information about the dovecot
mailing list