[Dovecot] Thunderbird caching problem
Using a fairly simple dovecot config (which obviously needs some max limit tweaking) we have problems with IMAP synchronization between thunderbird clients.
Two TB clients in the same IMAP mailbox will, from time to time, show different views of the same INBOX folders, when TB caching is enabled. The only fix is to right-click on the folder, go to "Properties" and use the "Repair Folder" option which repairs the local TB .msf cache file.
Is there any server-side fix/workaround that would keep TB from regularly going out-of-sync ? This happens with TB3 and newer versions, in concert with either dovecot 1 or 2.
The obvious fix is to disable TB local caching, which unfortunately also disables certain search features and can be a pain for large mailboxes.
dovecot -n
2.0.13: /etc/dovecot/dovecot.conf
doveconf: Warning: service auth { client_limit=4096 } is lower than required under max. load (7168) doveconf: Warning: service anvil { client_limit=2048 } is lower than required under max. load (3075)
OS: OpenBSD 5.0 amd64 ffs
auth_default_realm = dovecot.org auth_mechanisms = plain digest-md5 cram-md5 apop auth_username_translation = :@ default_client_limit = 2048 default_internal_user = _dovecot default_login_user = _dovenull default_process_limit = 1024 disable_plaintext_auth = no first_valid_gid = 125 first_valid_uid = 125 mail_location = maildir:/mail/%d/%n/ managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date mbox_write_locks = fcntl mmap_disable = yes passdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve sieve_global_path = /etc/dovecot/default.sieve } protocols = imap pop3 lmtp sieve service auth { unix_listener auth-userdb { user = mail } } service managesieve-login { inet_listener sieve { port = 4190 } inet_listener sieve_deprecated { port = 2000 } } ssl_cert = </etc/balls/balls-cert.pem ssl_key = </etc/balls/balls-key.pem userdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } protocol lda { mail_plugins = sieve } protocol imap { imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags mail_max_userip_connections = 50 } protocol pop3 { mail_max_userip_connections = 50 pop3_client_workarounds = outlook-no-nuls oe-ns-eoh pop3_save_uidl = yes pop3_uidl_format = %v-%u }
On 08/31/2011 02:59 PM, Chris Cappuccio wrote:
Using a fairly simple dovecot config (which obviously needs some max limit tweaking) we have problems with IMAP synchronization between thunderbird clients.
Two TB clients in the same IMAP mailbox will, from time to time, show different views of the same INBOX folders, when TB caching is enabled. The only fix is to right-click on the folder, go to "Properties" and use the "Repair Folder" option which repairs the local TB .msf cache file.
Is there any server-side fix/workaround that would keep TB from regularly going out-of-sync ? This happens with TB3 and newer versions, in concert with either dovecot 1 or 2.
I ran into exactly this problem as well, it is infuriating. A workaround was discussed here awhile back. Sticking this in the "protocol imap" block of dovecot.conf solved the problem completely:
imap_capability = IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDP LUS LIST-EXTENDED I18NLEVEL=1 ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS
That should all be one line; watch for wrappage.
-Dave-- Dave McGuire Port Charlotte, FL
Dave McGuire [mcguire@neurotica.com] wrote:
On 08/31/2011 02:59 PM, Chris Cappuccio wrote:
Using a fairly simple dovecot config (which obviously needs some max limit tweaking) we have problems with IMAP synchronization between thunderbird clients.
Two TB clients in the same IMAP mailbox will, from time to time, show different views of the same INBOX folders, when TB caching is enabled. The only fix is to right-click on the folder, go to "Properties" and use the "Repair Folder" option which repairs the local TB .msf cache file.
Is there any server-side fix/workaround that would keep TB from regularly going out-of-sync ? This happens with TB3 and newer versions, in concert with either dovecot 1 or 2.
I ran into exactly this problem as well, it is infuriating. A workaround was discussed here awhile back. Sticking this in the "protocol imap" block of dovecot.conf solved the problem completely:
imap_capability = IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDP LUS LIST-EXTENDED I18NLEVEL=1 ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS
Interesting..How do I know that I really should be announcing all of these capabilities given my current dovecot version and config?
With the config I posted, here's what I send out now
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Blahfart
Chris Cappuccio wrote:
Dave McGuire [mcguire@neurotica.com] wrote:
On 08/31/2011 02:59 PM, Chris Cappuccio wrote:
Using a fairly simple dovecot config (which obviously needs some max limit tweaking) we have problems with IMAP synchronization between thunderbird clients.
Two TB clients in the same IMAP mailbox will, from time to time, show different views of the same INBOX folders, when TB caching is enabled. The only fix is to right-click on the folder, go to "Properties" and use the "Repair Folder" option which repairs the local TB .msf cache file.
Is there any server-side fix/workaround that would keep TB from regularly going out-of-sync ? This happens with TB3 and newer versions, in concert with either dovecot 1 or 2. I ran into exactly this problem as well, it is infuriating. A workaround was discussed here awhile back. Sticking this in the "protocol imap" block of dovecot.conf solved the problem completely:
imap_capability = IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDP LUS LIST-EXTENDED I18NLEVEL=1 ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS
Interesting..How do I know that I really should be announcing all of these capabilities given my current dovecot version and config?
With the config I posted, here's what I send out now
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Blahfart
This is before login, you need to verify after login. Dovecot changes the capabilities it advertises after login. Remove CONDSTORE and QRESYNC; the CONDSTORE is the one messing it up for you. QRESYNC also implies CONDSTORE so you need to disable this one as well.
N.
On 31/08/2011 20:56, Nick Rosier wrote:
Chris Cappuccio wrote:
Dave McGuire [mcguire@neurotica.com] wrote:
Interesting..How do I know that I really should be announcing all of these capabilities given my current dovecot version and config?
With the config I posted, here's what I send out now
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Blahfart
This is before login, you need to verify after login. Dovecot changes the capabilities it advertises after login. Remove CONDSTORE and QRESYNC; the CONDSTORE is the one messing it up for you. QRESYNC also implies CONDSTORE so you need to disable this one as well.
N.
What you are doing is disabling CONDSTORE. You can do this on a machine by machine basis by going into the Thunderbird advanced configuration page and toggling: mail.server.default.use_condstore
Note, others have reported NOT having problems when using Cyrus..?
For me it happens:
- Using the same username to login to the same inboxes from separate machines
- Both users behind the same NAT (nat timeouts and missed messages a possibility)
- Rarely
Possibly:
- The user that gets affected has been idle for a while (see NAT idea above)
- That user is either viewing the affected folder, or recently viewed the folder.
Someone needs to catch this thing in the act and get a network trace so that we can put this thing to bed. It happens so rarely for me (and in such large folders) that it's not practical to get a trace.
Also note that for me it's mainly a case that I see messages marked unread, when someone else marked them read. This is often fixed by restarting TB (possibly a clue). I don't think I ever need to force a re-download of all messages?
Good luck
Ed W
participants (4)
-
Chris Cappuccio
-
Dave McGuire
-
Ed W
-
Nick Rosier