[RFE] Junk Status flag needs more states

NEW
Unassigned

Status

SeaMonkey
MailNews: Message Display
--
enhancement
15 years ago
4 years ago

People

(Reporter: JoSH Lehan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529

The Junk Status flag currently has only two states: Junk and Not Junk.  This
creates these problems:

* Unsorted mail always appears as Not Junk.  This can be confusing when
attempting to initially train the filter.  The user often wonders why their
marks don't take effect, because there is nothing in the UI to show that a
message has been marked Not Junk (it looks exactly the same as an unsorted message).
* If the sorting of mail is aborted, all remaining mail always appears as Not
Junk.  This might be one of the causes of mail wrongly being flagged as Not Junk
when the user has a bad connection.
* User-sorted mail is not distinguishable from Mozilla-sorted mail.  This can
also be confusing when attempting to initially train the filter.

I recommend 5 states for the Junk Status flag:

* Unsorted - this mail has never been classified as junk or nonjunk, either by
Mozilla or by the user - all new incoming mail would automatically get this
state before junk filtering occurs
* Auto Junk - Mozilla's Bayesian filtering has assumed this mail to be junk, and
the user has done nothing to change this
* Auto Not Junk - same, but for nonjunk mail
* Manual Junk - the user has manually designated this mail to be junk,
overriding whatever sorting the mail might have had earlier
* Manual Not Junk - same, but for nonjunk mail

This would be great to have, dramatically improving the usefulness of the Junk
Status column.  It would also open the door to providing better hints to the
Bayesian filter, perhaps by giving higher weight to mails that have been
manually designated as junk or nonjunk by the user.


Reproducible: Always

Steps to Reproduce:
1. Start downloading new mail.
2. Notice that each message is shown as Not Junk, even though it has not been
sorted yet, or even downloaded yet.
3. If I stop the download/filter, I have no way of distinguishing between
unfiltered mail and mail that has been determined not to be junk.
4. If I manually mark messages as not junk, I have no way of knowing if my mark
has taken effect, because all messages already appear as "not junk" by default.


Actual Results:  
See above.

Expected Results:  
See above.

Comment 1

15 years ago
Information about the "unknown" state is purposefully hidden from users as per
bug 182386 (a bad decision IMO, but still).
This might be a dupe of bug 192153. However, as what you're requesting is
broader, I'm confirming this as a valid RFE for now. I personally think having
five states would be more confusing than the appearance of only two states, with
going back to three being the optimal solution, but whatever. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
(Reporter)

Comment 2

14 years ago
As others have pointed out, it would be an advantage to have an "Unsure" state.
 This is proposed in the later comments of bug 181534.

With this, there would be SIX states of the Junk flag:

* unsorted
* manually flagged by the user as junk
* manually flagged by the user as nonjunk
* automatically determined to be junk
* automatically determined to be nonjunk
* automatically determined to be "unsure"

Note that the user can never manually set "Unsure".  If a user is going to go
out of their way to manually mark a message as junk or nonjunk, they would then
by definition not be unsure about it.
Product: Browser → Seamonkey

Updated

13 years ago
Assignee: sspitzer → mail

Comment 3

12 years ago
(In reply to comment #2)
For IMAP there is a proposal as to how server side keywords could be named:

> * unsorted
=> 

> * manually flagged by the user as junk
=> $Junk

> * manually flagged by the user as nonjunk
=> $NotJunk

> * automatically determined to be junk
=> $AutoJunk

> * automatically determined to be nonjunk
=> $AutoNotJunk

> * automatically determined to be "unsure"
=> $AutoMaybeJunk


See <http://www.ietf.org/internet-drafts/draft-melnikov-imap-keywords-03.txt> or Bug 277926.

Updated

10 years ago
Duplicate of this bug: 277926

Comment 5

10 years ago
consider using draft-melnikov-imap-keywords as start point, this draft
currently expired but it well written and fits our case to solve problem.

Updated

10 years ago
Assignee: mail → kent

Comment 6

9 years ago
I'd like to either move this forward, or close it as WONTFIX. Let me summarize the current issues.

Junk status is tri-state, and only needs a CSS change to show three states. We could re-enable that, and distinguish between not-junk and unknown fairly easily.

Junk status is currently an interaction between three variables: "junkscore" which is really the tri status (can be null, 0, or 100), "junkscoreorigin" which shows what set the junkscore (filter, plugin, whitelist, user, or imapflag are allowed values), and "junkpercent" which ranges from 0-100. It is possible now for an extension to combine these values in various ways to create a custom, sortable column with a complex junkstatus.

I don't think there is support among the TB drivers to include complex junk status in the standard displays though. That would be left to an extension. But it might be possible to add the tri-state display that was removed in bug 182386.

So I propose that this bug be morphed to restore the existing tri-state display of status. Anything else I think will probably be a WONTFIX for the standard product.

Comment 7

9 years ago
I prepared a patch for Thunderbird to implement this, but then noticed that this bug is marked as Seamonkey. The TB patch is now at bug 289011.
Assignee: kent → nobody
QA Contact: esther → message-display

Comment 8

4 years ago
$Junk and $NotJunk are listed in the IMAP keyword registry at <https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml>.
You need to log in before you can comment on or make changes to this bug.