64 lines
2.6 KiB
Plaintext
64 lines
2.6 KiB
Plaintext
MBOX-Line: From bill.shannon at sun.com Tue Sep 12 13:08:11 2006
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Shannon <bill.shannon@sun.com>
|
|
Date: Fri Jun 8 12:34:37 2018
|
|
Subject: [Imap-protocol] reporting/detecting expunged messages
|
|
In-Reply-To: <Pine.WNT.4.65.0609111648410.5544@Tomobiki-Cho.CAC.Washington.EDU>
|
|
References: <4505F2FE.8090807@sun.com>
|
|
<Pine.WNT.4.65.0609111648410.5544@Tomobiki-Cho.CAC.Washington.EDU>
|
|
Message-ID: <450713AB.4090601@sun.com>
|
|
|
|
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.
|
|
|