>> Regardless of whether or not some other system process issued an >> EXPUNGE command, the EXPUNGE has not been announced in the >> session. > That is not what I observe: > IMAP C: 8 Store 15 +Flags.Silent (\deleted) > IMAP S: 8 OK Success > IMAP C: 9 NOOP > IMAP S: * 15 EXPUNGE > * 15 EXISTS > 9 OK Success > Expunge is announced just fine.
You misunderstand. By doing the NOOP, you caused the EXPUNGE to be announced. The scenario under discussion is: IMAP DEBUG 16:18:55 10/23: 00000065 STORE 13 +Flags (\DELETED) IMAP DEBUG 16:18:55 10/23: * 13 FETCH (FLAGS (\Seen \Deleted)) IMAP DEBUG 16:18:55 10/23: 00000065 OK Success ...aiiieee, I didn't want to do that... IMAP DEBUG 16:18:56 10/23: 00000066 STORE 13 -Flags (\DELETED) IMAP DEBUG 16:18:56 10/23: 00000066 NO Unable to store flags (Failure) This is completely unacceptable behavior from an IMAP server. > Of course it does not break undelete, the mail is still kept in > "[Gmail]/All Mail" folder. You misunderstand again. Capricious, idiosyncratic behavior such as this unacceptable. Consider an IMAP client that only knows about INBOX; it neither creates, nor lists, nor uses any other mailbox name. There is no mention of "[Gmail]/All Mail" anywhere in RFC 3501. Why should this perfectly valid and compliant IMAP client be broken? It's like claiming that it's alright for a server to do an implicit delete+expunge of a message as a result of a COPY command, on the grounds that the server assumes that the user intended to move rather than copy the message. Let's twist the knife in further; the same server doesn't even leave the message in the destination of the copy, on the grounds that the server assumes that the user intended to move to trash and we all know that lazy users never empty the trash so let's do it for him. It's not enough to comply with the syntax of the protocol; it is necessary as well to comply with the functionality of the protocol. _________________________________________________________________ When your life is on the go—take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/_______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
