Closed Bug 687784 Opened 13 years ago Closed 29 days ago

IMAP tag sync becomes unreliable when more than 10 tags are used

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bozzunter, Unassigned)

References

Details

(Whiteboard: [has protocol logs])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/534.48.3 (KHTML, like Gecko) Version/5.1 Safari/534.48.3 Steps to reproduce: I create more than 10 tags in order to flag my messages. Besides, I send tagged messages to an IMAP account, so that my colleagues (with the same address) can see them and know what to do. Actual results: Tags are perfectly synched until we have 10. If we exceed the number, synchronization becomes erratic, i.e. some are seen, some others are not. With this I mean that I tag a message, I send the message to the IMAP account and my colleagues see the message but not the tag: this problem happens with ALL the tags as soon as 10 is exceeded, it's not only affecting the tags after the 10th. Expected results: All tags should be synched as it happens when we have less than 10. We're using a mix of TB 6.0.2 and TB 7 beta, but the bug is still there.
Can we get an imap log to see what we are sending when this happens (see https://wiki.mozilla.org/MailNews:Logging) ?
Attached file IMAP log of Bozzunter
Attached file IMAP log of Gus
You can find two logs while the problem was reproduced. Bozzunter added a tag INSTRUCCIONES to a message and sent it to IMAP, where the tag disappeared. Then he manually tagged the message and it was seen by Gus. Gus sent another message, tagged as INSTRUCCIONES, and the tag disappeared. Then Bozzunter sent a message to IMAP tagged as ASIGNEU and it was seen.
Attachment #561401 - Attachment mime type: application/octet-stream → application/zip
Attachment #561402 - Attachment mime type: application/octet-stream → application/zip
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Whiteboard: [has protocol logs]
Severity: normal → S3
Summary: Tag sync → IMAP tag sync becomes unreliable when more than 10 tags are used
See Also: → 730250
See Also: → 1901509
See Also: → 729732, 760856, 1504993, 1511362

Gene, does anything in the log suggest the cause? Server not supporting >10 tags?

Flags: needinfo?(gds)

I'm not seeing anything in the logs attached above that tells me much. But I tested last night with more than 10 tags on a cyrus courier imap server as the reporter was using, per the logs. I think I am seeing problems when I go above 10 but need to check some more. Will provide more details in next comments.

Flags: needinfo?(gds)

Corrected above: reporter was using courier imap server (not cyrus).
Above a certain number (somewhere above 10, not exactly 10) courier stops returning new user defined keywords in the PERMANENTFLAGS and FLAGS select responses. So tag previously set won't show up. Seems to be a server problem.
When I do the same exercise using dovecot, I don't see the problem. I can create/set 14 tags (more than the number I set testing courier) on message on tb instance A and see them all set on tb instance B (assuming instance B has all the tag defined in "Manage Tags" dialog.
So marking this bug INVALID.

Status: UNCONFIRMED → RESOLVED
Closed: 29 days ago
Resolution: --- → INVALID

Here's another somewhat off-topic item related to keywords/tags that I've noticed.
Once custom keywords are created in tb and applied to message(s) and then stored by the server, there is no way specified by imap RFCs to get rid of them. So if I store 100 keywords (tags) on a message or between different messages in an imap account, the PERMANENTFLAGS response from the server will contain all 100 keywords strings listed each time it occurs (i.e., on imap SELECT). This occurs even if all tags are removed from all messages in the account.
Re: https://www.dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/BK2RXZFBPSNCJPZDXJ4BN3PDBIOCFAHG/

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: