IMAP COMPRESS=DEFLATE with Dovecot Pro: responses out of sync, logout after SELECT, folders emptied
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: sterod, Unassigned)
Details
Steps to reproduce
Thunderbird 159.0 (64-bit), Windows. Two IMAP accounts on Network Solutions' server netsol-imap-oxcs.hostingplatform.com:993 (SSL/TLS, server ID "Dovecot Pro"), plus five other IMAP accounts (Gmail ×2, Office 365, Securenym ×2) in the same profile.
I started Thunderbird normally. Since late October 2026, the two Networksolutions accoutns failed. I captured an IMAP log with MOZ_LOG=IMAP:4,IMAPAutoSync:4.
Actual results
The two Network Solutions accounts intermittently show no folders, or an empty Inbox. Local .msf files are reset to about 2 KB, and full resyncs are lost at a later restart. The other five accounts are unaffected. Webmail shows all mail intact.
The log shows that after COMPRESS DEFLATE is accepted, the first decompressed line starts with stray bytes (logged as 0x20 0x20 0x20 0xFF 0xFF; possibly a deflate sync-flush marker passed through as text):
13 COMPRESS DEFLATE
13 OK Begin compression.
14 ID ("name" "Thunderbird" "version" "159.0")
- ID ("name" "Dovecot Pro")
From then on, Thunderbird processes each tagged response one command late:
15 select "INBOX"
14 OK ID completed
16 logout <- sent ~2 ms after SELECT, before the SELECT response
- 187 EXISTS
15 OK [READ-WRITE] Select completed
TellThreadToDie: close socket connection
This occurred on 6 of 6 SELECT attempts. During folder discovery, Thunderbird sends create "Trash" before the reply to list "" "Trash" arrives, and the server answers NO [ALREADYEXISTS]. Select URLs use the unknown-delimiter placeholder (select>^INBOX), although the server reports NAMESPACE (("" "/")). Gmail also uses COMPRESS DEFLATE in the same session, and its first decompressed line is clean.
Workaround confirmed: setting mail.server.serverN.use_compress_deflate = false for the two servers fixes it. In a new log, COMPRESS is not sent, there are no stray bytes and no premature LOGOUTs, folders and messages load normally (Inbox 7,707 messages), and the correct / delimiter is used.
Possibly related: the open Mozilla Support question "Thunderbird Empties and Redownloads Folders on Most Restarts" (September 2026, Thunderbird 156) describes the same symptoms.
Expected results
Compressed IMAP sessions with this server should work normally, with folders and messages loading as they do with compression disabled. If the compressed stream is corrupted, Thunderbird should detect it and fall back, or report an error, instead of misreading responses and destroying local folder data.
Correction: the stray characters before * ID ("name" "Dovecot Pro") did not survive in the posted text. In the raw log, the first decompressed line begins with the bytes 0x20 0x20 0x20 0xFF 0xFF (three spaces and two 0xFF bytes), immediately followed by * ID ("name" "Dovecot Pro"). Gmail's first decompressed line in the same session has no such prefix.
Comment 2•13 days ago
|
||
Looks like the same issue as bug 2087454.
Description
•