November 2017 - dovecot

Re: iPhone/iPad IMAP connection bursts causes user+IP exceeded
by David.M.Clark 30 Nov '17

30 Nov '17

Thanks for the reply and suggestion Robert. I have now set mail_max_userip_connections to 400 in 20-imap.conf to see if it makes any difference. Late yesterday the customer tested from his office, an older IOS 9 tablet and he had IMAP working in a matter of minutes, so is certainly an newer software version by Apple issue. On 30/11/17 03:03, Robert Giles wrote: > David, > > I'd say that if you set the mail_max_userip_connections value to a > large-ish number (300-400), your users likely won't notice an issue on > their iOS 10.x and iOS 11.x devices. It's more of an annoyance in the > logs, and occasionally the iOS Mail app will show that it is stuck > checking mail for a few minutes (when the new max_userip_connections is > reached again, but with a large number, it happens much less frequently). > > Keep in mind max_userip applies to *authenticated* users, so a true, > malicious DoS situation is less likely. > > And yeah, I'm definitely tired of Apple going off and breaking their > software, because the blame always comes back on IT instead of Apple :( > > Robert > > > > On 2017-11-28 at 22:18, David.M.Clark wrote: >> Robert just got this one today. >> >> A customer has phoned who has replaced or updated their Apple 'stuff' >> (including iPhone 8 just purchased) and the identical settings that >> work on the older Apple based devices, as well as Outlook based PCs, >> work fine with IMAP (internal port 143 and external port 10143), but >> the newer IOS based devices just do not work. iPhone 8 does not let >> you downgrade to earlier OS either, which is something the customer >> was thinking of doing. >> >> Once again either Apple or Microsoft have 'moved the goal posts' >> expecting everyone else in the world to be forced to move with them. >> >> They are reporting issues on-line also with MS server and Office 365 >> so will be hoping we have some kind of good result quickly from Apple >> as this will only get worse as more people update and find their >> e-mail is 'dead in the water'. >> >> On 04/11/17 06:19, Robert Giles wrote: >>> Apologies for bumping Joseph Tam's rather old thread, but I'm >>> wondering if anyone has come up with a workaround/fix for this >>> problem that iOS Mail.app clients (10.3.3, 11.0.3, 11.1?) continue to >>> exhibit? >>> >>> Robert >>> >>> >>> >>> On 10/28/2016 at 03:49 PM, Joseph Tam wrote: >>>> I frequently see this from my iPhone/iPad IMAP users: >>>> >>>> Oct 24 21:30:55 server dovecot: imap-login: Login: user=<user>, >>>> ... >>>> [... repeated 10 times ...] >>>> Oct 24 21:32:54 server dovecot: imap-login: Maximum number of >>>> connections from user+IP exceeded (mail_max_userip_connections=12): >>>> user=<user> >>>> Oct 24 21:32:54 server dovecot: imap(user): Logged out ... >>>> [... repeated 11 times ...] >>>> >>>> These bursts of logins/max/logouts would cycling on for a few minutes. >>>> Googling this problem seems to turn up lots of similar complaints about >>>> iOS mail mail clients. e.g. >>>> >>>> https://discussions.apple.com/thread/2547839?tstart=0 >>>> >>>> iOS mail readers do not limit connections limit as other mailreaders >>>> can. I could increase mail_max_userip_connections, but that just moves >>>> the goal posts. >>>> >>>> Using the new rawlog feature in 2.2.26 (thanks Dovecot team!), I was >>>> able >>>> to see that these connection bursts are caused by clients doing global >>>> searches. The rawlogs show each mailbox being SELECT'd and searched >>>> (e.g. From header string): >>>> >>>> 1477369968.730450 2 ID ("name" "iPad Mail" "version" "13G36" >>>> "os" "iOS" "os-version" "9.3.5 (13G36)") >>>> 1477369968.781932 3 SELECT {mailbox} >>>> 1477369968.961636 4 UID SEARCH RETURN (COUNT) 1:* NOT DELETED >>>> 1477369969.006087 5 UID SEARCH RETURN (ALL) 1:* NOT DELETED >>>> 1477369969.052701 6 UID SEARCH RETURN (ALL) {search-term} NOT >>>> DELETED >>>> 1477369974.624153 7 LOGOUT >>>> >>>> Questions: >>>> >>>> 1) How does this affect the user? I heard from one user that it >>>> makes global searches unusable because his reader just spins its >>>> wheel. I'm not sure whether this is impatience or this results >>>> in failed searches. >>>> >>>> 2) Is there a client-side fix (e.g. connection limiting)? >>>> Apple appears to be intransigent on addressing this. >>>> >>>> 3) Will maintaining search indices (e.g. solr) help with this? >>>> Maybe the searches are taking too long and the connections pile >>>> up waiting for previous searches to finish. >>>> >>>> Thanks, >>>> Joseph Tam <jtam.home(a)gmail.com> >>> >> > -- As always, I remain at your service. Kindest Regards, David.M.Clark (Director - Senior Linux/UNIX Consultant) =--------------------------------------------------------------------------= Davrom Consulting Pty Ltd Mobile: 0418763124 PO Box 1644, Sunnybank Hills, 4109 E-mail (Work): david(a)davrom.com ABN: 81 096 990 804 E-mail (Priv): dmc1961(a)dmc1961.id.au Website: http://davrom.com Skype: dmc1961 Podcast: http://ldup.com.au Google: dmc1961(a)gmail.com =--------------------------------------------------------------------------= Specialising in: Linux (Fedora/RedHat/CentOS), UNIX, SCO, MikroTik, Networking/Internet, E-mail/Web Technologies =--------------------------------------------------------------------------= Please note: Any e-mail communication bearing this signature is for the exclusive purpose of the sender and is not for publication without the expressed permission of the sender or respective sender's organisation. =--------------------------------------------------------------------------=

1 1

My Solr FTS problem
by Gao 30 Nov '17

30 Nov '17

I am testing the solr FTS following the guide here: http://things.m31.ch/?p=379 Now I am having problem when I try to test: # doveadm -v index -u fail2ban(a)mydomain.com Inbox doveadm(fail2ban(a)mydomain.com): Error: fts_solr: Invalid XML input at 1:0: not well-formed (invalid token) (near: { "responseHeader":{ "status":0, "QTime":0, "params":{ "q":"box:8864fa1d51ea1d5a7b12000096a1aaf8 AND user:fa) doveadm(fail2ban(a)mydomain.com): Error: Mailbox INBOX: Status lookup failed: Internal error occurred. Refer to server log for more information. [2017-11-30 13:05:24] My system is CentOS 7, Dovecot 3.2.4 (installed from source with solr support), Java OpenJDK-1.8.0, Solr v7.1.0. Could some one help me on this please? Here is detailed debug out put: [root@mail ~]# doveadm -vD index -u fail2ban(a)mydomain.com Inbox Debug: Loading modules from directory: /usr/lib64/dovecot Debug: Module loaded: /usr/lib64/dovecot/lib10_quota_plugin.so Debug: Module loaded: /usr/lib64/dovecot/lib20_fts_plugin.so Debug: Module loaded: /usr/lib64/dovecot/lib21_fts_solr_plugin.so Debug: Loading modules from directory: /usr/lib64/dovecot/doveadm Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: acl_user_module (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_expire_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_deinit (this is usually intentional, so just ignore this message) Debug: Module loaded: /usr/lib64/dovecot/doveadm/lib10_doveadm_quota_plugin.so Debug: Module loaded: /usr/lib64/dovecot/doveadm/lib10_doveadm_sieve_plugin.so Debug: Module loaded: /usr/lib64/dovecot/doveadm/lib20_doveadm_fts_plugin.so Debug: Skipping module doveadm_mail_crypt_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/libdoveadm_mail_crypt_plugin.so: undefined symbol: mail_crypt_box_get_pvt_digests (this is usually intentional, so just ignore this message) doveadm(fail2ban(a)mydomain.com): Debug: Added userdb setting: mail=maildir:/home/vmail/mydomain.com/fail2ban/ doveadm(fail2ban(a)mydomain.com): Debug: Added userdb setting: plugin/quota_rule=*:bytes=0 doveadm(fail2ban(a)mydomain.com): Debug: Effective uid=5000, gid=5000, home=/home/vmail/mydomain.com/fail2ban/ doveadm(fail2ban(a)mydomain.com): Debug: Quota root: name=User quota backend=maildir args= doveadm(fail2ban(a)mydomain.com): Debug: Quota rule: root=User quota mailbox=* bytes=0 messages=0 doveadm(fail2ban(a)mydomain.com): Debug: Quota rule: root=User quota mailbox=Trash bytes=+104857600 messages=0 doveadm(fail2ban(a)mydomain.com): Debug: Quota warning: bytes=0 (90%) messages=0 reverse=no command=quota-warning 90 fail2ban(a)mydomain.com mydomain.com doveadm(fail2ban(a)mydomain.com): Debug: Quota warning: bytes=0 (80%) messages=0 reverse=no command=quota-warning 80 fail2ban(a)mydomain.com mydomain.com doveadm(fail2ban(a)mydomain.com): Debug: Quota grace: root=User quota bytes=0 (10%) doveadm(fail2ban(a)mydomain.com): Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:/home/vmail/mydomain.com/fail2ban/ doveadm(fail2ban(a)mydomain.com): Debug: maildir++: root=/home/vmail/mydomain.com/fail2ban, index=, indexpvt=, control=, inbox=/home/vmail/mydomain.com/fail2ban, alt= doveadm(fail2ban(a)mydomain.com): Debug: quota: quota_over_flag check: quota_over_script unset - skipping doveadm(fail2ban(a)mydomain.com): Debug: INBOX: Mailbox opened because: index doveadm(fail2ban(a)mydomain.com): Debug: http-client: host 127.0.0.1: Host created doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Peer created doveadm(fail2ban(a)mydomain.com): Debug: http-client: queue http://127.0.0.1:8983: Setting up connection to 127.0.0.1:8983 (1 requests pending) doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Linked queue http://127.0.0.1:8983 (1 queues linked) doveadm(fail2ban(a)mydomain.com): Debug: http-client: queue http://127.0.0.1:8983: Started new connection to 127.0.0.1:8983 doveadm(fail2ban(a)mydomain.com): Debug: http-client: request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…]: Submitted doveadm(fail2ban(a)mydomain.com): Debug: http-client: Waiting for 1 requests to finish doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Creating 1 new connections to handle requests (already 0 usable, connecting to 0, closing 0) doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Making new connection 1 of 1 doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: HTTP connection created (1 parallel connections exist) doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Connected doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Ready for requests doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Successfully connected (connections=1) doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Using 1 idle connections to handle 1 requests (1 total connections ready) doveadm(fail2ban(a)mydomain.com): Debug: http-client: queue http://127.0.0.1:8983: Connection to peer 127.0.0.1:8983 claimed request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…] doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Claimed request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…] doveadm(fail2ban(a)mydomain.com): Debug: http-client: request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…]: Sent header doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: No more requests to service for this peer (1 connections exist) doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Got 200 response for request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…] (took 3 ms + 2 ms in queue) doveadm(fail2ban(a)mydomain.com): Error: fts_solr: Invalid XML input at 1:0: not well-formed (invalid token) (near: { "responseHeader":{ "status":0, "QTime":1, "params":{ "q":"box:8864fa1d51ea1d5a7b12000096a1aaf8 AND user:fa) doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Response payload stream destroyed (0 ms after initial response) doveadm(fail2ban(a)mydomain.com): Debug: http-client: request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…]: Finished doveadm(fail2ban(a)mydomain.com): Debug: http-client: queue http://127.0.0.1:8983: Dropping request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…] doveadm(fail2ban(a)mydomain.com): Debug: http-client: host 127.0.0.1: Host is idle (timeout = 100 msecs) doveadm(fail2ban(a)mydomain.com): Debug: http-client: request [Req1: GET http://127.0.0.1:8983/solr/dovecot/select?fl=uid&rows=1&sort=uid+desc&q=box…]: Free (requests left=1) doveadm(fail2ban(a)mydomain.com): Debug: http-client: All requests finished doveadm(fail2ban(a)mydomain.com): Error: Mailbox INBOX: Status lookup failed: Internal error occurred. Refer to server log for more information. [2017-11-30 13:13:57] doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Peer close doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Peer disconnect doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Peer closed doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Connection disconnect doveadm(fail2ban(a)mydomain.com): Debug: http-client: conn 127.0.0.1:8983 [0]: Connection destroy doveadm(fail2ban(a)mydomain.com): Debug: http-client: peer 127.0.0.1:8983: Peer destroy doveadm(fail2ban(a)mydomain.com): Debug: http-client: host 127.0.0.1: Host destroy doveadm(fail2ban(a)mydomain.com): Debug: http-client: queue http://127.0.0.1:8983: Destroy

2 2

Username character disallowed by auth_username_chars: 0x13
by Alex 30 Nov '17

30 Nov '17

Hi, I'm receiving the following messages in my mail logs that I haven't seen before: Nov 28 22:45:31 bwipropemail dovecot: auth: login(?,179.210.41.21): Username character disallowed by auth_username_chars: 0x13 (username: AB?) Nov 28 22:45:31 bwipropemail dovecot: auth: login(?,179.210.41.21): Username character disallowed by auth_username_chars: 0x13 (username: AB?) There's thousands of them, from hundreds of different IP addresses. I suspect it's an exploit attempt, but does anyone know which? I've added a fail2ban entry, but I'd also like to make sure my dovecot is not vulnerable. This is on a fc25 system with all updates.

2 2

Detect port number of SASL AUTH request?
by MRob 30 Nov '17

30 Nov '17

Hi, this is partly Postfix related, but I want to know if there could be way to distinguish port of the SASL AUTH request to segregate user services. Currently I use unix listener for dovecot sasl auth, but could change to inet_listener. Only way I can think is to have different SASL AUTH services for each master.cf entry where its needed. But is it possible for Dovecot to have more than one SASL AUTH services with different configuration setup? It would be nicer if there was a way for Postfix to tell Dovecot about the port the client connected on. Or maybe it can be done with a SASL realm? I'm not sure how? Any help please?

2 1

Plugin 'sieve_imapsieve' not found
by Christopher Satchell 30 Nov '17

30 Nov '17

Hello, when Dovecot launches (and pretty much at any action afterwards) it always throws following error: | managesieve: Fatal: Plugin 'sieve_imapsieve' not found from directory /usr/lib/dovecot/modules/sieve | config: Error: managesieve-login: dump-capability process returned 89 dovecot-sieve and dovecot-managesieved are both installed and the only plugin in the mentioned folder is `lib90_sieve_extprograms_plugin.so`. `doveconf -n` output: # 2.2.22 (fe789d2): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.13 (7b14904) managesieve(username): Fatal: Plugin 'sieve_imapsieve' not found from directory /usr/lib/dovecot/modules/sieve doveconf: Error: managesieve-login: dump-capability process returned 89 # OS: Linux 4.4.0-101-generic x86_64 Ubuntu 16.04.3 LTS auth_mechanisms = plain login mail_gid = vmail mail_home = /var/vmail/mailboxes/%d/%n mail_location = maildir:~/mail:LAYOUT=fs mail_privileged_group = vmail mail_uid = vmail namespace inbox { inbox = yes location = mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Sent { auto = subscribe special_use = \Sent } mailbox Spam { auto = subscribe special_use = \Junk } mailbox Trash { auto = subscribe special_use = \Trash } prefix = } passdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } plugin { imapsieve_mailbox1_before = file:/var/vmail/sieve/global/learn-spam.sieve imapsieve_mailbox1_causes = COPY imapsieve_mailbox1_name = Spam imapsieve_mailbox2_before = file:/var/vmail/sieve/global/learn-ham.sieve imapsieve_mailbox2_causes = COPY imapsieve_mailbox2_from = Spam imapsieve_mailbox2_name = * quota = maildir:User quota quota_exceeded_message = Benutzer %u hat das Speichervolumen überschritten. / User %u has exhausted allowed storage space. sieve = file:/var/vmail/sieve/%d/%n/scripts;active=/var/vmail/sieve/%d/%n/active-script.sieve sieve_before = /var/vmail/sieve/global/spam-global.sieve sieve_global_extensions = +vnd.dovecot.pipe sieve_pipe_bin_dir = /usr/bin sieve_plugins = sieve_imapsieve sieve_extprograms } protocols = imap lmtp sieve service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-userdb { group = vmail mode = 0660 user = vmail } } service imap-login { inet_listener imap { port = 143 } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } user = vmail } service managesieve-login { inet_listener sieve { port = 4190 } } ssl = required ssl_cert = </etc/letsencrypt/live/mail.domain.tld/fullchain.pem ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA ssl_dh_parameters_length = 2048 ssl_key = </etc/letsencrypt/live/mail.domain.tld/privkey.pem ssl_prefer_server_ciphers = yes ssl_protocols = !SSLv3 userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } protocol imap { imap_idle_notify_interval = 29 mins mail_max_userip_connections = 20 mail_plugins = " quota imap_quota imap_sieve" } protocol lmtp { mail_plugins = " sieve" postmaster_address = postmaster(a)domain.tld } Thanks in advance. Chris

3 3

dovecot - 2 Faktor Auth
by Hajo Locke 30 Nov '17

30 Nov '17

Hallo Liste, hat sich schon mal jemand mit 2 Faktor Auth für dovecot beschäftigt? Es geht dabei nicht nur um die Absicherung einer Weboberfläche sondern direkt die Absicherung der Standard pop/imap Verbindungen des Clients. Wir machen das auth bisher über MySQL. Rein technisch würde das gehen, da man die Password-Query beliebig anpassen und auch mit allow_nets arbeiten kann. Es wäre eher die Herausforderung für den Client den 2. Faktor zu erfüllen und seine IP freizuschalten. Man müsste dann ja Clients wie Thunderbird veranlassen irgendwie die Challenge des 2. Faktors anzuzeigen und zu erfüllen. Vermutlich kann man das nur mit speziellen Clients z.B. einer eigenen App machen. Hat jemand in dem Bereich Erfahrung und kann diese teilen? Danke, Hajo

2 1

ManageSieve: authenticate "EXTERNAL" not behaving correctly
by Marc Weustink 30 Nov '17

30 Nov '17

Hi, I've enabled client certificate authentication for imap and managesieve. When I use Thunderbird with the sieve plugin it tries to login, but times out. Initially I reported this to the sieve plugin, but we came to the conclusion that it managesieve is misbehaving. https://github.com/thsmi/sieve/issues/94 Thunderbird (win10-64) 52.4.0 (32bit) Sieve 0.2.3k Dovecot (Ubuntu 16.04.3 LTS) 2.2.33.1-1 (sid) What happens is the following (p=plugin sends m=managesieve sends) p:authenticate "EXTERNAL" "" m:"" The response is unexpected. According to RFC 5804 an empty challenge/response is sent as an empty string. So I would expect: p:authenticate "EXTERNAL" "" m:OK "Logged in." With the use of gnutls-cli I could reproduce (c=I send m=managesieve sends) gnutls-cli --starttls --x509keyfile marc_mail.key --x509certfile marc_mail.crt -p sieve 172.17.1.4 ... m:OK "TLS negotiation successful." c:authenticate "EXTERNAL" "" m:"" c:"" m:OK "Logged in." However if I try the "imap" syntax (rfc4959) I get logged in at once ... m:OK "TLS negotiation successful." c:authenticate "EXTERNAL" "=" m:OK "Logged in." Note that this is an imap only extention, "=" is an invalid base64 encoding. Marc

2 4

Re: iPhone/iPad IMAP connection bursts causes user+IP exceeded
by Joseph Tam 30 Nov '17

30 Nov '17

On 30/11/17 03:03, Robert Giles wrote: >> David, >> >> I'd say that if you set the mail_max_userip_connections value to a >> large-ish number (300-400), your users likely won't notice an issue on >> their iOS 10.x and iOS 11.x devices.? It's more of an annoyance in the >> logs, and occasionally the iOS Mail app will show that it is stuck >> checking mail for a few minutes (when the new max_userip_connections is >> reached again, but with a large number, it happens much less frequently). >> >> Keep in mind max_userip applies to *authenticated* users, so a true, >> malicious DoS situation is less likely. Maybe not malicious DoS, but if your running a shared platform, or supports hundreds of users using Apple products, you can do the arithmetic and see that you can run into problems with resource starvation. >> And yeah, I'm definitely tired of Apple going off and breaking their >> software, because the blame always comes back on IT instead of Apple :( Apple, are you listening? Would it kill you to design your software not to treat remote mail servers like personal servers that can serve up connections like candy? (I also see that some iOS clients keeps an open SMTP connection on standby, even though it's not sending mail.) Joseph Tam <jtam.home(a)gmail.com>

1 0

iPhone/iPad IMAP connection bursts causes user+IP exceeded
by Joseph Tam 29 Nov '17

29 Nov '17

I frequently see this from my iPhone/iPad IMAP users: Oct 24 21:30:55 server dovecot: imap-login: Login: user=<user>, ... [... repeated 10 times ...] Oct 24 21:32:54 server dovecot: imap-login: Maximum number of connections from user+IP exceeded (mail_max_userip_connections=12): user=<user> Oct 24 21:32:54 server dovecot: imap(user): Logged out ... [... repeated 11 times ...] These bursts of logins/max/logouts would cycling on for a few minutes. Googling this problem seems to turn up lots of similar complaints about iOS mail mail clients. e.g. https://discussions.apple.com/thread/2547839?tstart=0 iOS mail readers do not limit connections limit as other mailreaders can. I could increase mail_max_userip_connections, but that just moves the goal posts. Using the new rawlog feature in 2.2.26 (thanks Dovecot team!), I was able to see that these connection bursts are caused by clients doing global searches. The rawlogs show each mailbox being SELECT'd and searched (e.g. From header string): 1477369968.730450 2 ID ("name" "iPad Mail" "version" "13G36" "os" "iOS" "os-version" "9.3.5 (13G36)") 1477369968.781932 3 SELECT {mailbox} 1477369968.961636 4 UID SEARCH RETURN (COUNT) 1:* NOT DELETED 1477369969.006087 5 UID SEARCH RETURN (ALL) 1:* NOT DELETED 1477369969.052701 6 UID SEARCH RETURN (ALL) {search-term} NOT DELETED 1477369974.624153 7 LOGOUT Questions: 1) How does this affect the user? I heard from one user that it makes global searches unusable because his reader just spins its wheel. I'm not sure whether this is impatience or this results in failed searches. 2) Is there a client-side fix (e.g. connection limiting)? Apple appears to be intransigent on addressing this. 3) Will maintaining search indices (e.g. solr) help with this? Maybe the searches are taking too long and the connections pile up waiting for previous searches to finish. Thanks, Joseph Tam <jtam.home(a)gmail.com>

3 2

XDOVECOT capability?
by Hogne Vevle 28 Nov '17

28 Nov '17

Hi! Here and there, I'm seeing mentions of a "XDOVECOT" capability - e.g. on https://documentation.open-xchange.com/7.8.2/middleware/components/search/c… . However, I can't seem to find any documentation on what this actually does. We need to add this capability to our servers in order for certain functionality of Open Xchange App Suite to work properly (as seen in the link above), but we don't want to blindly update our entire Dovecot cluster just because their docs tell us to :) Can someone, please, shed some light on what other effects we can expect to see after enabling this capability, if any? Or is it simply a way of telling clients that "Hey, I'm a Dovecot server" - nothing else? Cheers, - Hogne

2 1