The problem mentioned here is, IMHO, an oversight, not a feature
request. Our dovecot implementation functions as a stand alone
daemon so it is not under xinetd's control and will not obey
tcp_wrappers restrictions implemented via xinetd and since it is not
linked with libwrap it will not obey tcp_wrappers restrictions on its
own. All that's left is iptables if you want to implement any form of
network access restrictions for pop3 and imap with dovecot.

This reminds me very, very much of the vsftpd bug from a few releases
back.

Our pop3/imap services have *ALWAYS* obeyed tcp_wrappers restrictions
in the past. This is a reduction in functionality between rhel3 and 4
and most definitely is *NOT* an improvement.

I did not request to run dovecot via xinetd. I requested to link
dovecot against tcp_wrapper's library to honor /etc/hosts.{deny,allow}
settings.
This is easy to check every incoming connection with this library and
much more simple than using iptables.

Using the firewall (iptables) is the preferred method to control external
access. If you need some of the other access control offered by tcp_wrappers you
can run dovecot under xinetd, see the link below for instructions on how to run
dovecot under xinetd.

http://wiki.dovecot.org/moin.cgi/InetdInstall?highlight=%28inetd%29

Another alternative to tcp_wrappers is to take advantage of dovecots security
and authentication mechanisms that are already built into dovecot (e.g. only
authenticated users can connect to the server). You also have the option of
using pam to fine tune access control once authentication is turned on.

It's not just a matter of linking against the tcp wrappers library, the source
code has to be modified in a number of places, dovecot does not come with
tcp_wrapper support in the source code. I've checked, and we do not have a
policy of tcp_wrapper support for services, there exists several alternative
solutions, closing won't fix.