$Id: BUGS,v 1.6 2000/03/14 01:51:27 mrsam Exp $

This is not a list of Courier-IMAP bugs, rather this is a list of bugs in
either the IMAP4REV1 RFC, RFC2060, or various IMAP clients.  Whether it's
the RFC that's broken, or the various IMAP clients, is not always clear.

Pine:

1) Pine chokes on whitespace between BODY and [

2) Pine's implementation of the Drafts folder is buggy, and prevents
   compatibility with SqWebmail's Drafts folder, which is a permanent folder.
   Pine expects to be able to delete and create Drafts at will.
   You can go into Pine's setup, and change postponed-msgs to Drafts, but
   then if you use Pine and sqwebmail concurrently, SqWebmail will complain
   about Pine's deleting the Drafts folder from it.
   Pine should NOT delete the drafts folder when it is empty, and should not
   prompt someone to open a postponed message if the postponed messages folder
   is empty.

3) Occasionally Pine sends a FETCH request with an invalid UID.  This usually
   happens after you resume a postponed message, and send it.  It looks like
   other IMAP servers simply ignore this error condition, however Courier-IMAP
   will return an error message, which Pine shows briefly on the status line.
   This is similar to the Netscape Communicator bug (see below), but not as
   bad.

4) Pine fails to quote certain special characters in the login userid and
   password.

Netscape Communicator:

1) Netscape Communicator insists that the response in HEADER.FIELDS is
terminated by a blank line, supposedly the end of message headers.

However, since Communicator is asking for a subset of headers, I don't
think I should include the additional blank line in the response.

2) If you create a new folder, and immediately open it, Netscape Communicator
sometimes (not always, I can't seem to nail it down when it does or doesn't
do this) sends the following garbage to the IMAP server after selecting the new
folder:

8 UID fetch -1,6 (UID RFC822.SIZE [ blah blah blah ])

A negative message number?

This is syntactically invalid, because all message sequence numbers are defined
as 32-bit unsigned integers, so the - sign is considered to be a syntax error.
Courier-IMAP will send an error message in response to this junk, and
Netscape Communicator will complain.

Solution: exit Communicator *completely*, and restart it.  Just closing
the Message Center window won't be enough.

2a) The same thing happens when you move a message to a different folder,
then open the new folder.

2b) The same thing apparently happens when you click on "Get Messages".
This option will not work with Courier-IMAP until Netscape fixes their
broken code.

3) Netscape Communicator does not do a very good job visualy displaying
a folder hierarchy which includes a mixture of folders that contain both
messages and other subfolders, and folders which contain only other subfolders.
Netscape will display it as if each folder can contain messages.

This won't usually happen if NC is the only IMAP client being used, since
it is not very intuitive how to create folders that contain other folders
only (and not other messages).  This may happen if other IMAP clients,
besides NC, are used to access the maildrop.

4) Certain versions of Netscape Communicator crash when they get an
attachment with a filename that contains backslashes.  It'll lock into
an infinite loop, then when you click stop it will complain "Out of memory".
Definitely there's something that's seriously wrong there.  The following
response causes Communicator to blow chunks:

* 12 FETCH (BODYSTRUCTURE (("text" "html" ("charset" "us-ascii") NIL NIL "7bit" 156 6 NIL NIL NIL)("image" "jpeg" NIL "<part1.38CCE9F2.AA9CB891@erc.de>" NIL "base64" 163260 NIL ("inline" ("filename" "C:\\TEMP\\nsmailA7.jpeg")) NIL) "mixed" ("boundary" "------------D4FEE57DE096D806712EBE49") NIL NIL))


RFC 2060

The IMAP4REV1 RFC is not clear as to what LIST should return for a mailbox
that can contain both messages and other mailboxes.  The RFC strongly implies
that the response should be one LIST reply without \Noinferiors and \Noselect
tags.

However, Pine does not appear to gracefully handle that.  It does handle
the navigation part more or less reasonably.  The mailbox name is shown
with the hierarchy delimiter inside brackets.  Enter opens the contents of
the mailbox, the > key displays the subfolder collection.

However, when copying the message there does not appear to be a way to select
the folder itself.  Only the Enter key responds, which shows the subfolder
collection.

Pine behaves better if this situation is handled by returning two replies with
the same mailbox name.  One reply contains the \Noinferiors tag, the second
reply contains the \Noselect tag.  Pine will display the folder twice in the
folder collections window.  The first entry is displayed like any other folder,
and pressing Enter selects the folder.  The second entry is displayed with the
hierarchy separator appended to it, and pressing Enter shows the subfolder
collection.

Unfortunately, Netscape Communicator has a bug handling this implementation.
The second reply for the same folder appears to "override" the first reply,
and NC will not show any messages in the folder, and you can only select the
subfolders from the hierarchy tree.

To make things worse, Netscape appears to cache the mailbox status, so even
if the \Noselect tag is removed, Netscape Communicator will STILL not show
the folder contents.

Outlook Express

Even when you tell it not to use "subscriptions", Outlook Express still sends
spurious Subscribe/Unsubscribe commands, which forced me to implement a stub
for those function.

OE also persistent problems updating the number of unread messages in each
folder, or visually highlighting new messages in the folder.  Perhaps I'm not
familiar with OE.  It's possible that there might be a bug in Courier-IMAP
too, but neither Pine, nor Communicator, exhibit these symptoms, and I
consider Pine to be the reference implementation of the IMAP protocol.

There have been reports that OE 5.0 does not work at all due to the fact
that the silly thing expects to see UID as the first parameter in the
response to a FETCH.

No, I am not going to add spaghetti code to push UID to the front of the
structured response to a FETCH.  Ask Microsoft to actually read the RFCs
before implementing them.

StarOffice 5.1a and others:

StarOffice's IMAP server doesn't have a good grasp on what IMAP responses
should be like.  For some silly reason, it insists on a period at the end
of a freeform message.  Nothing even close is required by RFC 2060, and
I'm not going to change Courier-IMAP in order to accomodate such silliness.
If you need to use StarOffice's IMAP client, try the following patched.


--- imapd.c.orig	Fri Jan  7 02:47:27 2000
+++ imapd.c	Sun Jan 16 22:31:16 2000
@@ -1131,7 +1131,7 @@
 			writes(tag);
 			writes(" OK ");
 			writes(cmdbuf);
-			writes(" completed\r\n");
+			writes(" completed.\r\n");
 		}
 		writeflush();
 		return (0);


     _________________________________________________________________
   
   Pine is a trademark of the University Of Washington
   
   Netscape Communicator is a trademark of the Netscape Communications
   Corporation
   
   Outlook Express is a trademark of the Microsoft Corporation

   Staroffice is a trademark of Sun Microsystems

     _________________________________________________________________
