1220304 – Moving to the real Junk folder doesn't move anything

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1220304 - Moving to the real Junk folder doesn't move anything

Summary: Moving to the real Junk folder doesn't move anything

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	evolution-data-server
Sub Component:
Version:	7.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Matthew Barnes
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2015-05-11 09:30 UTC by Matěj Cepl
Modified:	2015-11-19 07:58 UTC (History)
CC List:	4 users (show)
Fixed In Version:	evolution-data-server-3.12.11-14.el7.x86_64
Doc Type:	Bug Fix
Doc Text:	I would not mention this bug report in the Doc Text, there was not added any specific change for it (neither the mentioned upstream changes), it was fixed by the rebase and/or any consequent changes.
Clone Of:
Environment:
Last Closed:	2015-11-19 07:58:18 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2015:2226	0	normal	SHIPPED_LIVE	evolution bug fix and enhancement update	2015-11-19 08:37:43 UTC

Description Matěj Cepl 2015-05-11 09:30:20 UTC

Description of problem:
For better compatibility with other MUAs I would prefer that Junk (and Trash) was actually moving the messages to the appropriate folders instead of just marking them as spam (or deleted).

Version-Release number of selected component (if applicable):
evolution-3.12.8-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Make sure "Use Real folder" is checked for both Trash and Junk
2. Mark a message as junk
3. Switch to another folder to make sure all changed information is stored in the IMAP server.
4. Quit Evolution
5. Open another MUA on the same IMAP server (Thunderbird, mutt, or a web client)

Actual results:
Messages are still in INBOX, but marked as spam.

Expected results:
Messages are moved to the folder identified as a spam folder.


Additional info:

Comment 2 Milan Crha 2015-05-11 10:07:20 UTC

Thanks for a bug report. Please retest with evolution(-data-server) 3.12.11, once it is available.

Comment 3 Matěj Cepl 2015-05-11 10:29:40 UTC

Works for me in evolution-3.12.11-1.el7.x86_64 (which will hopefully get into 7.2).

Comment 4 Milan Crha 2015-05-11 15:26:22 UTC

Sure, it will get it into RHEL 7.2.

*** This bug has been marked as a duplicate of bug 1174414 ***

Comment 5 Matěj Cepl 2015-05-13 22:03:42 UTC

Actually, no it doesn’t. Apparently it doesn’t happen 100% but I have still the same problem at least on one account. On the work account (Zimbra, IMAP+) it perhaps seems to work (not 100% certain about it either), but it happens a way too frequently with my personal account (dovecot, IMAP+ as well).

Comment 6 Milan Crha 2015-05-22 08:49:06 UTC

I do not know how to reproduce this. I setup an IMAPx account pointing to a Dovecot server with Receiving options: Check for new messages every 60 minutes and Number of concurrent connections to use 3, all the other Receiving Options are uncheced. In Defaults I set real Trash and Junk folders. Saved settings, closed evolution , run evolution (just in case).

Then in Inbox I marked few consecutive messages as Junk with the toolbar "Mark as Junk" button, then moved to another folder on the same account, but not into the Junk folder. After all the saving finished in the status bar I selected the Junk folder, which shows the Junk messages as expected.

I suggest to run evolution from a terminal and watch its output. Ideally, for testing purposes, disable all but the Dovecot IMAPx account, then run evolution with IMAPx debugging like this:
   $ CAMEL_DEBUG=imapx:io evolution &>log.txt
then try to reproduce the issue. It can be that the operation of moving the messages failed for some reason, which might be shown in the log.

Please use the most recent evolution-data-server, like the current evolution-data-server-3.12.11-8. Thanks in advance.

Comment 7 Matěj Cepl 2015-05-22 11:06:30 UTC

(In reply to Milan Crha from comment #6)
> Then in Inbox I marked few consecutive messages as Junk with the toolbar
> "Mark as Junk" button, then moved to another folder on the same account, but
> not into the Junk folder. After all the saving finished in the status bar I
> selected the Junk folder, which shows the Junk messages as expected.

Yes, but Evolution lies. Did you check in another IMAP client (mutt, Thunderbird, webmail) that the messages are truly moved?

Comment 8 Milan Crha 2015-05-27 10:57:48 UTC

(In reply to Matěj Cepl from comment #7)
> Yes, but Evolution lies. Did you check in another IMAP client (mutt,
> Thunderbird, webmail) that the messages are truly moved?

As you said above, Zimbra works fine here.

I made some changes upstream recently [1][2], which are touching related part of the code. It was not only about message move as such, but maybe related for you too.

I backported the upstream changes and created a test build for you [3]. Please, install it, then disable all but the one account where you were able to reproduce the issue (thus the log will not contain any unrelated information), then start evolution as follows:
   $ CAMEL_DEBUG=imapx:io evolution &>log.txt
then try to reproduce the issue, while the log.txt file will contain what was communicated between the evolution and the IMAP server. Note that the log contains a raw communication between the server and the client, which means the content of the messages, names of folders and so on. If you consider anything of it private, then feel free to send the log only to me, just name this bug report in the subject, thus I'd not overlook it in my spam folder. Of course, if the test package will work properly for you, then there is no need to send the log.

Thanks in advance.

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=8811085cf413
[2] https://git.gnome.org/browse/evolution-data-server/commit/?id=8ba72793929d
[3] https://brewweb.devel.redhat.com/taskinfo?taskID=9266083
    as evolution-data-server-3.12.11-11.1

Comment 9 Matěj Cepl 2015-06-09 08:53:45 UTC

Yes, it seems to be fixed with

evolution-perl-3.12.11-6.el7.x86_64
evolution-help-3.12.11-6.el7.noarch
evolution-data-server-3.12.11-14.el7.x86_64
evolution-3.12.11-6.el7.x86_64
evolution-debuginfo-3.12.11-6.el7.x86_64
evolution-data-server-debuginfo-3.12.11-14.el7.x86_64

Comment 10 Milan Crha 2015-06-16 20:01:50 UTC

Thanks for the confirmation. I'll add the bug to the errata.

Comment 14 errata-xmlrpc 2015-11-19 07:58:18 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2226.html

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