Closed Bug 250470 Opened 20 years ago Closed 9 years ago

Junk processing marking all messages as Junk if training.dat doesn't exist

Categories

(MailNews Core :: Filters, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: dhaisell2279, Unassigned)

References

Details

(Whiteboard: [dupetome])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520

Whenever I have the Junk controls enabled in ver. 1.8a1, all the messages in my
POP account are marked as Junk, unless I disable the Junk controls. All incoming
messages are moved to the Junk folder, regardless of whether they are actually Junk.

Reproducible: Always
Steps to Reproduce:
1.Open Mail & Newsgroups
2.Automatically receive all new messages
3.All messages are marked as Junk and moved to said folder

Actual Results:  
All messages sent to Junk folder

Expected Results:  
Allowed messages that are not Junk to remain in the Inbox, and messages that are
Junk moved to the Junk folder.
Product: MailNews → Core
*** Bug 251705 has been marked as a duplicate of this bug. ***
I am seeing this on all platforms on the 1.7.7 branch builds from 0406

-launch with fresh profile
-create a pop account
-Get messages

tested results: All messages are flagged as junk(sometimes one or two don't get
marked junk)  I didn't set junk messages to be moved anywhere, so they remained
in the inbox.

expected results:
nothing marked as junk. I think that's the way it should be, since we have to
teach the filter what is and isn't junk. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Flags: blocking1.7.7?
Flags: blocking1.7.7?
*** Bug 306123 has been marked as a duplicate of this bug. ***
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
anyone still see this?
this is WFM with fresh profile.
reporter's address is dead.
Whiteboard: CLOSEME 2008-02-20
Bug 251705 comment #1 gets to the heart of this, namely by design when no messages have been trained, all messages are marked as junk. The comments at http://mxr.mozilla.org/seamonkey/source/mailnews/extensions/bayesian-spam-filter/src/nsBayesianFilter.cpp#1113 say:

// if there are no good tokens, assume the message is junk
// this will "encourage" the user to train

Bug 179999 is one way to resolve this. I suggest we WONTFIX this bug, as it represents a reasonable design decision, and leave bug 179999 to carry any further interest in pretrained junk processing.


hrm, I can't believe I wrote that (comment 6). What was I thinking?

> I suggest we WONTFIX this bug, as it represents a reasonable design decision

reasonable design perhaps but is it sufficient?  From bug land we know there aren't many dupes to this bug.  But perhaps we can't say the process is idiot proof without having some new users test and see what they say.  Perhaps, for example, on startup should there be a notice saying "so far you've marked x bugs junk and y bugs not junk - which is not enough for junk filtering to accurately ____. Please ..."
Summary: Junk filter marking all messages as Junk → Junk filter marking all messages as Junk if training.dat doesn't exist
Whiteboard: CLOSEME 2008-02-20
The process is clearly NOT idiot proof. There needs to be a review of the UI for junk processing to understand what is confusing, and see if improvements are possible. So the design decision complained about in this bug, that is "mark as junk to force user to train" is part of that confusing UI. 

But at the same time, I don't see what steps could be taken to fix this current bug. Is the proposed fix to remove the behavior to mark messages as junk when no training has occurred? But that also has downsides. I'm not enough of a bugzilla guru to understand how to show these subtleties. Maybe make a macro bug for junk UI problems, and relate it to this bug?
discussion in m.d.a.thunderbird would probably be helpful, to identify which of several ideas (yet to be determined) are the best way to improve - rather than get bogged down in a bug with a pre-determined idea
QA Contact: filters
Product: Core → MailNews Core
WONTFIX per comment 7 suggestion
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
See Also: → 179999
Summary: Junk filter marking all messages as Junk if training.dat doesn't exist → Junk processing marking all messages as Junk if training.dat doesn't exist
Whiteboard: [dupetome]
You need to log in before you can comment on or make changes to this bug.