33 lines
1.7 KiB
Plaintext
33 lines
1.7 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Feb 19 12:00:59 2019
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Tue Feb 19 12:01:49 2019
|
|
Subject: [Imap-protocol] Gmail IMAP server session timeout
|
|
In-Reply-To: <87f58114-8169-d911-2e2b-e1679c598941@comaxis.com>
|
|
References: <87f58114-8169-d911-2e2b-e1679c598941@comaxis.com>
|
|
Message-ID: <CABa8R6uMZFFs_x0chivVUsj0ZFD4DqR7cLCZzoL11V=8AwH9YA@mail.gmail.com>
|
|
|
|
What time frame are you seeing this in?
|
|
|
|
There's a bunch of different reasons that the server will close a
|
|
connection. There's a maximum number of connections allowed, for example,
|
|
or if the user's primary/secondary servers flip, or if you're connected to
|
|
a secondary because the primary was down and the primary comes back, or the
|
|
primary moves for load balancing, or the servers are restarted for new
|
|
versions. The connection also travels through at least three proxies, and
|
|
those can restart as well (though those won't say BYE). That's all
|
|
relatively rare but can cause connection closes on average daily.
|
|
|
|
If you're seeing consistent closes after an hour or 24h, that's probably
|
|
the auth refresh threshold. I don't recall the specific time frames, and
|
|
it varies between using oauth and regular login, but basically the auth
|
|
time has a limit because we can't easily tell in some circumstances if the
|
|
auth has been revoked, so we close the connection to force a re-login to
|
|
prove you still should have access. It's been a couple years, so I don't
|
|
recall the details.
|
|
|
|
Brandon
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190219/41ef75cc/attachment.html>
|