[Dovecot] max connects per host?
Hi everyone!
I want to manage mail server resource part (like it can CGP) and with it I have one question. Is any way to limit overall max simultaneous connections to imap/pop3 server from one(each) host, except use iptables/ipfw and so on? Like a patch to dovecot or, maybe, it can be released in future versions?
I know about mail_max_userip_connections in dovecot 1.1
but it can't limit hosts this way.
Thank you.
On Mon, 2008-03-17 at 01:47 +0300, subscriber@viliar.net.ru wrote:
Hi everyone!
I want to manage mail server resource part (like it can CGP) and with it I have one question. Is any way to limit overall max simultaneous connections to imap/pop3 server from one(each) host, except use iptables/ipfw and so on? Like a patch to dovecot or, maybe, it can be released in future versions?
Probably in future versions.
I know about mail_max_userip_connections in dovecot 1.1
It should be pretty easy to patch this code to ignore the user and just limit IPs. You could basically just remove "user" from struct mail_process_group and fix the code to compile. Or even easier:
static struct mail_process_group * mail_process_group_lookup(enum process_type type, const char *user, const struct ip_addr *ip) { user = ""; // use the same empty user for everyone
// ...
static struct mail_process_group * mail_process_group_create(enum process_type type, const char *user, const struct ip_addr *ip) { struct mail_process_group *group;
user = ""; // use the same empty user for everyoneOn Mon, 2008-03-17 at 17:45 +0200, Timo Sirainen wrote:
I know about mail_max_userip_connections in dovecot 1.1
It should be pretty easy to patch this code to ignore the user and just limit IPs. You could basically just remove "user" from struct mail_process_group and fix the code to compile. Or even easier:
static struct mail_process_group * mail_process_group_lookup(enum process_type type, const char *user, const struct ip_addr *ip) { user = ""; // use the same empty user for everyone
// ...
static struct mail_process_group * mail_process_group_create(enum process_type type, const char *user, const struct ip_addr *ip) { struct mail_process_group *group;
user = ""; // use the same empty user for everyone
Sounds like
Probably in future versions.
could be trivially implemented with a "mail_process_group_lookup_key" setting that defaults to %u :)
johannes
Johannes Berg wrote:
On Mon, 2008-03-17 at 17:45 +0200, Timo Sirainen wrote:
I know about mail_max_userip_connections in dovecot 1.1
It should be pretty easy to patch this code to ignore the user and just limit IPs. You could basically just remove "user" from struct mail_process_group and fix the code to compile. Or even easier:
static struct mail_process_group * mail_process_group_lookup(enum process_type type, const char *user, const struct ip_addr *ip) { user = ""; // use the same empty user for everyone
// ...
static struct mail_process_group * mail_process_group_create(enum process_type type, const char *user, const struct ip_addr *ip) { struct mail_process_group *group;
user = ""; // use the same empty user for everyone
Sounds like
Probably in future versions.
could be trivially implemented with a "mail_process_group_lookup_key" setting that defaults to %u :)
johannes
Thank you Timo and Johannes for answers! I have used your recommendations and really enough this small patch: --- src/master/mail-process.c.orig 2008-03-18 19:55:04.000000000 -0400 +++ src/master/mail-process.c 2008-03-18 19:55:35.000000000 -0400 @@ -75,7 +75,8 @@ mail_process_group_lookup(enum process_t struct mail_process_group lookup_group; lookup_group.process.type = type; - lookup_group.user = t_strdup_noconst(user); + /*lookup_group.user = t_strdup_noconst(user);*/ + lookup_group.user = ""; lookup_group.remote_ip = *ip; return hash_lookup(mail_process_groups, &lookup_group); @@ -89,7 +90,8 @@ mail_process_group_create(enum process_t group = i_new(struct mail_process_group, 1); group->process.type = type; - group->user = i_strdup(user); + /*group->user = i_strdup(user);*/ + group->user = ""; group->remote_ip = *ip; i_array_init(&group->processes, 10); --- src/login-common/sasl-server.c.orig 2008-03-19 09:36:56.000000000 -0400 +++ src/login-common/sasl-server.c 2008-03-19 09:37:21.000000000 -0400 @@ -51,7 +51,7 @@ master_callback(struct client *client, e case MASTER_LOGIN_STATUS_INTERNAL_ERROR: break; case MASTER_LOGIN_STATUS_MAX_CONNECTIONS: - data = "Maximum number of connections from user+IP exceeded"; + data = "Maximum number of connections from ip exceeded"; break; } call_client_callback(client, reply, data, NULL); And it is really work. But for probable future option, I think, it is would be wrong way. Because this solution limit user _logins_, not connections. So, just for example, I could make very much connections to server and go to end up dovecot connection pool or, if I miss something here, system resources like max_files, max_sockets and so on. IMHO, more truly solution is limit connections, and check it _before_ login procedure. I understand, that can happen in this case also. But why we will waste our resources to check login/pass, make redundant query to myssql/pgsql/sqlite and so on? What are you think about that? Comments are very welcome. Alex
On 08-03-18 18.34, Alex wrote:
And it is really work. But for probable future option, I think, it is would be wrong way. Because this solution limit user _logins_, not connections. So, just for example, I could make very much connections to server and go to end up dovecot connection pool or, if I miss something here, system resources like max_files, max_sockets and so on. IMHO, more truly solution is limit connections, and check it _before_ login procedure. I understand, that can happen in this case also. But why we will waste our resources to check login/pass, make redundant query to myssql/pgsql/sqlite and so on? What are you think about that? Comments are very welcome.
I would personally use the operating systems firewall software for this. Seems redundant that every piece of software accepting connections should duplicate the functionality of a firewall.
/Johan
participants (5)
-
Alex
-
Johan Fredin
-
Johannes Berg
-
subscriber＠viliar.net.ru
-
Timo Sirainen