Update message list on recent messages stopped working

[rosali]

We have a lot of complaints on roundcubeforum.net that updating the message list on recent messages stopped working. This issue occurs obviously for various IMAP backends.

I have tried to track it down on hMailServer (./prgram/steps/mail/check_recent.inc) and found out that ...

$IMAP->messagecount(NULL, 'RECENT', TRUE)

... already toggles the recent flag. It meets the condition ...

if($recent_count = $IMAP->messagecount(NULL, 'RECENT', TRUE))

... but when creating the $header object by ...

$header = $IMAP->get_headers($id, NULL, FALSE);

... $header->recent ...

... results in NULL or FALSE, because the recent flag was already toggled before.

At the end of all the condition ...

if ($header->recent)

... fails and the list is not updated.

I hope you can follow this steps!

[rosali]

Log of check_recent.inc with hMailServer

[rosali]

Sorry, just noticed that is a reopened ticket #1484136 for the same issue. Nethertheless, may be my info's and the log snippet might be helpfull.

[alec]

I see a few possibilities to fix this. Use EXAMINE instead of SELECT to determine recent messages count. This shouldn't modify \Recent flag as described in RFC "EXAMINE MUST NOT cause messages to lose the \Recent flag". hMailServer probably changes the message \Recent flag in SELECT or FETCH, dovecot isn't doing that. Second way is just to remove "if ($header->recent)" condition. Finally we can fetch headers of messages using SEARCH RECENT call.

[alec]

EXAMINE instead of SELECT

[alec]

I was wrong. EXAMINE will not help, because to make SEARCH/FETCH we need to select mailbox. ;) It would be nice to know for sure when the \Recent flag is changing.

[rosali]

./program/steps/mail/check_recent.inc -> $IMAP->messagecount(NULL, 'RECENT', TRUE);

... ends up in ...

./program/lib/imap.inc around line 822:

if (iil_PutLine($conn->fp, "sel1 SELECT \"".iil_Escape($mailbox).'"')) {

... and exactly there the recent flag is changed by hMailServer!

Did you want me to debug it this way?

[alec]

I'm still not sure if this isn't a bug in hMailServer. I think that even with SELECT the \Recent flag shouldn't be changed in the same session. Just to be sure, please execute

sel1 SELECT mailbox
sel1 SELECT mailbox
sch1 SEARCH ALL RECENT

in one session (connection) and show the output.

[rosali]

Replying to alec:

See attached screenshot ... both SELECT show 1 RECENT, SEARCH returns total messages regardless if seen/unseen or recent

[alec]

So, SEARCH isn't changing the flag, it must be FETCH. Please, do the last test, run:

sel1 SELECT mailbox
sch1 SEARCH ALL RECENT
sel1 SELECT mailbox
fuid FETCH XX (UID FLAGS)
sel1 SELECT mailbox

where XX is a message id returned in SEARCH response.

[rosali]

No, last sel1 SELECT INBOX still shows "1 recent" ...

But 'xy FETCH start:end flags' does not return any messages with a \RECENT flag

[rosali]

I noticed that closing the connection after SELECT toggles the recent flag ... So, my debugging was false, because I just terminated the script by EXIT and then checked the database for the flag. When I exit telnet after SELECT the flag is toggled too ...

[rosali]

Obiously hMailServer - and as fas as I see from the complaints on the forum other servers too - simply does not return a \RECENT flag on FETCH.

hMailServer changes all recent flags of a box when the box received a SELECT when quitting the session (logout).

As a workaround I simply changed if($header->recent) to if(!$header->seen).

If you really want to check the \RECENT flags the attached sequence will indicate it.

[alec]

Please check attached check_recent.patch.

[rosali]

Works perfect! Thanks!

[alec]

Fixed in [2e1809e5].

[stridger]

We are still seeing this in 0.3.1 . The left pane updates the new message count just fine, but the message list on the right is not refreshed...

[stridger]

Replying to stridger:

We are still seeing this in 0.3.1 . The left pane updates the new message count just fine, but the message list on the right is not refreshed...

Sorry, #1486106 is probably more appropriate for this now. Ignore my comment, I will post it in the other ticket.