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@scorchedearth.us.proofpoint.com To: altitude@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@xxx.com To: dovecot@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...