On 10/2/07, Brian Wong <bwlist@xxxxxxxxx> wrote: > On 10/2/07, Alain Spineux <aspineux@xxxxxxxxx> wrote: > > On 10/2/07, Brian Wong <bwlist@xxxxxxxxx> wrote: > > > List, > > > I am in the process of migrating to Cyrus IMAP. I have a test server > > > (CentOS 5 x86_64) with several accounts and I look forward to placing > > > the IMAP server in production but I have recently noticed a problem. > > > > > > Certain emails that are delivered into a mailbox are not visible to > > > the email client. I believe this may have to do with consecutive > > > emails to the same mailbox with minimal time between the deliveries, > > > but I can not consistently reproduce the problem. In this case, two > > > separate and different emails are delivered and only the first is > > > visible. I do not believe this is a client specific problem. I have > > > the general log files indicating delivery and protocol telemetry logs > > > for the user in question. > > > > > > It is not until I log out and log back in do I see the second message. > > > > > > The relevant log snippets mentioned above are attached. > > > Name: server.log (evidence of consecutive delivery) > > > Name: user_tel.log (from line 259; evidence of only first message > > > visible, but not second) > > > Name: user_tel-2.log (evidence that upon log out and log in, second > > > message appears) > > > Name: imapd.conf (for completeness) > > > Name: cyrus.conf (for completeness) > > > > > > Bear with me as I am not well versed in IMAP protocol specifics. > > > The user telemetry logs show that the IDLE daemon notified the client > > > of a new message through the EXISTS command. When the IMAP client then > > > does a FETCH command, the server only returns the first of the two > > > delivered messages. (user_tel.log) > > > > Maybe a the time of the notification the second message in still not > > delivered and then > > the FETCH can report only one message ! > > > > But when doing the check later : > > > > <1191272540<74 UID fetch 15:* (FLAGS) > > >1191272540>* 6 FETCH (FLAGS (\Recent) UID 14) > > 74 OK Completed (0.000 sec) > > > > I thing here the server should answer with UID 15 > > > > I don't know if answer with UID 14 is an error or an imap feature (we > > are requesting message >=15, but IMAP protocol is very permissive and > > can include some untagged "status" message) > > But a that time the message is in the mailbox and the server should know it ! > > > > Maybe a bug ! > > > > My 2.2.X is also reporting a "UID 14" like message when requesting the > > next one like your 2.3.9. > > > > When sending messages in a short time, my 2.2.X in IDLE mode notify > > the client long time after receiving both mail, and then report them > > both in once. > > > > Hope someone will find more ! > > > > Intead of logoff/login did you try to switch from one folder to > > another then back to the INBOX, to force the client to refresh all the > > emails ? > > > > I did try this to no avail. What my client actual did was open a new > connection and SELECT the new folder and log out. When I switched back > to INBOX, i am thinking that it just did a FETCH on the original > connection which did not return the second message as if I used the > "Check Mail" function. > Yes it is ! This is unexpected. -- Alain Spineux aspineux gmail com May the sources be with you ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
