iPhone/iPad IMAP connection bursts causes user+IP exceeded
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=0iOS 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 LOGOUTQuestions:
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@gmail.com>
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@gmail.com>
Re-e-mailing, sorry, just realised I replied to Robert, not the entire group :-(
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@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@davrom.com ABN: 81 096 990 804 E-mail (Priv): dmc1961@dmc1961.id.au Website: http://davrom.com Skype: dmc1961 Podcast: http://ldup.com.au Google: dmc1961@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.
participants (3)
-
David.M.Clark
-
Joseph Tam
-
Robert Giles