[Dovecot] Dovecot response to "FETCH" command
Alex Tang
altitude at funkware.com
Fri Mar 4 01:18:46 EET 2005
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.
>
>
>
More information about the dovecot
mailing list