iPhone/iPad IMAP connection bursts causes user+IP exceeded

Thu Nov 30 00:40:45 EET 2017

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 at 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 at davrom.com
  ABN: 81 096 990 804                  E-mail (Priv): dmc1961 at dmc1961.id.au
  Website: http://davrom.com           Skype: dmc1961
  Podcast: http://ldup.com.au          Google: dmc1961 at 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.
=--------------------------------------------------------------------------=