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 272027 - Don't mark Junk automatically as read
Don't mark Junk automatically as read
Status: RESOLVED DUPLICATE of bug 579550
Product: evolution
Classification: Applications
Component: Mailer
2.10.x (obsolete)
Other All
: Normal major
: ---
Assigned To: Johnny Jacob
Evolution QA team
: 305568 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-31 22:20 UTC by Uri David Akavia
Modified: 2013-09-10 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Preliminary patch! (1.23 KB, patch)
2007-08-27 10:55 UTC, Johnny Jacob
needs-work Details | Review
patch adapted to evolution-2.22.3.1 as shipped by ubuntu hardy (1.38 KB, patch)
2008-08-09 04:10 UTC, cwehrmann
needs-work Details | Review

Description Uri David Akavia 2005-01-31 22:20:00 UTC
Description of Problem:
Messages that are moved to Junk (by the spamassasin filters) are
automatically marked as read.
This doesn't tell you that you've got new messages, so you don't check the
Junk folder, and you can't remember to train the filters.
I've had non-Junk messages end up there, but I only saw them when I clicked
on the Junk folder.
Comment 1 André Klapper 2005-03-09 16:52:17 UTC
workaround could be:
add as the last incoming filter:
If [Status][is][Junk] Then [Move to folder][INBOX/spam],[Stop Processing]
so it does not get marked as read.
it was posted by Eric Lambart on bug 260830.
Comment 2 Karsten Bräckelmann 2005-06-04 16:47:10 UTC
Raised the Severity and set a Target Milestone for 2.3. Accepted this bug as well.

This is a serious usability issue IMHO that should be resolved ASAP. It even
came up on the mailing lists, so it really strikes the users.

Wondering about the RFE keyword, as I consider this a bug, rather than an
enhancement. Current behavior is broken.
Comment 3 Luis Villa 2005-07-25 13:29:08 UTC
*** Bug 305568 has been marked as a duplicate of this bug. ***
Comment 4 André Klapper 2006-01-09 01:42:39 UTC
still in 2.5.4, retargetting
Comment 5 André Klapper 2006-06-03 08:40:51 UTC
this isn't an enhancement, this is a bug, because i miss mail.
Comment 6 André Klapper 2006-08-06 13:36:29 UTC
varadhan, jony? any comments? i miss email because of this bug, i expect new emails in a folder to bold this folder.
Comment 7 Sebastien Bacher 2006-12-14 10:07:46 UTC
Ubuntu bug about that: https://launchpad.net/products/evolution/+bug/49703
Comment 8 Daniel Holbach 2007-02-09 15:22:10 UTC
Bumping version, still happens with 2.9.6.
Comment 9 Johnny Jacob 2007-08-27 10:55:21 UTC
Created attachment 94420 [details] [review]
Preliminary patch!

Needs some more testing !
Comment 10 Srinivasa Ragavan 2007-08-29 04:25:51 UTC
Johnny I dont think you should reset the seen flag when it is done by pressing JUNK. It means that the user has seen it. It should be unread only if it is done through automatic junk filtering
Comment 11 Matthew Barnes 2008-03-11 00:32:03 UTC
Bumping version to a stable release.
Comment 12 C de-Avillez 2008-08-07 20:00:20 UTC
just a ping -- per srag's comment, all we would need to do is take out the proposed changes to em-folder-view.c.

If indeed this is correct, can we get this done?
Comment 13 cwehrmann 2008-08-09 04:10:50 UTC
Created attachment 116208 [details] [review]
patch adapted to evolution-2.22.3.1 as shipped by ubuntu hardy

adapted above patch to keep CAMEL_MESSAGE_NOTJUNK which seems to have been added recently
Comment 14 cwehrmann 2008-08-09 04:17:49 UTC
I disagree with Srinivasa Ragavan and don't think it's necessary to mark mail as read which has been explicitly marked junk via the button.  This may be an attractive feature for some, but I would want to turn it off.  Mail should only be marked read if I've seen it or explicitly marked it as such.  This patch has been around for a year and is required to enable junk filtering for high volume mail accounts
Comment 15 Srinivasa Ragavan 2008-08-11 04:51:56 UTC
cwehrmann, Its the same behavior when you delete a unread mail. Its set as deleted and seen. This way, the Junk folder shows some unread mails, that are automatically junked by the filter. So the user can validate at times.

Also, you shouldn't set NOTJUNK. That has to be set only on mails that the user sets as NotJunk.
Comment 16 C de-Avillez 2008-08-11 20:23:06 UTC
srag, I am unsure on your comment "you shouldn't set NOTJUNK". This was already in the code, and was not changed by the patch. Are you saying this was wrong in the code?

Also -- although I am not yet taking a side on this...

1. if we mark a message as junk, then it is also marked as read.

2. if we mark a message as not junk, then -- currenlty -- its read status is not changed. 

This sounds a bit inconsistent: if an user's action is to force CAMEL_MESSAGE_SEEN, then it should do so at all points.

Now taking a side:

Personally, I am unsure if this is indeed inconsistent or not, but I think it is not quite right.

Here's the reasoning: if I -- the user -- mark a junked message as not junk, this is because I am checking the junk folder for false-positives. I am not really *reading* the email, I just decided it is *not* junk, and should be marked so. I will probably -- later on -- go back to my Inbox and really, really, read the email... so I would like it to be marked NOT seen.

On the other hand, if I explicitly mark a message as junk, then I see no reason for it to be marked unread -- I am done with it.

So. Although I agree with you on " marking as junk also marks as read", I think we should force unread if a message is marked NOTJUNK.

Does this warrant a new bug?
Comment 17 Srinivasa Ragavan 2008-08-12 07:34:34 UTC
(In reply to comment #16)
> srag, I am unsure on your comment "you shouldn't set NOTJUNK". This was already
> in the code, and was not changed by the patch. Are you saying this was wrong in
> the code?

Ignore it, I was sleepy probably.

> 
> Also -- although I am not yet taking a side on this...
> 
> 1. if we mark a message as junk, then it is also marked as read.
> 
> 2. if we mark a message as not junk, then -- currenlty -- its read status is
> not changed. 
> 
> This sounds a bit inconsistent: if an user's action is to force
> CAMEL_MESSAGE_SEEN, then it should do so at all points.
> 
> Now taking a side:
> 
> Personally, I am unsure if this is indeed inconsistent or not, but I think it
> is not quite right.
> 
> Here's the reasoning: if I -- the user -- mark a junked message as not junk,
> this is because I am checking the junk folder for false-positives. I am not
> really *reading* the email, I just decided it is *not* junk, and should be
> marked so. I will probably -- later on -- go back to my Inbox and really,
> really, read the email... so I would like it to be marked NOT seen.
> 
> On the other hand, if I explicitly mark a message as junk, then I see no reason
> for it to be marked unread -- I am done with it.
> 
> So. Although I agree with you on " marking as junk also marks as read", I think
> we should force unread if a message is marked NOTJUNK.

When a mail comes, it is unread. When spam filter moves it to junk folder it will be unread. All such mails the user focus on the junk folder will be such mails. No need to explicitly set as unread. In a normal lifecycle, it doesnt affect anything or cause anything.
> 
> Does this warrant a new bug?
> 

Comment 18 Mario Manno 2008-08-23 18:26:19 UTC
RFC 2060 describes the seen flag as an indicator for: "Message has been read".
If I open with an email I expect the read flag to be set, thus I expect mails which I didn't interact with to have the flag set to unread.

Evolutions junk mail filter breaks these exceptions: mail which is automatically handled has its read status altered. This is especially bad since:
* bayes junk filters rely on user interaction to learn about false positives.
* junk mail is hidden in original folder
* no notification about new junk in the gui

Not toggling the read flag for automatically detected junk would fix this issue.

If I manually mark email as junk, I'd say this clearly is an interaction and justifies marking as read, but IMHO this is a different issue and works as expected.

The patch works fine.
Comment 19 Florian Ludwig 2009-06-10 16:47:04 UTC
I think this changed in the newest version of evolution and this bug can be closed now. (At least it works for me, Evolution 2.26.2, Debian)
Comment 20 C de-Avillez 2009-08-17 15:21:33 UTC
Johnny, Milan fixed this on bug 579550. As such, I will go ahead and mark this one as a duplicate, if you do not mind.

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