52 lines
1.8 KiB
Plaintext
52 lines
1.8 KiB
Plaintext
MBOX-Line: From tss at iki.fi Wed Jan 9 20:36:32 2008
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] Question on FETCH example in RFC3501
|
|
In-Reply-To: <Pine.BSO.4.64.0801092110230.31840@vanye.mho.net>
|
|
References: <b6f3249e0801091938m12cbccd6j4fff9f406cf0fee1@mail.gmail.com>
|
|
<alpine.WNT.1.00.0801091945320.3080@Tomobiki-Cho.CAC.Washignton.EDU>
|
|
<b6f3249e0801092004x584dac51t2156511e43b7a7d6@mail.gmail.com>
|
|
<Pine.BSO.4.64.0801092110230.31840@vanye.mho.net>
|
|
Message-ID: <1199939792.8850.111.camel@hurina>
|
|
|
|
On Wed, 2008-01-09 at 21:23 -0700, Philip Guenther wrote:
|
|
> 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.
|
|
|
|
Also if client sends two commands, the server may mix them:
|
|
|
|
1 fetch 1:2 flags
|
|
2 fetch 1:2 uid
|
|
* 1 fetch (flags (\seen))
|
|
* 1 fetch (uid 100)
|
|
* 2 fetch (flags ())
|
|
* 2 fetch (uid 101)
|
|
2 ok
|
|
1 ok
|
|
|
|
Although I'm not sure if this is allowed:
|
|
|
|
1 fetch 1:2 flags
|
|
2 fetch 1:2 uid
|
|
* 1 fetch (flags (\seen) uid 100)
|
|
* 2 fetch (flags () uid 101)
|
|
2 ok
|
|
1 ok
|
|
|
|
-------------- next part --------------
|
|
A non-text attachment was scrubbed...
|
|
Name: signature.asc
|
|
Type: application/pgp-signature
|
|
Size: 196 bytes
|
|
Desc: This is a digitally signed message part
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080110/ec9d4a37/attachment.sig>
|