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@xxx.com To: dovecot@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.