42 lines
1.8 KiB
Plaintext
42 lines
1.8 KiB
Plaintext
MBOX-Line: From guenther+imap at sendmail.com Wed Jan 9 20:23:53 2008
|
|
To: imap-protocol@u.washington.edu
|
|
From: Philip Guenther <guenther+imap@sendmail.com>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] Question on FETCH example in RFC3501
|
|
In-Reply-To: <b6f3249e0801092004x584dac51t2156511e43b7a7d6@mail.gmail.com>
|
|
References: <b6f3249e0801091938m12cbccd6j4fff9f406cf0fee1@mail.gmail.com>
|
|
<alpine.WNT.1.00.0801091945320.3080@Tomobiki-Cho.CAC.Washignton.EDU>
|
|
<b6f3249e0801092004x584dac51t2156511e43b7a7d6@mail.gmail.com>
|
|
Message-ID: <Pine.BSO.4.64.0801092110230.31840@vanye.mho.net>
|
|
|
|
On Thu, 10 Jan 2008, Liam Clarke wrote:
|
|
> Thanks for that - my vague fear is that a poorly behaved server could
|
|
> mix responses to one request with responses for another, which
|
|
> probably betrays my lack of experience with IMAP servers.
|
|
|
|
It's not 100% clear to me what you mean by "mix responses to one requests
|
|
with responses for another". Can a server send back FETCH responses for
|
|
messages that you never asked about? Yes! Can it send back FETCH data
|
|
items that you never asked about? Yes! Indeed, those both commonly occur
|
|
for flags. For example, let's say the flags on messages 2 and 3 have
|
|
changed since the client last sent a command, and then it sends this:
|
|
|
|
a042 FETCH 2 RFC822.SIZE
|
|
|
|
The server may send back the following:
|
|
* 2 FETCH (RFC822.SIZE 123985 FLAGS (\seen \deleted))
|
|
* 3 FETCH (FLAGS (\seen \recent \deleted))
|
|
a042 Ok
|
|
|
|
|
|
IMAP FETCH is effectively a cache-filling protocol: the client asks for
|
|
whatever data that it wants but doesn't already have and is told when all
|
|
that data has been sent. However, the server may send additional,
|
|
unrequested data along the way in order to keep the client's cache up to
|
|
date. c.f. RFC 3501, section 5.2 for what servers are required and
|
|
expected to send without being asked.
|
|
|
|
|
|
Philip Guenther
|
|
|