MBOX-Line: From mail at sabahattin-gucukoglu.com  Mon Oct  4 11:32:53 2010
To: imap-protocol@u.washington.edu
From: Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Fwd: iOS IMAP IDLE (Standard "Push Email")
	Deficiency, Explanation?
In-Reply-To: <alpine.OSX.2.00.1010041034520.392@hsinghsing.panda.com>
References: <352410DE-19D8-4EE4-8741-AB82741D7A18@sabahattin-gucukoglu.com>
	<4CAA0F5C.7030009@lists.grepular.com>
	<alpine.OSX.2.00.1010041034520.392@hsinghsing.panda.com>
Message-ID: <7D32DBF6-2ECC-4854-85A8-84261D828ED2@sabahattin-gucukoglu.com>

On 4 Oct 2010, at 18:56, Mark Crispin wrote:
> The real problem with IDLE is that it is NAT-unfriendly.  Most NAT boxes
> drop the mapping after a period of client inactivity, and send a TCP RST
> to the server if the server resumes activity before the client.  Most
> users don't see this, since if the client resumes activity first the same
> mapping is created and no RST is sent.

Yes, indeed, this argument is the most convincing I've actually seen against IDLE, and the compromise is to set a time interval that gets around the NAT's braindead behaviour.  Since most clients are happy to allow users to specify a polling frequency that determines the maximum time between checks, it's not a stretch to turn this into a between DONE-IDLE timer.  The solution is IPv6, of course.

Cheers,
Sabahattin

