#590 accepted
Menza Dudley

Too many connections error

Reported by Menza Dudley | January 17th, 2014 @ 12:52 AM

I have a gmail (Google Apps) account. Every so often i receive the error shown on the screenshot. Clicking OK does not do anything. Clicking cancel results in the email account being taken offline. Sometimes I can get it back online immediately and sometimes it is a few minutes before I can bring it back online.

Comments and changes to this ticket

  • benny

    benny January 17th, 2014 @ 06:23 PM

    • State changed from “new” to “closed”

    Google (and many other IMAP providers) enforce a maximum number of open connections by a Gmail user. The current maximum is documented to be 15.

    By default, MailMate uses at most 3 connections. You might be using other email clients or MailMate on multiple machines (or anything else talking to Gmail via IMAP for some reason). Any mobile devices configured for your account also counts. (I don't know if Google also counts SMTP connections. They don't mention that on the page linked above).

    Some times connections are not properly closed by email clients (for various reasons) and then it won't be available before it “times out” on the server. This can make it tricky to stay under the limit.

    You can see the connections MailMate make to the server in the Activity Viewer (⌥⌘0).

  • benny

    benny January 21st, 2014 @ 02:47 PM


    First, it's not only the number of devices but also the number of email clients. If you run 5 email clients and they use 3 connections each then 15 is reached.

    There is nothing MailMate can do with respect to getting a connection if “Too many simultaneous connections” is reported. I don't know how other email clients can obtain a connection if MailMate cannot. Some thoughts:

    1. MailMate uses at most 3 connections and the error is reported even if 2/3 works and the third one fails. This is because there is no safe way for MailMate to determine what the problem is (the only standard part of the error is [ALERT] which tells MailMate to inform the user).

    2. MailMate releases the connections shortly after they are not needed anymore. This might make it more likely that there are no free connections when MailMate needs to reconnect (because they are then taken by other email clients).

    Note that you can use the Terminal command lsof to review the connections used by MailMate and other applications. Do it like this:

    lsof -i":imaps" | grep "1e100.net"

    The 1e100.net hostname belongs to Google. A live view can be obtained using the nettop command, but this is a bit harder to use.

    I'll consider if I should try to improve item 1 above. I guess that no matter the reason then I could let MailMate quietly use fewer connections as long as at least 1 connection works. (This is not quite as trivial as it sounds :-) ).

  • benny

    benny January 21st, 2014 @ 03:08 PM

    • State changed from “closed” to “accepted”

    As noted MailMate complains even if it's 1 out of 3 connections that fail. When closing MailMate then 2 of 3 connections are released and that might be enough for the other applications. As noted I'll look into improving how MailMate behaves when it's not the first connection that fails. I've put the ticket back in “accepted” state to track progress on this.

    The output is interesting. There is a Notes application using 4 connections. Do you know what that is about? Maybe it uses the problematic Gmail account?

    There is a lot of MailMate connections, but you had multiple accounts which makes it hard to see if any of them use more than 3 connections. You could perhaps take all other than the problematic account offline?

  • benny

    benny January 22nd, 2014 @ 12:34 AM

    I'm not sure, but the fact that Notes has the connections in a CLOSE_WAIT state might indicate that the Notes app is “leaking” connections. When you have this problem then try quitting Notes and see if it helps.

    I've just implemented a kind of balancer for the number of connections to a given server. When authentication fails and it's not the primary connection then the password requester is not shown. Instead I decrease the maximum number of connections used and setup a timer to increase it again later on. I've tested it with a Gmail account with an initial maximum of 16 connections (to trigger the limitation) and it seems to work fine. I expect to have a test version for you at the end of the week. Note that this does not solve the problem if not even 1 connection can be made to the server.

    Thanks for the feedback.

  • benny

    benny January 23rd, 2014 @ 10:55 AM

    Hold down ⌥ when clicking “Check Now” in the Software Update preferences pane to fetch the latest test release (r3962). I've introduced an IMAP “balancer” which should automatically try to reduce the number of connections used by MailMate until the last one fails. It doesn't solve the problem if no connections can be made, but it might reduce the number of requesters shown.

  • benny

    benny January 24th, 2014 @ 09:55 AM

    How many Gmail accounts do you have online with this output?

    And you are running r3962 now? (See the About window.)

    You can watch whether or not the new IMAP balancer is doing anything. Write this in the Terminal:

    defaults write com.freron.MailMate MmMonitorIMAPBalancer -bool YES

    Then launch MailMate like this:


    MailMate outputs whenever it increases/decreases the number of connections for an account.

  • benny

    benny January 24th, 2014 @ 02:12 PM

    How many Gmail accounts are online?

    Also relaunch MailMate if you didn't do so.

  • Jon Phipps

    Jon Phipps April 5th, 2014 @ 03:01 PM

    • Tag set to authentication, gmail, imap

    I note that this is still open and I'd like to add something...

    I recently tested several email apps, along with the official Gmail app, on my iPad and iPhone, both running iOS7.1. Three of these apps use the 'background update' feature of ios7 that leaves them running, and connecting, in the background. Shortly after this I started getting the “[ALERT] Too many simultaneous connections. (Failure)” error. It took me a bit of thinking to figure out what was likely happening because the apps had been installed over several days, and they weren't apparently running on my devices.

    Since MailMate was the only app that displayed an error and failed to reconnect, I naturally assumed that it was a MailMate problem. I now assume that the other apps failed silently and used some other strategy for recovering -- none of them failed to continue to download messages in the background.

    Given that they likely failed and also recovered silently, perhaps there's another strategy MailMate could use to try to recover from this rather than requesting a re-login?

    note: one Gmail account, IMAP access, 2-factor auth enabled

  • benny

    benny April 7th, 2014 @ 11:41 AM

    @Jon: Thanks for the feedback. You might be right that this is just a question about MailMate being better at ignoring these errors for a while, but I'm not quite convinced about that yet. As an experiment, it could be interesting to detect this specific Gmail error and then retry repeatedly after a fixed number of seconds until it can reconnect. Just to see if it's a very short-lived problem.

    Do you still have this problem or was it only while experimenting with iOS apps?

  • benny

    benny April 22nd, 2014 @ 12:55 PM

    @Patrick: You can keep the Activity Viewer open and then use “Help ▸ Send Server Logs” when it happens. I have another report about this, but it is still unresolved (so far I cannot see that MailMate does anything wrong).

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket