Dovecot 2.2.27 proxy - enforcing per client IP connection limits
Hi,
Trying to keep abusive/buggy IMAP clients at bay on a number of Dovecot
proxy servers, I've reconfigured them to use
"mail_max_userip_connections = 50" in the "protocol imap" section,
followed by restarting Dovecot. Yet, I'm still seeing 160+ established
connections from a single IP address for the same email account. Am I
missing anything?
# 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.16 (fed8554)
# OS: Linux 2.6.32-642.4.2.el6.x86_64 x86_64 CentOS release 6.8 (Final)
auth_cache_negative_ttl = 5 mins
auth_cache_size = 16 M
auth_cache_ttl = 18 hours
default_client_limit = 6120
default_process_limit = 500
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate mime foreverypart
extracttext imapflags notify
mbox_write_locks = fcntl
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
sieve_extensions = +notify +imapflags
}
protocols = imap pop3 lmtp sieve
service auth {
client_limit = 6120
}
service imap-login {
process_limit = 2048
process_min_avail = 20
service_count = 0
vsz_limit = 256 M
}
service imap {
process_limit = 2048
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
service_count = 0
vsz_limit = 128 M
}
service managesieve {
process_limit = 1024
}
service pop3 {
process_limit = 1024
}
[...]
protocol imap {
imap_capability = IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
mail_max_userip_connections = 50
}
--
Adi Pircalabu
Re: v2.2.28 released
On 03/07/2017 02:41 PM, Robert L Mathews wrote: > As a result, I > end up using what seems to be a mostly stable version, plus "extra > patches I grabbed from reading the mailing list". Pretty sure that's what the dovecot enterprise repo is.
Re: v2.2.28 released
On 3/6/17 2:30 PM, Timo Sirainen wrote: > I don't see anything critical. A couple of bugs that might or might > not affect you. We'll have 2.2.29 soon enough, so no plans for other > releases before that. As a comment: When trying to choose which version of Dovecot to use in production, I've found it difficult that minor point releases add new features and make other changes, as well as purely fixing bugs. It's a challenge to find a Dovecot version that fixes known issues without introducing other (possibly problematic) changes. As a result, I end up using what seems to be a mostly stable version, plus "extra patches I grabbed from reading the mailing list". I'm grateful for all the effort put into the code, but for me, at least, it would be easier to work with if new features and changes were only in new versions like 2.3, with 2.2.x only fixing bugs. (And when 2.3 is stable, new features would be in 2.4, with 2.3.x just fixing bugs, and so on.) This is the model used in Postfix development, for example, and I find it easier to work with in terms of finding a known stable version. But again, this could be just me, and I apologize if this has already been suggested and found inappropriate. As I said, I definitely appreciate that the code is constantly being improved. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
iOS Mail app and rapid authenticate / disconnect on Dovecot proxy
Hi folks,
I have a handful of iOS 10.2.1 Mail app IMAP clients that intermittently
break into this unexplained authenticate-then-immediately-disconnect
behavior when connecting to a RHEL7 Dovecot (dovecot-2.2.10-7.el7)
proxy, providing proxied connections to a backend Panda/UW-IMAP server.
From talking to the users, the activity would appear to be spontaneous
(ie: not caused by user interaction with the device).
The behavior doesn't seem to have any observable implications for the
end user, other than momentarily hitting the Dovecot process_limit
(which, if not raised to a rather large number, disrupts new IMAP proxy
connections momentarily).
I reckon this is not an issue with Dovecot, but I'm curious to know if
other folks have observed this behavior when dealing with iOS Mail app
clients?
The log entries look like this:
iOS 10 device = 172.16.0.1
RHEL7 Dovecot proxy host = 192.168.0.1 ("proxyhost")
Panda/UW-IMAP target = panda.imap.tld
Mar 6 12:11:00 proxyhost dovecot: imap-login: proxy(jdoe): started
proxying to panda.imap.tld:993: user=, method=PLAIN,
rip=172.16.0.1, lip=192.168.0.1, TLS, session=
Mar 6 12:11:00 proxyhost dovecot: imap-login: proxy(jdoe):
disconnecting 172.16.0.1 (Disconnected by client): user=,
method=PLAIN, rip=172.16.0.1, lip=192.168.0.1, TLS: Disconnected,
session=
Mar 6 12:11:01 proxyhost dovecot: imap-login: proxy(jdoe): started
proxying to panda.imap.tld:993: user=, method=PLAIN,
rip=172.16.0.1, lip=192.168.0.1, TLS, session=
Mar 6 12:11:01 proxyhost dovecot: imap-login: proxy(jdoe):
disconnecting 172.16.0.1 (Disconnected by server): user=,
method=PLAIN, rip=172.16.0.1, lip=192.168.0.1, TLS,
session=
Mar 6 12:11:01 proxyhost dovecot: imap-login: proxy(jdoe): started
proxying to panda.imap.tld:993: user=, method=PLAIN,
rip=172.16.0.1, lip=192.168.0.1, TLS, session=
Mar 6 12:11:01 proxyhost dovecot: imap-login: proxy(jdoe):
disconnecting 172.16.0.1 (Disconnected by server): user=,
method=PLAIN, rip=172.16.0.1, lip=192.168.0.1, TLS,
session=
Mar 6 12:11:02 proxyhost dovecot: imap-login: proxy(jdoe): started
proxying to panda.imap.tld:993: user=, method=PLAIN,
rip=172.16.0.1, lip=192.168.0.1, TLS, session=
Mar 6 12:11:02 proxyhost dovecot: imap-login: proxy(jdoe):
disconnecting 172.16.0.1 (Disconnected by server): user=,
method=PLAIN, rip=172.16.0.1, lip=192.168.0.1, TLS,
session=
Mar 6 12:11:02 proxyhost dovecot: imap-login: proxy(jdoe): started
proxying to panda.imap.tld:993: user=, method=PLAIN,
rip=172.16.0.1, lip=192.168.0.1, TLS, session=
Mar 6 12:11:02 proxyhost dovecot: imap-login: proxy(jdoe):
disconnecting 172.16.0.1 (Disconnected by server): user=,
method=PLAIN, rip=172.16.0.1, lip=192.168.0.1, TLS,
session=
Mar 6 12:11:03 proxyhost dovecot: imap-login: proxy(jdoe): started
proxying to panda.imap.tld:993: user=, method=PLAIN,
rip=172.16.0.1, lip=192.168.0.1, TLS, session=
Mar 6 12:11:03 proxyhost dovecot: imap-login: proxy(jdoe):
disconnecting 172.16.0.1 (Disconnected by server): user=,
method=PLAIN, rip=172.16.0.1, lip=192.168.0.1, TLS,
session=
Mar 6 12:11:03 proxyhost dovecot: imap-login: proxy(jdoe): started
proxying to panda.imap.tld:993: user=, method=PLAIN,
rip=172.16.0.1, lip=192.168.0.1, TLS, session=
Mar 6 12:11:04 proxyhost dovecot: imap-login: proxy(jdoe):
disconnecting 172.16.0.1 (Disconnected by server): user=,
method=PLAIN, rip=172.16.0.1, lip=192.168.0.1, TLS,
session=
...and on and on, usually until the 'service imap-login' process_limit
is reached. You could naturally apply some iptables rate-limiting to
avoid hitting process_limit, but it'd be nice to have the iOS client
simply behave properly instead.
dovecot -n:
---
# 2.2.10: /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-514.6.2.el7.x86_64 x86_64 Red Hat Enterprise Linux
Server release 7.3 (Maipo)
auth_mechanisms = plain login
auth_verbose = yes
first_valid_uid = 1000
imap_capability = +I18NLEVEL=1
mbox_write_locks = fcntl
passdb {
args = nopassword=y
default_fields = proxy=y ssl=any-cert host=panda.imap.tld
driver = static
}
protocols = imap pop3
service imap-login {
process_limit = 400-ish at the moment
process_min_avail = 2
}
service pop3-login {
inet_listener pop3s {
port = 995
ssl = yes
}
}
ssl = required
ssl_ca =
smime.p7s
Description: S/MIME Cryptographic Signature
Re: v2.2.28 released
On 07.03.2017 10:52, Nagy, Attila wrote: > On 03/06/2017 11:30 PM, Timo Sirainen wrote: >> On 6 Mar 2017, at 9.17, Tom Sommer wrote: >>> >>> On 2017-02-24 14:34, Timo Sirainen wrote: http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz.sig >>> Are there any plans to do a bugfix-release, that includes the few >>> issues seen in the mailing-list, or do you consider 2.2.28 safe to >>> upgrade to? >> I don't see anything critical. A couple of bugs that might or might >> not affect you. We'll have 2.2.29 soon enough, so no plans for other >> releases before that. > Truncating passwords with dict protocol* seems quite critical to me. :-O > Or is it just me, who's affected by that? > > *: http://dovecot.org/list/dovecot/2017-February/107265.html Hi! The password is not actually truncated, it's actually subjected to var_expand, which is silly. We are working on a patch for this and let y'all know when it's ready. The only truncation happens with % as last character. Aki
Re: v2.2.28 released
On 03/06/2017 11:30 PM, Timo Sirainen wrote: On 6 Mar 2017, at 9.17, Tom Sommer wrote: On 2017-02-24 14:34, Timo Sirainen wrote: http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz.sig Are there any plans to do a bugfix-release, that includes the few issues seen in the mailing-list, or do you consider 2.2.28 safe to upgrade to? I don't see anything critical. A couple of bugs that might or might not affect you. We'll have 2.2.29 soon enough, so no plans for other releases before that. Truncating passwords with dict protocol* seems quite critical to me. :-O Or is it just me, who's affected by that? *: http://dovecot.org/list/dovecot/2017-February/107265.html
SiS hashes file ?
Hello, In mdbox SiS POSIX mail box setting - There are hard-links under - /ha/sh/- /ha/sh/- Why is a copy of the file kept under hashes/ ? -- Regards, Sai Kiran
