On Wed, 3 Dec 2003, DINH Viet Hoa wrote:
> For unknown commands, it also replies with NO, is this correct ?
> I thought the response for bad syntax was "BAD" ...
You are correct. The correct response for an unknown command, as well as
bad syntax, is BAD.
It is a bug in Courier that it issues "NO" for an unknown command.
> Besides, I thought we could find bug in Courier IMAP only if we used
> weird syntax, but in fact, it seems this is not the case ...
> It seems this is really a very very bad server (to keep polite).
Yes, Courier is a very very bad server.
I gave up on its author years ago. He thinks that in all cases where
Courier disagrees with the IMAP specification, that Courier is right, the
IMAP specification is wrong, I am an idiot, and IMAP is the worst protocol
ever devised.
Here are some other bugs in Courier, off the top of my head, in case you
want to workaround the problems in your client:
It does not implement atoms correctly. He thinks that some atom
characters should be atom-specials so his source code won't be
"spaghetti." [Workaround by not sending atoms for a astring, unless it's
a HEADER.FIELDS list in which case you must use atoms]
It does not implement IMAP ranges correctly. He thinks that ranges should
follow mathematics rather than what IMAP defines; the result is that UID
clients which do n:* can get the wrong result. [Workaround by never using
"*" in a range, so do "FETCH * UID" then "FETCH n:m" and make sure that n
is less than m.]
It does not implement ORDEREDSUBJECT threading correctly; it treats it as
a "SUBJECT DATE" sort. He thinks that since the SORT/THREAD specification
is "just a draft", it's alright to ignore its definition. [Workaround is
to do orderedsubject threading locally.]
It does not implement REFERENCES threading correctly; it does not
collapse dummies in all cases according to the specification. I have no
idea why he thinks that is right, or why he collapses some dummies but not
others. [Workaround is to do references threading locally.]
It sends bogus personal names in address structures that duplicate the
email address, instead of NIL when there's no personal name. I have no
idea why he thinks that is right. [Workaround is to detect and discard
such personal names.]
I believe that it also gets confused when it gets a complex SEARCH.
[Workaround is to do searches locally.]
Rather than slow down interactions with all servers, I only do these
workarounds when "/loser" is in the mail_open() mailbox specification,
e.g.:
{courier.example.com/loser}INBOX
The /loser option was created especially for Courier, but is now defined
in my code as an option to "interoperate with inferior losing servers
which will never get fixed." I have had to implement /loser in my NNTP,
POP3, and SMTP client code as well. It seems that the world is full of
broken servers... :-(
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
