[Dovecot] Dovecot response to "FETCH" command

[Alex Tang]

Hi folks.

I just converted my site from UW+mbox to dovecot+maildir (stable-test59, 
2005/02/25).  For the most part, everything is great.  The server seems 
faster and less memory intense than the UW server (this part has made me 
very happy).   And it's definitely more user friendly to me than Courier.

There is one thing however...

A few of my users are using the web based mail reader 
(Squirrelmail-1.2.11) that i provide for them. 

Once i converted to dovecot, the squirrelmail users were reporting that 
when viewing the folder list page, 2 things were happening:

    * The date for all of the messages was being displayed as "Sun 4:00 pm"
    * all messages were shown as being "new".  they never would be
      transferred into the "Seen" state.

After doing some IMAP protocol sniffing, i found this difference in the 
way that the UW server and the dovecot server handles the "FETCH" command...

Squirrelmail issues a FETCH command to get message header information 
like this (lines broken with backslashes for readability):

A009 FETCH 1:1 (FLAGS RFC822.SIZE INTERNALDATE BODY.PEEK \
    [HEADER.FIELDS (Date To From Cc Subject X-Priority \
    Content-Type)])

The UW server returns:

* 1 FETCH (FLAGS () RFC822.SIZE 710 \
    INTERNALDATE "27-Feb-2005 23:50:42 -0800" \
    BODY[HEADER.FIELDS ("DATE" "TO" "FROM" "CC" "SUBJECT" \
    "X-PRIORITY" "CONTENT-TYPE")] {153}
Date: Sun, 27 Feb 2005 23:50:42 -0800
From: root <root at scorchedearth.us.proofpoint.com>
To: altitude at scorchedearth.us.proofpoint.com
Subject: asdf
  

When the same FETCH response is returned by dovecot, the response looks 
like this:

FLAGS () RFC822.SIZE 3358 INTERNALDATE "27-Feb-2005 07:55:27 -0800")
* 1 FETCH (BODY[HEADER.FIELDS (DATE TO FROM CC SUBJECT X-PRIORITY CONTENT-TYPE)] {205}
Date: Mon, 28 Feb 2005 00:04:22 +0800
From: xxx xxx <xxx at xxx.com>
To: dovecot at dovecot.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Subject: [Dovecot] "not listening" notification
  

I noticed that in the UW response, the "* 1 FETCH ..." is the first 
line, and contains all of the data except for the message header info. 

However, in the dovecot response, the data is split into 2 lines, and 
the first line is not the "* 1 FETCH" line. 

In reading through the squirrelmail source, squirrelmail is not 
recognizing this as a valid response, and thus the date, size, and flags 
are not being properly set in the internal squirrelmail message 
objects.  This explains why both the date as well as the "seen" status 
of the message is never properly set.

OK, after all this blabbing on...here's my question.

Is the data being sent back by dovecot a valid response?

My knowledge of the IMAP protocol is weak to say the least.  I tried 
reading the IMAP RFC (3501), in particular section 6.4.5 which defines 
the FETCH command), and the RFC seems to specify that the response 
should have the "* # FETCH" lines come first.  However, the RFC seems 
vague, and i didn't wade through any of the other RFCs out there.

I figure it is legal, since the two other clients i've used seem to 
understand it just fine (thunderbird/mozilla, mutt).

However, could this be the reason why mozilla/thunderbird sometimes gets 
the message size wrong (and hence why the "tb-negative-fetch" workaround 
is needed).

For now, i'll bang on squirrelmail to support the response sent by 
dovecot. 

Thanks.

...alex...