Mark Crispin said: > The IMAP specification does not specifically outlaw multiple SEARCH > responses. > > Note that the the IMAP unsolicited data model (e.g. section 7, "The client > MUST be prepared to accept any response at all times") indicates that an > untagged SEARCH can happen at any time; an example even indicates that an > untagged SEARCH can happen (albeit has not obvious purpose) when no SEARCH > command is in progress. > > So it is clearly valid and an IMAP client must accept it. >
We did accept it but the problem was that we only looked at the first untagged search response and didn't parse the following untagged search responses. > The only ambiguity is what to do about it; whether multiple untagged > SEARCH responses are culminative, or if each successive response replaces > the previous one. > > I have always believed that it is culminative (and that is how I > implemented it in my client), but have been unwilling to put that down in > a formal ruling for fear that maybe someone might come up with a reason > for it to replace instead. > Thnx for the clearification. In this case it concerns culminative untagged search responses and since yesterday I handle them correct :) > The real question is why EIMS needs to do this. It is arguably silly > because it wastes 10 octets for each extraneous response in the > culminative case, and much more for the replace case. That's what I wondered too. What I saw is that EIMS only puts 10 UID's in each untagged search response. That requires a lot of untagged search responses for large mailboxes on a UID SEARCH UID 1:* request. Regards, Marc Groot Koerkamp.
