Arnt Gulbrandsen <[EMAIL PROTECTED]> writes: ... >3501 section 5.5, UID SEARCH. Makes me think, though. Consider this >conversation: > >C: a uid search 1:* >S: * search 1 2 3 4 >S: a ok >C: b fetch 2,4 body[header.fields (from subject)] >S: 2 fetch ... >S: 4 fetch ... >S: b ok >C: c uid search (or 1 3) from larryo >S: 2 expunge >S: * search 1 >S: c ok
[This would be easier to read if the UIDs and msgno didn't overlap...] >Is this even legal? I don't see anything to forbid it. But I also don't >see which message set is searched: uids 1 and 3 or uids 1 and 4? 1 and 3. The client had not been informed of the expunge when it sent the UID command, therefore the msgno 3 in the command refered to uid 3 and not uid 4. The server knows this because it hadn't sent the EXPUNGE response yet and couldn't do so until it had seen the command. Consider that if the above wasn't true, then it would *always* be ambiguous to use a message sequence number criteria with UID SEARCH. If that was a possibility, I would have expected rfc3501 to say so instead of explictly referring to the use of UID SEARCH with msgnos in two different places. The exception proves the rule: section 5.5 makes note of a limitation on when the client can pipeline UID SEARCH with msgnos, so such a command can't always be ambiguous. Philip Guenther [EMAIL PROTECTED]
