Delivery and fetching of new email inconsistent

[Alain Spineux]

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

Yes it is !
This is unexpected.

-- 
Alain Spineux
aspineux gmail com
May the sources be with you