Question about CYRUS-IMAP and FETCH BODY[]

[Paulino Calderon]

Bron Gondwana wrote:
> On Thu, Mar 19, 2009 at 06:20:49PM -0600, Paulino Calderon wrote:
>   
>> Sebastian Hagedorn wrote:
>>     
>>> -- Paulino Calderon <paulino.calderon at gmail.com> is rumored to have 
>>> mumbled on 19. März 2009 11:40:53 -0600 regarding Re: Question about 
>>> CYRUS-IMAP and FETCH BODY[]:
>>>
>>>       
>>>>>> As you can see, the connection is being established succesfully but 
>>>>>> our
>>>>>> program ( it was running OK for almost 2 years btw ) is sending a:
>>>>>>
>>>>>> IMAP<SEQ #> FETCH <MSG #> BODY[1]
>>>>>>             
>>>>> actually that's not true. It's sending a *UID* FETCH, which is
>>>>> something quite different.
>>>>>
>>>>>           
>>>>>> And the server is only responding:
>>>>>> IMAP<SEQ #> Ok Completed (0.000 sec)
>>>>>>             
>>>>> That's quite correct if no message with UID 2 exists ... you've given
>>>>> no indication that it *does* exist.
>>>>>           
>>>> Umm, well after a:
>>>> IMAP<SEQ #> SELECT INBOX
>>>> The server is responding:
>>>> http://calder0n.com/cyrus-imap-selectinbox-response.png
>>>>         
>>> So? I still see no evidence that a message with *UID* 2 exists. The 
>>> response only shows that a message with *sequence number* 2 exists! 
>>> That's why I said that the actual command is quite different from what 
>>> you claimed it was. This command will give you a response whenever 
>>> there are at least two messages:
>>>       
>> Sorry about that. What command should I send to retrieve the uids of the 
>> unseen messages?  The output in the image shows the traffic between the 
>> program it used to work and the server, i didnt send those commands 
>> manually. So "FETCH <#> BODY[1]" was working before. I assumed that 2 ( 
>> on the screenshot) was from the unseen response after a "select inbox".
>>
>> Thanks again.
>>     
>
> TAG UID SEARCH UNSEEN
>
> (e.g. this on my INBOX)
>
> ----------------------------
>
> . select inbox
> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen hasnoatt hasatt
> * selected medeleted NonJunk receipt-handled)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen hasnoatt
> * hasatt selected medeleted NonJunk receipt-handled \*)]
> * 887 EXISTS
> * 1 RECENT
> * OK [UNSEEN 882]
> * OK [UIDVALIDITY 1148523981]
> * OK [UIDNEXT 379340]
> * OK [NOMODSEQ] Sorry, modsequences have not been enabled on this
> * mailbox
> * OK [URLMECH INTERNAL]
> . OK [READ-WRITE] Completed
> TAG UID SEARCH UNSEEN
> * SEARCH 379334 379335 379336 379337 379338 379339
> TAG OK Completed (6 msgs in 0.010 secs)
> TAG SEARCH UNSEEN
> * SEARCH 882 883 884 885 886 887
> TAG OK Completed (6 msgs in 0.000 secs)
>
> ----------------------------
>
> The second one being sequence numbers rather than UIDs.  It's the
> "UID" in the command that makes the difference.
>
> Bron.
>   

Yeah I've realized it would be for the best to replace that old library. 
It's going to fail again if we leave it there. Anyway, I'm still curious 
why it broke after the upgrade, what do you guys think? Is it just not 
following a newer RFC as it's supposed to?

The library we're using is:

http://www.codeproject.com/KB/IP/imaplibrary.aspx