[Dovecot] Restricting Services (POP or IMAP)
It would be great to have a HOWTO in the wiki, on how to restrict services by username in dovecot, so some users are allowed IMAP and others not allowed. As concerns restricting users by IP, I believe that is a bad idea. It's almost a useless idea, imnsho, because they can connect from another IP. It's easy to restrict services by IP using a firewall or by using inetd. -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +======================================================================+ |\ _,,,---,,_ | Odhiambo Washington <wash@wananchi.com> Zzz /,`.-'`' -. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +======================================================================+ Don't take life too seriously -- you'll never get out of it alive.
Odhiambo WASHINGTON wrote:
It would be great to have a HOWTO in the wiki, on how to restrict services by username in dovecot, so some users are allowed IMAP and others not allowed.
As concerns restricting users by IP, I believe that is a bad idea. It's almost a useless idea, imnsho, because they can connect from another IP. It's easy to restrict services by IP using a firewall or by using inetd.
That can be done, at least, with a SQL passwd db, see:
http://wiki.dovecot.org/Authentication/RestrictAccess
-- Rui LopesOn Thu, 2006-08-24 at 17:18 +0100, Rui Lopes wrote:
Odhiambo WASHINGTON wrote:
It would be great to have a HOWTO in the wiki, on how to restrict services by username in dovecot, so some users are allowed IMAP and others not allowed.
As concerns restricting users by IP, I believe that is a bad idea. It's almost a useless idea, imnsho, because they can connect from another IP. It's easy to restrict services by IP using a firewall or by using inetd.
That can be done, at least, with a SQL passwd db, see:
Yea, and actually it can also be done with passwd-file. Updated the wiki page to contain this:
passdb passwd-file {
args = /etc/dovecot/deny.%Ls
deny = yes
}
Hello Odhiambo,
Odhiambo WASHINGTON, 24.08.2006 (d.m.y):
As concerns restricting users by IP, I believe that is a bad idea. It's almost a useless idea, imnsho, because they can connect from another IP. It's easy to restrict services by IP using a firewall or by using inetd.
IMO it would be great if dovecot could use tcpd/libwrap...
Regards, Christian Schmidt
-- Eine Reise beginnt mit einem einzigen Schritt. -- Chinesisches Sprichwort
* On 24/08/06 22:58 +0200, Christian Schmidt wrote: | Hello Odhiambo, | | Odhiambo WASHINGTON, 24.08.2006 (d.m.y): | | > As concerns restricting users by IP, I believe that is a bad idea. | > It's almost a useless idea, imnsho, because they can connect from | > another IP. | > It's easy to restrict services by IP using a firewall or by using | > inetd. | | IMO it would be great if dovecot could use tcpd/libwrap... I agree, but ..... Isn't that true for any service that is started via inetd? It should work if you can start dovecot via inetd, but I don't like the idea either, coz using runit or daemontoools is better. However, I believe support for tcpd/libwrap can be incorporated into dovecot if you can convince Timo to do it, or make it worth his time if you really need it asap ;) If you know some C++, you can get the code from mysqld, exim, etc, which have it already, and submit a patch. -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +======================================================================+ |\ _,,,---,,_ | Odhiambo Washington <wash@wananchi.com> Zzz /,`.-'`' -. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +======================================================================+ Air is water with holes in it
Hello Odhiambo,
Odhiambo WASHINGTON, 25.08.2006 (d.m.y):
- On 24/08/06 22:58 +0200, Christian Schmidt wrote: | | IMO it would be great if dovecot could use tcpd/libwrap...
I agree, but .....
Isn't that true for any service that is started via inetd?
Sure, but I favor services that are running on their own...
It should work if you can start dovecot via inetd, but I don't like the idea either, coz using runit or daemontoools is better. However, I believe support for tcpd/libwrap can be incorporated into dovecot if you can convince Timo to do it,
@Timo: What do you think about it? IMO it can be very useful if a "service" offers its own possibility of blocking hosts and/od networks without depending on external tools like packet filters.
or make it worth his time if you really need it asap ;)
If you know some C++, you can get the code from mysqld, exim, etc, which have it already, and submit a patch.
Unfortunately, the only thing I know about C++ is that it's a programming language. ;-)
Regards, Christian Schmidt
-- Wußten Sie schon, daß der Trabbi den zweiten Preis im Windkanalwettbewerb gewonnen hat? Den ersten gewann eine Schrankwand!
* On 25/08/06 12:02 +0200, Christian Schmidt wrote: | Hello Odhiambo, | | Odhiambo WASHINGTON, 25.08.2006 (d.m.y): | | > * On 24/08/06 22:58 +0200, Christian Schmidt wrote: | > | | > | IMO it would be great if dovecot could use tcpd/libwrap... | > | > I agree, but ..... | > | > Isn't that true for any service that is started via inetd? | | Sure, but I favor services that are running on their own... | | > It should | > work if you can start dovecot via inetd, but I don't like the idea | > either, coz using runit or daemontoools is better. | > However, I believe support for tcpd/libwrap can be incorporated into | > dovecot if you can convince Timo to do it, | | @Timo: What do you think about it? | IMO it can be very useful if a "service" offers its own possibility of | blocking hosts and/od networks without depending on external tools | like packet filters. | | > or make it worth his time if you really need it asap ;) | > | > If you know some C++, you can get the code from mysqld, exim, etc, | > which have it already, and submit a patch. | | Unfortunately, the only thing I know about C++ is that it's a | programming language. ;-) Me too ;) We're on the same train to doom! -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +======================================================================+ |\ _,,,---,,_ | Odhiambo Washington <wash@wananchi.com> Zzz /,`.-'`' -. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +======================================================================+ Very few profundities can be expressed in less than 80 characters.
On Fri, 2006-08-25 at 12:02 +0200, Christian Schmidt wrote:
However, I believe support for tcpd/libwrap can be incorporated into dovecot if you can convince Timo to do it,
@Timo: What do you think about it?
Already done, but since login process is chrooted it won't work unless you create the hosts.* files inside the chroot. So I decided not to include the support for it for now. Maybe in Dovecot 2.0 I'll do something else, like have a separate process handle the checking. Anyway here's the patch:
On Friday 25 Aug 2006 10:49, Odhiambo WASHINGTON wrote:
Isn't that true for any service that is started via inetd? It should work if you can start dovecot via inetd, but I don't like the idea either, coz using runit or daemontoools is better.
On the other hand xinetd offers most, if not all the advantage of these, is backwardly compatible to inetd, supports libwrap, and provides other features.
I think the real case to be made, is why do people keep making standalone servers, with their own server logic, when I've hacked servers into inetd or xinetd.conf without actually changing the program that did what I wanted as a standalone application.
More sophisticated servers make sense when doing event driven architectures, but when doing a process/task per user type approach, it is probably better to use something with the security features of xinetd than reimplement them all over again, miss bits people want, and make mistakes that cause resource exhaustion.
participants (5)
-
Christian Schmidt
-
Odhiambo WASHINGTON
-
Rui Lopes
-
Simon Waters
-
Timo Sirainen