Sophie

Sophie

distrib > Mageia > 5 > x86_64 > media > core-release > by-pkgid > 922623ff293c7934ad75d88b17778461 > files > 12

courier-imap-4.9.3-9.mga5.x86_64.rpm

<?xml version="1.0" encoding="iso-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <title>Courier-IMAP: BUGS</title>
</head>

<body>
<p>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.</p>

<h2>Pine</h2>
<ol>
  <li>Pine chokes on whitespace between BODY and [</li>
  <li>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.</li>
  <li>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.</li>
  <li>Pine fails to quote certain special characters in the login userid and
    password.</li>
  <li>The CHILDREN draft extension breaks Pine at least up to 4.21.  It is
    necessary to set IMAP_OBSOLETE_CLIENT flag in the configuration file to
    make Pine work.  The problem happens when a message gets sent, when Pine
    sends the following to the server:
    <pre>READ: ATOM: 0000000a
READ: ATOM: LIST
READ: ATOM: INBOX.
READ: ATOM: sent-mail
READ: EOL
WRITE: * LIST (\HasNoChildren) "." "INBOX.sent-mail"^M
0000000a OK LIST completed^M

READ: ATOM: 0000000b
READ: ATOM: CREATE
READ: ATOM: INBOX.sent-mail
READ: EOL
WRITE: 0000000b NO Cannot create this folder.^M</pre>
    <p>Basically Pine is checking if the sent-mail folder exists.  It sends
    the command "(tag) LIST INBOX. sent-mail".  Apparently the \HasNoChildren
    reply causes Pine to toss its cookies, think that the folder does not
    exist, and attempt to create it, which obviously fails.</p>
    <p>Previous versions of Courier-IMAP used the \NoInferiors tag instead of
    \HasNoChildren.  Pine appears to handle that just fine:</p>
    <pre>READ: ATOM: 0000000b
READ: ATOM: LIST
READ: ATOM: INBOX.
READ: ATOM: sent-mail
READ: EOL
WRITE: * LIST (\Noinferiors) "." "INBOX.sent-mail"^M
0000000b OK LIST completed^M

READ: ATOM: 0000000c
READ: ATOM: APPEND
READ: ATOM: INBOX.sent-mail
WRITE: + OK^M</pre>
    <p>\NoInferiors is technically a wrong flag to use here, but that's what,
    apparently is needed to keep Pine happy.  Set the IMAP_OBSOLETE_CLIENT
    flag to get this legacy behavior.</p>
  </li>
  <li>Pine sends a non-empty reference in the LIST command, specifying the
    folder directory.  RFC 2060 clearly indicates that a non-empty reference
    is non-standard behavior:

    <blockquote>
      A non-empty reference name argument is the name of a mailbox or a level
      of mailbox hierarchy, and indicates a context in which the mailbox name
      is interpreted in an implementation-defined manner.</blockquote>
    <p>This is another Pine bug.</p>
  </li>
</ol>

<h2>Netscape Communicator</h2>

<p>Netscape Communicator is ancient history. Upgrade to Mozilla, or
Thunderbird.</p>

<h2>RFC 2060</h2>

<p>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.</p>

<p>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 &gt; key displays the subfolder collection.</p>

<p>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.</p>

<p>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.</p>

<h2>Outlook Express</h2>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h2>StarOffice 5.1a and others</h2>

<p>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 patch:</p>
<pre>--- 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);</pre>
<hr />

<p>Pine is a trademark of the University Of Washington</p>

<p>Outlook Express is a trademark of the Microsoft Corporation</p>

<p>Staroffice is a trademark of Sun Microsystems</p>
<hr />
</body>
</html>