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...
On Mon, 28 Feb 2005 01:00:08 -0800 Alex Tang <altitude at funkware.com> wrote:> I just converted my site from UW+mbox to dovecot+maildir (stable-test59, > 2005/02/25).Hi Alex This isn't the answer to the question you asked, sorry, but I use SquirrelMail with Dovecot and there are no problems with dates. I suspect your conversion from mbox to Maildir may be the problem. I've done this successfully for a few customers with mb2md and not had date problems. How did you convert mbox-->Maildir? Keith -- ---------------------------------------------------------------------- Business computing support: http://www.tiger-computing.co.uk Linux consultancy: http://www.TheLinuxConsultancy.co.uk ----------------------------------------------------------------------
On Mon, 2005-02-28 at 01:00 -0800, Alex Tang wrote:> 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")This is the ending part of reply for the previous FETCH request.> * 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" notificationThe RFC822.SIZE etc. attributes for this reply come after these headers.> Is the data being sent back by dovecot a valid response?Yes. The order in which attributes are sent inside FETCH request doesn't matter. The {205}..headers.. all belong in one attribute.> 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).Yep. Thunderbird has finally fixed it though, hopefully in next release. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050303/5500a50b/attachment-0001.bin>
Sorry it took so long to respond...i missed this email (DOH!). Thanks for your response Timo. I understand now. I didn't realize that the FLAGS() RFC822... stuff was from the previous message. It makes much more sense now. Thanks again. Dovecot is running like a champ. I am >very< happy. :) ...alex... Timo Sirainen wrote:>On Mon, 2005-02-28 at 01:00 -0800, Alex Tang wrote: > > >>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") >> >> > >This is the ending part of reply for the previous FETCH request. > > > >>* 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 >> >> > >The RFC822.SIZE etc. attributes for this reply come after these headers. > > > >>Is the data being sent back by dovecot a valid response? >> >> > >Yes. The order in which attributes are sent inside FETCH request doesn't >matter. The {205}..headers.. all belong in one attribute. > > > >>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). >> >> > >Yep. Thunderbird has finally fixed it though, hopefully in next release. > > >