After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 215672 - IMAP filters re-apply on message move
IMAP filters re-apply on message move
Status: RESOLVED INCOMPLETE
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other other
: Normal normal
: Future
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[filters]
: 350326 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-11-19 19:31 UTC by Steve Fox
Modified: 2009-12-11 04:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Steve Fox 2001-11-19 19:31:10 UTC
Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:

When I move a mail from a filtered folder back to my Inbox, the filter
re-applies itself and moves it back to the folder it was originally in.

Steps to reproduce the problem:
1. Setup up a folder and filter messages from a mailing list into that folder.
2. When mail comes in it will move to the appropriate folder.
3. Try to move a message from the folder to the inbox.
4. Watch it move back into the folder it was moved from.

Actual Results:
 
The message ends up back where it started

Expected Results:

Since filters are only supposed to be applied on incoming mail or when
filters are manually applied, I expected the mail to be left in my inbox.

How often does this happen? 

Every time.

Additional Information:
Comment 1 Jeffrey Stedfast 2001-11-19 19:34:45 UTC
I assume this is because your IMAP server is marking the moved message
as \Recent... and all \Recent messages get filtered by Evo on IMAP.

I don't think the server should be marking the message as \Recent, so
I *think* it's a server bug but I'm not 100% sure. I'd have to reread
parts of the IMAP spec and also see how we decide to filter messages
in evo's imap code...
Comment 2 Dan Winship 2001-11-19 19:41:16 UTC
Um... no, the server is correct to call it \Recent. Blah.
Comment 3 Jeffrey Stedfast 2001-11-19 19:54:44 UTC
okay, so the only way I can think of to fix this is to add some
X-Evolution-* header that says that the message has already been
filtered so we don't filter it again. But, if we do that, then we slow
the process down a HUGE deal because that means we'll have to modify
the message and upload it to the IMAP server again instead of using
the handy COPY command on the IMAP server.

Joy.

why do you want to move the message back to the Inbox for anyway?
*sigh*
Comment 4 Dan Winship 2001-11-19 19:57:58 UTC
If the server supports UIDPLUS, it's easy to recognize the
message. If not, we can remember the md5sum of the headers
or something like that.
Comment 5 Not Zed 2002-04-29 09:28:22 UTC
hmm, i thought filtering was only supposed to apply to inbox.  Perhaps
i rooted it up, thats what it was supposed to do.
Comment 6 Not Zed 2002-06-06 09:28:01 UTC
ok so i misread this the first time around.

You're wrong.  Filters do not apply to incoming mail, not for imap.
Imap  has no notion of 'incoming mail' that it tells the client -
apart from setting the 'recent' flag, which is what we use.

Using uidplus doesn't help the servers that dont support it (which is
a lot), so its not a suitably general solution.

More servers support arbitrary flags: we could use an arbitrary 'user
flag' in the append to flag it.  Or even if they didn't, then use the
'flagged' bit, its very unlikely a truly recent message would have the
flag bit set, and we could flip the bits off when we receive any
"recent & flagged" messages.

Comment 7 Jeffrey Stedfast 2002-06-06 17:29:30 UTC
hmmm, I don't like the idea of using the flagged bit, it's possible
for me to copy a flagged message over to my IMAP INBOX. I probably
wouldn't want it to be unfalled.

if we can do the user-flag bit, then we should do that otherwwise just
forget it I guess.
Comment 8 Akhil Laddha 2009-10-28 04:59:51 UTC
This bug has been fixed in 2.28.0 afair

This version is no longer maintained, which means that it will not receive any
further security or bug fix updates.
The current stable GNOME and Evolution version is 2.28.

Can you please check again whether this issue still happens in Evolution 2.26
or 2.28 and update this report by adding a comment and changing the "Version"
field? Thanks a lot.

Again thank you for reporting this bug and we are sorry it could not be fixed
for the version you originally used here.

Without feedback this report will be closed as INCOMPLETE in 6 weeks.
Comment 9 Akhil Laddha 2009-10-28 05:10:45 UTC
*** Bug 350326 has been marked as a duplicate of this bug. ***
Comment 10 Akhil Laddha 2009-12-11 04:26:03 UTC

Closing this bug report as no further information has been provided. Please 
feel free to reopen the bug if the problem still occurs with a newer
version of GNOME 2.28.0 or later, thanks.