Bug 1278313
Summary: | Junk flag not remembered on a Zimbra server | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> |
Component: | evolution | Assignee: | Milan Crha <mcrha> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | kengert, lucilanga, mbarnes, mcrha, tpopela |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-12 16:56:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tim Waugh
2015-11-05 09:00:53 UTC
Thanks for a bug report. I tried to reproduce this, but no luck. I used a folder under On This Computer and also a Dovecot IMAP folder, with and without real junk folder set. The message stays as junk. What is the server you experience this with, please? If it's IMAP, do you have real junk folder set? I'm using an IMAP+ server, without a Real Folder for Junk (hadn't seen that option before now). Zimbra server doesn't play well with QResync. There was a default to enable it, but since it was realized that it doesn't work well the default was changed to not enable it. Existing accounts were not changed, of course. Running $ CAMEL_DEBUG=imapx:io evolution and checking what will change after you try to delete junk mails (what will be added to the console) may possibly show some issue with QResync. I would disable the QResync and try without it. Even the evolution is able to use that new option on-the-fly, it would be safer to close & run the evolution after the change of the option, just in case. After waiting until idle and then marking two messages as junk, I saw this: [imapx:D] I/O: 'DONE' [imapx:D] I/O: 'D00334 OK IDLE completed' [imapx:D] I/O: 'D00338 UID STORE 2159858:2159859 +FLAGS.SILENT (\SEEN)' [imapx:D] I/O: '* 214 FETCH (UID 2159858 MODSEQ (5236353)) * 215 FETCH (UID 2159859 MODSEQ (5236353)) D00338 OK UID STORE completed' [imapx:D] I/O: 'D00339 UID STORE 2159858:2159859 +FLAGS.SILENT (JUNK)' [imapx:D] I/O: 'D00339 OK UID STORE completed' [imapx:D] I/O: 'D00340 IDLE' [imapx:D] I/O: '+ idling' [imapx:D] I/O: 'DONE' [imapx:D] I/O: 'D00340 OK IDLE completed' Then I closed evolution and restarted it, and both messages re-appeared. Thanks for the tip. I've disabled QResync and closed evolution, and will watch to see if things improve. (In reply to Tim Waugh from comment #5) > After waiting until idle and then marking two messages as junk, I saw this: The log shows exactly that, two messages were marked as read and as junk, the server reported success for both changes. The the IDLE waiting continued. The thing that this is on Zimbra server is important. I noticed that the Zimbra server (I do not know since which version) treats the Junk flag specifically. I mean, when you mark message as junk, the server does some processing with the message on its own when it's stored. I reproduced this here too, I looked into the log and I see that the junk flags are stored (just like in your log snippet above), but the next time the folder is opened the Zimbra server ignores it and returns flags without that Junk flag. Looking even more closely into the log the Zimbra server advertises on folder open that it can store any custom user flags, with a notice at the end that it doesn't store the Junk flags permanently. > * OK [PERMANENTFLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded > $MDNSent Forwarded $has_cal $Labeltodo \*)] junk-related flags are not > permanent So this is not evolution's issue, but Zimbra's. I'm pretty sure it used to store the Junk flags permanently, but I do not know what convinced it to ignore (or unset) it. That'll be a good question for the server admins. An alternative solution would be to setup a real Junk folder (Defaults tab of the IMAPx account properties) to "Junk E-mail" on the server, thus whenever you'll set any messages as junk they will be moved to that folder. There was a bug in the code which moves the messages unfortunately [1], thus I cannot recommend it right now. The fix from [1] will be available in 3.18.3. If you want, I can build a test build for you with that change included. [1] https://bugzilla.gnome.org/show_bug.cgi?id=757789 I experience the bug, too. (In reply to Milan Crha from comment #6) > So this is not evolution's issue, but Zimbra's. I'm pretty sure it used to > store the Junk flags permanently, but I do not know what convinced it to > ignore (or unset) it. That'll be a good question for the server admins. Did someone contact the server admins to ask them this question? > An alternative solution would be to setup a real Junk folder (Defaults tab > of the IMAPx account properties) to "Junk E-mail" on the server, thus > whenever you'll set any messages as junk they will be moved to that folder. > There was a bug in the code which moves the messages unfortunately [1], thus > I cannot recommend it right now. The fix from [1] will be available in > 3.18.3. If you want, I can build a test build for you with that change > included. > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=757789 So, is there any workaround for us at this time? (In reply to Kai Engert (:kaie) from comment #7) > Did someone contact the server admins to ask them this question? I didn't. > > An alternative solution would be to setup a real Junk folder (Defaults tab > > of the IMAPx account properties) to "Junk E-mail" on the server, thus > > whenever you'll set any messages as junk they will be moved to that folder. > > There was a bug in the code which moves the messages unfortunately [1], thus > > I cannot recommend it right now. The fix from [1] will be available in > > 3.18.3. If you want, I can build a test build for you with that change > > included. > > > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=757789 > > So, is there any workaround for us at this time? Right, I dind't tell it here, but I made an update, evolution-data-server-3.18.2-2, which fixed the message copy/move issue in the IMAPx accounts, thus with that installed the workaround is to use real Junk folder. |