Tickets :: [#2634] Message seen/unseen status incorrect

6.0.0-beta1

9/6/25

Summary	Message seen/unseen status incorrect
Queue	IMP
Type	Bug
State	Not A Bug
Priority	1. Low
Owners
Requester	nick (at) cole2 (dot) com
Created	09/20/2005 (7291 days ago)
Due
Updated	10/05/2005 (7276 days ago)
Assigned	09/20/2005 (7291 days ago)
Resolved	10/05/2005 (7276 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

10/05/2005 09:15:12 PM	nick (at) cole2 (dot) com	Comment #12	Reply to this comment
OK I'll point them at this ticket and see what they say!

10/05/2005 08:48:39 PM	Chuck Hagenbuch	Comment #11 State ⇒ Not A Bug	Reply to this comment
Actually that's not consistent at all. :) But it's pretty clear at this point, imo, that it's not IMP that's at fault here. We don't explicitly remove the UNSEEN flag on messages; the imap server is supposed to do that automatically when any part is FETCHed. It sounds like your host's custom server doesn't do this consistently.

10/05/2005 08:22:58 PM	nick (at) cole2 (dot) com	Comment #10	Reply to this comment
Great question - I think you are close. Just done some testing, with the following results: - the only message types which seem to act properly are those with an alternative part, and some text content - those where there is a "part" and no inline content, and those which are essentially plain text, remain unseen in the inbox view despite having been viewed. For example, the latter category includes the auto email which I received from horde ticketing when you updated the ticket. Any help?

10/05/2005 05:17:03 PM	Chuck Hagenbuch	Comment #9	Reply to this comment
When back in the inbox view, some of the read messages are still in bold, denoting unread status, which is incorrect. They can be set to read OK using the explicit [mark as: seen] command. I may have been missing something by not reading quite closely enough here. What is the definition of "some" of the read messages? Messages without any inline parts, perhaps?

10/05/2005 02:44:59 PM	nick (at) cole2 (dot) com	Comment #8	Reply to this comment
Hoster has confirmed that they are not using Dovecot / IMAP proxy. They tell me their email system is custom developed. Dead end?

10/02/2005 07:27:40 PM	nick (at) cole2 (dot) com	Comment #7	Reply to this comment
Thanks Chuck - have asked my hoster.

10/02/2005 01:43:15 PM	Chuck Hagenbuch	Comment #6	Reply to this comment
Sorry - no idea. How do I check? If you're not in charge of the IMAP server, ask the person who is.

09/20/2005 04:04:33 PM	nick (at) cole2 (dot) com	Comment #5	Reply to this comment
Sorry - no idea. How do I check? Definitely using IMAP protocol at back end of IMP.

09/20/2005 03:32:39 PM	Jan Schneider	Comment #4	Reply to this comment
Do you use Dovecot and an imap proxy?

09/20/2005 03:23:44 PM	nick (at) cole2 (dot) com	Comment #3	Reply to this comment
Had a look at ~~bug 152~~ - it seems inconclusive on what the problem is, and what the solution is. Are you able to clarify?

09/20/2005 12:55:56 PM	Jan Schneider	Comment #2 State ⇒ Feedback	Reply to this comment
Maybe a duplicate of ~~bug 152~~?

09/20/2005 10:44:28 AM	nick (at) cole2 (dot) com	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ Message seen/unseen status incorrect Queue ⇒ IMP State ⇒ Unconfirmed	Reply to this comment
Can't find any other reports of this so here goes ... Using Horde 3.0.5 / IMP 4.0.3 talking to an IMAP back end. Common scenario is reading through unread emails, starting at the first unread, and then moving through using either [delete] or [next], and finally back to inbox view either by default ([delete]) or explicitly ([back to inbox]). When back in the inbox view, some of the read messages are still in bold, denoting unread status, which is incorrect. They can be set to read OK using the explicit [mark as: seen] command.