[Imap-protocol] reporting/detecting expunged messages

Bill Shannon bill.shannon at sun.com
Tue Sep 12 13:08:11 PDT 2006


Mark Crispin wrote:

> Bill,

>

> Part of the server behavior that caused you such problems is described

> in RFC 2180 section 4.1.2.

>

> I objected to that section being including in RFC 2180. In my opinion,

> the behaviors of RFC 2180 sections 4.1.1 and 4.1.4 are the only

> acceptable ones for the expunged message scenario. A server with an

> inferior mail store may be forced to exhibit the 4.1.3 behavior; but

> this should not be considered "acceptable" behavior.


I agree, 4.1.3 is the worst by far. There's just no reasonable way for
the client to know what's going on.


> The best behavior is section 4.1.1, and this is what the mbx and mix

> mail format support in UW imapd does.

>

> In any case, I consider any server that returns NO to a FETCH to be

> broken in spite of RFC 2180 section 4.1.2. I deeply regret ever listing

> NO as a possible response to a FETCH in the base specification; it was

> there "for completeness" at a time before it was understood that some

> commands didn't have to have all three responses.

>

> However, this is definitely a server bug:

> A5 FETCH 1 (BODYSTRUCTURE)

> * 1 FETCH (FLAGS (\Deleted))

> A5 OK FETCH completed.

> since the server replied OK without returning a BODYSTRUCTURE (not even

> a fake RFC 2180 section 4.1.3 one).


Ok, I'll ask the customer to report it. The customer claims the server is:
Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.6944.0


> Just about the only reasonable thing that you can do, following

> unexpected responses to a FETCH, is to do a NOOP (which would allow

> untagged EXPUNGE events) and see if that makes the world become sane again.


Yup, that looks like the best approach.


> As for an EXPUNGED response code, I would much rather abolish RFC 2180

> section 4.1.2 (and preferably also section 4.1.3) entirely than add

> another complication to an already overly-complex protocol.


4.1.2 is tolerable since at least the client has some clue that something
is wrong, although an EXPUNGED response code would still be helpful in
this case.

4.1.3 is completely unacceptable. If this remains allowed behavior, an
EXPUNGED response code should be *required* for this case.

Thanks for your help.



More information about the Imap-protocol mailing list