34 lines
1.3 KiB
Plaintext
34 lines
1.3 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Fri Nov 30 03:56:24 2018
|
|
To: imap-protocol@u.washington.edu
|
|
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
Date: Fri Nov 30 03:56:52 2018
|
|
Subject: [Imap-protocol] Unsolicited server responses
|
|
In-Reply-To: <f3131ad7-bfdb-895e-2938-0a03962b91cd@chartertn.net>
|
|
References: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
|
|
<f3131ad7-bfdb-895e-2938-0a03962b91cd@chartertn.net>
|
|
Message-ID: <4d4d7b4f-5744-492f-8bac-1622e92ab59d@gulbrandsen.priv.no>
|
|
|
|
>> Given that the server can unilaterally send updates to the
|
|
>> client, why was the IDLE extension useful/necessary?
|
|
>
|
|
> I'm no expert but I don't think I have seen an IMAP server that
|
|
> sends unsolicited EXISTS or EXPUNGE responses when not in IDLE
|
|
> mode.
|
|
|
|
I've co-written one that sends a sends a very small number of responses and
|
|
then stops, which hasn't caused problems. I've heard that another server
|
|
sent an unlimited number of responses using blocking i/o, and that would
|
|
cause problems if the client wasn't listening.
|
|
|
|
IIRC more servers send unsolicited responses occasionally, to keep NAT
|
|
middleboxes from discarding the connection.
|
|
|
|
> "While the spec [RFC3501 I assume] actually does allow a server
|
|
> to push EXISTS responses asynchronously, a client can't expect
|
|
> this behavior and must poll."
|
|
|
|
That's the key.
|
|
|
|
Arnt
|
|
|