wasm-demo/demo/ermis-f/imap-protocol/cur/1600094972.22523.mbox:2,S

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>