Delivery and fetching of new email inconsistent

[Brian Wong]

On 10/2/07, Alain Spineux <aspineux at gmail.com> wrote:
> On 10/2/07, Brian Wong <bwlist at gmail.com> 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.