On Thu, 11 Apr 2013, lists-dovecot wrote:

[... snip ...]

...

I've put in a test ip address in /etc/hosts.deny like so: dovecot: 166.84.1.2

And then I execute the following from 166.84.1.2 to port 110: bash-3.2$ telnet SiteWhereImConfiguringDovecot 110 Trying SiteWhereImConfiguringDovecot... Connected to SiteWhereImConfiguringDovecot. Escape character is '^]'. +OK Dovecot ready. quit +OK Logging out Connection closed by foreign host.

If dovecot is configured with tcp wrappers (which it is; built on a CentOS 6 system, installed and configured per instructions), and the firewall has ports 110 and 143 open, but I'm blocking a particular host through /etc/hosts.deny then I should not be able to telnet to either port 110 or 143; both requests should be blocked from the originating IP, no?

Much thanks for your help,

Max Pyziur pyz@brama.com

What are you using as the service name in hosts.deny? I think it should be "imap-login:", (that's what I have as an historical/left-over entry) but don't have dovecot configured with wrappers on my current centos system so can't test this to be certain. Also make certain that you don't have anything in your hosts.allow file that would override the hosts.deny entry.

I was using dovecot, until you convinced me to do otherwise.

Putting pop3 in /etc/hosts.deny with the associated ip seems to work, like so: pop3: 166.84.1.2

or imap imap: 166.84.1.2

(are there any challenges to this?)

Given that services such sendmail and sshd respond to sshd: xxx.xxx.xxx.xxx sendmail: xxx.xxx.xxx.xxx

I thought that it should be dovecot: xxx.xxx.xxx.xxx

As a suggestion, can dovecot binaries for distributions such as CentOS and Fedora be compiled with tcp wrappers by default?

• Richard

Much thanks.

MP pyz@brama.com