Delivery and fetching of new email inconsistent

Scott M. Likens damm at yazzy.org
Mon Oct 1 19:03:15 EDT 2007


Brian,

Here's a stupid question... might be from my ignorance, or just oversight.

But if the email is delivered to an INBOX, unless the client supports
notification... it won't be notified of the new email until it does a
Send/Receive and then it will be aware of it.

I mention this because many Clients such as Outhouse (Outlook) don't
support that kind of notification, so you end up having people setting
their send/receieve time to 60seconds.

Now I notice in your logs it says * 1 Recent... at least in one of them,
so it seems that Cyrus is notifying the IMAP Connection.  Now it comes
down to if the client ignores it or not.  (as you use idled you should
be good in this area).

So then it comes down to which Clients are you using, and if they
support the notification of new email to 'refresh' the INBOX.  I know
Outlook Express, and Outlook don't support that... and they are rather
unbearable for an IMAP connection for most users I run into. 

However Thunderbird works just dandy.... Long drawn out mail for more
information I guess...

Thanks

Scott

Brian Wong 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)
>
> The server is built with the following options
> ./configure --enable-idled --enable-murder --enable-replication
> --enable-listext --with-ldap --with-openssl --with-sasl --with-snmp
> --without-bdb --with-cyrus-user=cyrus --with-cyrus-group=cyrus
>
> I am also using the "Parse Received: headers for internaldate" patch
> from http://cyrus.brong.fastmail.fm/. I believe this is needed to
> retain INTERNALDATE when migrating.
>
> Could the patch from fastmail be the culprit?
> What other steps can I take to help troubleshoot this problem?
>
>
> !DSPAM:47017a8383425432119130!
>   
> ------------------------------------------------------------------------
>
> ----
> 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
>
> !DSPAM:47017a8383425432119130!
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20071001/9798e01b/attachment.html 


More information about the Info-cyrus mailing list