On Tue, 6 Jan 2004, Richard Bang wrote:
> And I don't know what's wrong with
> SEARCH 1:* UNSEEN
> * SEARCH 1,2,3,4,5,6,7,8,9
> * EXPUNGE 5
> OK SEARCH COMPLETED
>
> Why cant the client just say "oh, immediately after the search message 5
> was removed so I had better make a note of that". Its not rocket
> science.
You still don't understand.
Consider:
A1 SEARCH 1:* UNSEEN
A2 STORE 6 +FLAGS.SILENT (\Deleted)
* SEARCH 1,2,3,4,5,6,7,8,9
* EXPUNGE 5
A1 OK SEARCH completed
A2 OK STORE completed
In other words, the client sent commands A1 and A2 without waiting. Which
message was deleted: original message 6 or original message 7? You don't
know. Nobody knows.
> Maybe a new RFC advisory "RFCXXXX Clients SHOULD NOT issues FETCH STORE
> SEARCH without a NOOP between them", our servers could then issue a "NO
> Client is not RFCXXXX compliant". I bet the client writers would update
> pretty sharpish then.
No non-garbage server would do such a thing. Not only is it wrong, it
doesn't help the problem either.
It isn't the NOOP that causes synchronization. It is the issuance of a
command which requires blocking for the response, and thus is not part of
a streamed sequence of commands.
FETCH, SEARCH, and STORE can be streamed. EXPUNGEs can not happen in the
middle of a streamed sequence.
If you want a lockstep protocol, use POP3. For better or worse, the
decision that IMAP is not a lockstep protocol was made in 1986 and it's
too late to change it now.
> It really is stretching it to say that a server cannot delete a message
> from its store because some mail client MIGHT want to take a look at it
> at some undefined time in the future.
I have seen it happen many times. Everything that went in to the IMAP
specification had a reason.
If you consider me to be credible, then you should pay attention to my
advice. If you don't, then please say so, so I know that it is alright to
delete all future mail from you unread.
> IMO IMAP should not be placing constraints about the operation of the
> whole server (which forcing messages to hang around forever does).
IMAP does. Live is unfair sometimes.
> IMAP as it stands does not seem to cater at all well for shared folders.
I take offense at that statement. Do you think that I am a stupid person
who has no idea about shared mailboxes, and that my years of efforts to
create shared mailboxes on UNIX (at a time when I was told it was
"impossible") were worthless?
Other servers have managed to implement shared mailboxes in IMAP,
including all the servers (note the plural) that I wrote. Other clients
have managed to work with shared mailboxes in IMAP, including all the
clients (note the plural) that I wrote.
For better or worse, complaining, and demanding that existing protocols
and implementations be changed to accomodate a new implementation,
accomplishes nothing (other than making people angry).
Listening to advice, asking questions, and accepting the answers
(especially when it is bad news) accomplishes everything.
> Most clients send NOOPS every 5 minutes and some don't have the faintest
> idea of what a UID is. There is a perfectly good extension IDLE that
> helps BUT only MS seem to have bothered with it.
IDLE does not, repeat *NOT*!!, solve the problem. The fact that you think
that IDLE solves the problem suggests that you still do not fully
understand how IMAP works.
An client which implements IDLE may still stream a long sequence of
commands together without blocking.
The problem is caused by a client not doing a synchronizing command that
ends a streamed sequence. Such a command could be IDLE, NOOP, or for that
matter *any* command other than FETCH, STORE, and SEARCH.
> What is needed is not to try to shift the burden to the servers but
> force the clients to get their act together. An error dialog stating a
> non conformance to an RFC would do that.
My 30 years of experience with network protocols says that this is not
going to happen. Such messages are invariably unpopular and are blamed
upon the server, even in cases in which the RFC supports issuing such a
message.
In this case, however, the RFC does not support issuing such a message.
The RFC is quite emphatic on how IMAP synchronization works. There is an
implicit requirement that both clients and servers be sensible.
Nonsensical behavior from a server is unforgivable. It doesn't matter if
the motivation is to attack possible nonsensical behavior from a client.
> Failing that I will have to tell pretty much all of my customer base
> that the only clients worth using are Outlook and Outlook Express. Which
> would be a sad day for us all !
No, because your server will become well-known and reviled as being
garbage. Eventually, your competitors will steal your customers from you,
and your company will suffer the fate of all companies which demand that
the world be their way instead of everybody else's way.
I'm trying to help you write a good server so this not happen. I am
finding it increasingly difficult to do so.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
