[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