[Imap-protocol] reporting/detecting expunged messages
MRC at CAC.Washington.EDU
Mon Sep 11 17:04:38 PDT 2006
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.
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).
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.
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.
-- Mark --
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
More information about the Imap-protocol