From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20020109 BuildID: 20020109 With the Mozilla 0.9.7 release (and th 20020109 nightly build) and connecting to a uw-imap 2000a with Maildir, SSL & Kerberos support (using IMAP4rev1). Messages that I read in my client don't get marked as read on the server. This problem is not present using other IMAP clients (eg Eudora) Reproducible: Always Steps to Reproduce: 1.Get Mail 2.Read mail in mail client (and it gets marked as read) 3. Get Mail again (mail remains marked as unread on server and it gets remarked as unread in mail client) Actual Results: See above Expected Results: Mail should remain marked as read in mail client (and on server)

I have what *appears* to be the same problem on Linux build 2001122108. This just started with 0.9.7 -- 0.9.6 was fine, and I believe 2001121408 was ok. Server is IMAP4rev1 also. The problem seems to be a little bit intermittent, and to me seems to do with moving mail. 1. Open up Mail 2. Click on a new message in INBOX and read it 3. Drag message to IMAP folder 4. Destination IMAP folder now is boldfaced and indicates I have new unread message. I then must go into the destiation folder and read the message *again* before it's marked as read. Deleting a message has the same effect -- I hit 'Delete' when reading the message, and 'Trash' immediately becomes boldfaced and indicates new mail. Happens about 50% of the time, on both moving and deleting.

I have a similar problem (Linux v0.9.9). I use IMAP/Maildir. Messages I read at work get marked read at home, but not vice versa. The main difference is that I leave my mail client running all the time at work. It seems like it is not getting the status update from the server when a message is marked as read by another client. Also note that this problem seems to be Maildir-specific. We recently switched to Maildir, and everything worked fine before the switch.

two confirmations in this bug.. confirming as new

I see exactly the same problem as was reported. But I can reproduce it only sometimes. I use a free IMAP account at the fastmail.fm server. Client - Mozilla 1.0 on Linux.

I see this behaviour on an everyday basis working with Mozilla as my mailclient at work. I read messages in any folder that are marked as new, the message is then correctly marked as read in MailNews. Thought if I leave the client for a while and check back later, the message is _sometimes_ reset to unread. One possible cause of this that fits well with the behaviour is that I have the mailclient check for mail every 5 minutes. The client is checking a number of mailboxes on the server (either forcing it to check all folders or a selection of folders using Mozilla 1.1a) so this takes a few seconds to complete. One guess is that the messages I read while the client is checking for new messages never are marked as read on the server and the client updates the new messages count based on what the server says, not writing back the status of the read messages first. But that's just a guess based on the behavior I see. This happens on Mozilla 1.0rc2 on Win2000, CVS trunk as of 062902 on Linux, Mozilla 1.0 on Solaris.

Bug 159267 might be a better description of this problem. I suggest that this bug be marked as a duplicate of that one.

If viewing the message twice does *not* solve this problem (as it does for me) then this is not a duplicate of bug 159267. However, if not a duplicate of 159267 then this bug is a duplicate of bug 159180 (or vise versa) and should be marked so.

There is a problem that I see this bug only sometimes - not exactly twice every time. Really strange.

I'd like to reconfirm that this is happening several times a day for our users of IMAP mail. We have been upgrading from 1.0 to 1.1a to 1.1b to 1.1, running on Solaris and Linux. The easiest way to reproduce this problem is to have the IMAP server side mail sorting turned on (we use sieve on our Cyrus 2.0.16 server) and read new messages outside of the inbox. I frequently use the "Message -> Mark -> Threas as read" " and "Message -> Mark -> All read" commands on while reading these folders (typical mailing list stuff). Sometimes I have the mark all messages read once, sometimes twice and sometimes up to 4 times before it stayes read. Seems like the number of IMAP server connections (the default is 5) plays a role, I have had users lower this to 2 or 3 and that seemed to make this problem less frequent (but it still happens). My concern here is that we have 5 server connections going in parallell and some connections are used to send \seen messages to the server and some to check for new messages (I have mozilla setup to check for new messages in all these different IMAP folders every 5 minutes). My guess is that there is a synchronization problem between server connections fetching new messages and server connections sending \seen flags to the server but I can't confirm this. I'd like to help solve this bug, where to I start ?

Some more discussions on the Cyrus IMAP mailing lists seems to indicate that this is a problems on the IMAP server side and not in Mozilla. The Cyrus server, older versions at least, have problems synchronizing the when multiple connections are used. Since Mozilla have 5 connections open, this causes problems in the IMAP server. What IMAP software is used by the other reporters on this bug ? (telnet <mailserver host name> 143 ) will tell you.

The fastmail.fm service uses Cyrus IMAP server too.

Here's what my IMAP server says: * OK Courier-IMAP ready. Copyright 1998-2001 Double Precision, Inc. See COPYING for distribution information.

*** Bug 131575 has been marked as a duplicate of this bug. ***

I am seeing this bug for a long time now. It is still present in 1.2beta. Here are the info sent by my IMAP server: * OK [CAPABILITY IMAP4REV1 X-NETSCAPE LOGIN-REFERRALS AUTH=LOGIN] imap1-1.free.f r IMAP4rev1 2001.315/Proxad at Wed, 20 Nov 2002 15:32:45 +0100 (CET) Is there a way to get more precise info? I feel that the priority of this bug should be boosted. It is really an obstacle to adopting Mozilla.

anyone still see this problem?

resolving incomplete since there is no new information since Nov 2002.