read state not propagated
I have migrated the inbox namespace from mbox to mdbox by doing a doveadm backup to the new server. Both servers are having CentOS7 + dovecot-2.2.36-6.el7_8.1.x86_64, both servers have identical configurations (new server has some different vsz_limits and stats enabled)
Now a user complains that an imap mailbox he opens at the same time with a colleague does not propagate the 'read' state. Previously if his colleague read the message, it would show on his mailbox also 'read'. After the transfer it keeps being unread for him.
Am I correct to assume that he should indeed get an updated to 'read'? Where should I look to fix this? What can be the cause of this?
On 29/12/2020 13:22 Marc Roos m.roos@f1-outsourcing.eu wrote:
I have migrated the inbox namespace from mbox to mdbox by doing a doveadm backup to the new server. Both servers are having CentOS7 + dovecot-2.2.36-6.el7_8.1.x86_64, both servers have identical configurations (new server has some different vsz_limits and stats enabled)
Now a user complains that an imap mailbox he opens at the same time with a colleague does not propagate the 'read' state. Previously if his colleague read the message, it would show on his mailbox also 'read'. After the transfer it keeps being unread for him.
Am I correct to assume that he should indeed get an updated to 'read'? Where should I look to fix this? What can be the cause of this?
How are they accessing the mailbox? Same credentials?
Aki
I have migrated the inbox namespace from mbox to mdbox by doing a doveadm backup to the new server. Both servers are having CentOS7 + dovecot-2.2.36-6.el7_8.1.x86_64, both servers have identical configurations (new server has some different vsz_limits and stats enabled)
Now a user complains that an imap mailbox he opens at the same time with a colleague does not propagate the 'read' state. Previously if his colleague read the message, it would show on his mailbox also
'read'.
After the transfer it keeps being unread for him.
Am I correct to assume that he should indeed get an updated to 'read'? Where should I look to fix this? What can be the cause of this?
How are they accessing the mailbox? Same credentials?
yes, mostly just 2nd account in apple mail client
On 29/12/2020 13:27 Marc Roos m.roos@f1-outsourcing.eu wrote:
I have migrated the inbox namespace from mbox to mdbox by doing a doveadm backup to the new server. Both servers are having CentOS7 + dovecot-2.2.36-6.el7_8.1.x86_64, both servers have identical configurations (new server has some different vsz_limits and stats enabled)
Now a user complains that an imap mailbox he opens at the same time with a colleague does not propagate the 'read' state. Previously if his colleague read the message, it would show on his mailbox also
'read'.
After the transfer it keeps being unread for him.
Am I correct to assume that he should indeed get an updated to 'read'? Where should I look to fix this? What can be the cause of this?
How are they accessing the mailbox? Same credentials?
yes, mostly just 2nd account in apple mail client
Can you somehow confirm that the "read" status is not available for the 2nd user in dovecot indexes? Maybe use mail_log plugin to see when the flag changes occur?
Aki
Can you somehow confirm that the "read" status is not available for the 2nd user in dovecot indexes? Maybe use mail_log plugin to see when the flag changes occur?
Is it possible to configure this logging for only one users, maybe via this special-userdb?
This would be sufficient not?
plugin { mail_log_fields = flags }
On 30/12/2020 12:19 Marc Roos m.roos@f1-outsourcing.eu wrote:
Can you somehow confirm that the "read" status is not available for the 2nd user in dovecot indexes? Maybe use mail_log plugin to see when the flag changes occur?
Is it possible to configure this logging for only one users, maybe via this special-userdb?
This would be sufficient not?
plugin { mail_log_fields = flags }
You can return
userdb_mail_log_fields = fields-for-this-user
I would recommend having mail_log plugin enabled always. This helps when customers complain about you deleting their mail.
Aki
participants (3)
-
Aki Tuomi
-
aki.tuomi
-
Marc Roos