189289 - No new mail notification (biff) when junk mail (spam) arrives

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Kai Stukenbrock]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030112
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030112

When junk mail filtering _and_ moving to junk mail folder is enabled, the new
mail notification should only be displayed if at least one mail arrives that is
not considered spam. Otherwise I think it is pointless to notify the user of new
mail, while the use of junk mail controls and the move option indicates that the
user does not want junk mail. So why notify the user of something unwanted,
instead of silently filtering it away?

Reproducible: Always

Steps to Reproduce:

Comment 1

[Ian Nartowicz]

Yes, this confused me somewhat.  I got my new email ding-dong, but couldn't find
the email :)  Once I did find it, I realised that I didn't want to find it!  You
might consider this to be a duplicate of bug 120599.

Comment 2

[esther]

changing qa.

Comment 3

[(not reading, please use [e-mail] instead)]

with pop, for example, you can know you have new mail before you've downloaded it.

and you can't tell it's junk until after you've downloaded it and analyzed it.

so this might not even be possible to fix, as esther points out.

let me think on this, but I think this will be either wontfix or invalid.

Comment 4

[Vidar Haarr (not reading bugmail)]

*** Bug 189791 has been marked as a duplicate of this bug. ***

Comment 5

[Ian Nartowicz]

I see your point Seth, that email may be notified before it is downloaded, since
that is a possible setting for POP servers.  However, in the perhaps more common
circumstance where email is detected and downloaded at the same time, I feel
that every attempt should be made not to notify the user about spam which gets
filtered away.  I think this has the potential to become one of the most
reported bugs when spam filtering gets officially released. 

Comment 6

[Sander]

Isn't this a dupe of bug 91498? (I assume the distinction between trash and spam
is artifical.)

Comment 7

[Quinn Yost (mythdraug)]

Yes, I think this could be considered a dupe of bug 91498 comment 5.  However,
that seems to make it just a subset (dupe) of bug 11040.

Seth: care to make a ruling?

Comment 8

[Ian Nartowicz]

Oops, I tried to say that, but I collided :)  Here's my comment:

The issues are certainly the same.  It is perhaps more closely a duplicate of
bug 11040, calling for email notification to be more generally configurable
based on filters and folders.  Certainly, there will be a case made for no
notification for spam which is detected but not moved to a special folder.

Comment 9

[Quinn Yost (mythdraug)]

And since Seth opened bug 11040 saying, "I was thinking of doing 
this - it's just a matter of adding a filter action, and doing a 
folder notification. But if someone beats me to it, that's fine 
too" in 1999.

Perhaps it is time...   ;)

Comment 10

[Stefan Borggraefe]

Adding "biff" to Summary so this bug can be found easier. Also Changing
Hardware/OS to All/All because there is some kind of notification on every platform.

Comment 11

[Simon Spiegel]

Just wanted to add that I consider this enhancement very useful. Espcially on
slower machines changing to MailNews takes some time. Right now I always change
to Mail when I get see that new mail has arrive, happily anticipating a nice
mail from a friend. All I get in about half of the cases is junk. As long as no
non-junk mail gets downloaded no notification (or a different one: "You've got
junk") should show uo.

Comment 12

[Jon Granrose]

add my vote.  I get more spam at home than I do at work and there's few things
more annoying than seeing the biff notice and checking your email to find it's
just spam.  glad to see I'm not the first person who thought of this.

Comment 13

[Matthew Elvey]

OT/workaround:I just changed my bugzilla login/email, as you can see, to dodge
the spammers who were sending to [e-mail].   Hopefully
http://leginfo.ca.gov/pub/bill/sen/sb_0001-0050/sb_12_bill_20021202_introduced.html
passes. The author could do with a support letter on Netscape letterhead... 
She's looking for such letters of support. 

Comment 14

[David]

*** Bug 195884 has been marked as a duplicate of this bug. ***

Comment 15

[Matthias Versen [:Matti]]

*** Bug 197244 has been marked as a duplicate of this bug. ***

Comment 16

[scottputterman]

nominating.

If the whole purpose of the junk mail feature and this folder is to make it so
that I don't get bothered by Spam then this bug should get fixed.  Otherwise,
Spam is still causing me to spend time on it by having to figure out why I got
new mail. 

If this can't be fixed, I'd at least suggest making the Junk Mail icon more
noticeable when there's new mail in that folder so I can know that Junk Mail was
the cause of the notification.

Comment 17

[Alfonso Martinez]

*** Bug 197543 has been marked as a duplicate of this bug. ***

Comment 18

[Lasse Marøen]

*** Bug 197876 has been marked as a duplicate of this bug. ***

Comment 19

[(not reading, please use [e-mail] instead)]

good suggestion, maybe 1.4 beta.

need to look into the pop and imap code, see when we biff and when we're done
analyzing and moving.

I bet we currently biff way before we're done analyzing and moving, so that
would need to be delayed.

Comment 20

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 21

[Ryan Russell]

Me too.  I use Mozilla 1.3 Release on Windows XP with a POP3 server.  Frequently
when I get new mail, it's all junk, and the various "new messages" notifications
stay lit.  If I hit get new messages again (and no new messages arrive in the
meantime), they go away.  Otherwise, it sits there indicating that I've got new
messages, and I have no idea if I *really* have new messages.  I'd like it if
Mozilla would do another quick check to see if unread messages remain after the
junk filter does it's thing, and set the flag appropriately.  Also, if I got a
non-junk message, when I read the last new one, it also clears the flag
properly, if that helps.  So, if it re-checks after chaning the status everytime
you read a message, it seems reasonable to do it once after the junk scan.

Comment 22

[Stefan Vorkoetter]

*** Bug 202922 has been marked as a duplicate of this bug. ***

Comment 23

[Grey Hodge (jX)]

Isn't this a dupe of Bug 91498 / isn't Bug 91498 a dupe of this?

Comment 24

[Mike Cowperthwaite]

Kinda.  Bug 91498 is a special case of Bug 11040.  This bug is not, because the
junk filtering is separate from user-defined filtering.

Comment 25

[Torben]

*** Bug 203440 has been marked as a duplicate of this bug. ***

Comment 26

[emmet]

Attachment: first draft bug fix patch

Patch that suppresses (well removes) the biff icons when ONLY junk mail is
MOVED to the junk folder.

Does not suppress biff if other mail arrives (irrespective of other filters) or
if the junk mail is NOT MOVED.

Does NOT suppress the mail alerts 'beep' or sliding window (this requires quite
a major change to the mail / filter plugin architecture) -- Workround, switch
them off in the preferences dialog.

I am no master of cvs etc and my cygwin system will not let me use
'cvs -uw diff' but only 'cvs -w diff'. This may mean a little attention
is needed to apply it.

It would be good to get this into 1.4 -- is that possible?

Comment 27

[(not reading, please use [e-mail] instead)]

I don't think this is the right approach.

I think the right approach is to do a little double checking, when biff does
fire, that we really have new, non junk, messages.  (that should work for imap
and pop).

Comment 28

[emmet]

Request for comments.

The current problem with biff is that the message filter plug in system runs in
a different thread from the mail system and therefore there is no way at present
to tell the mail system when it is a good time to biff. The old filter system
just filters messages within the mail state machine.

When a message is classified as junk/not junk by the plugin it then calls
nsIJunkMailClassificationListener::onMessageClassified(...)
which is the hook that LocalMail and Imap picks up on (and which the previous
patch for LocalMail (hence POP) uses).

There is no way to tell when the mail plugin has finished processing the messages.

If we added a new function to nsIJunkMailClassificationListener
nsIJunkMailClassificationListener::onProcessedAllMessages(...)
that the various mail systems could hook up to then they could all do their biff
on receipt of that message (or at least know what is what).

Concerning Seth's specific comment, there is an issue (I think) with the mail
database in that you can not distinguish between new mail and unread mail (the
POP system uses a (function accessed) variable nsMsgFolder::mNumNewBiffMessages
-- what does Imap do?) so a method such as counting classfied junk
::onProcessedAllMessages may still have to be used.

Comment 29

[emmet]

Attachment: bug fix proper

This patch works as per previous comment.

Tested on POP and IMAP, works for me.

This is a complete solution, beep and alert boxes are suppressed when new mail
is just spam. Correct number of not-junk messages displayed in alert box.

Comment 30

[Jon Granrose]

we still have time to make the 1.4b train with this.

emmet - as a huge junk mail control fan, thanks for your work on this!

Comment 31

[emmet]

Attachment: bug fix proper mk 2

The previous patch would not biff if ALL messages were in the address book
(white list). Corrected by ensuring that SpamFilterClassifyMessages is called
even if the number of messages to classify is zero. SpamFilterClassifyMessages
checks this and calls the biff callback immediately if so, otherwise passes the
message list onto JunkMailPlugin.

I am now using the debug build with this patch on my mail mail account for
testing. Can I encourage a few of you to do this too.

Comment 32

[Patrick]

*** Bug 204057 has been marked as a duplicate of this bug. ***

Comment 33

[emmet]

Attachment: bug fix mk3

I have now been using this patch in both debug and optimised builds (installed
with cd mailnews; patch -p0 < PATCH) for two days and it works fine; checked
with fresh downloads of the source.

This new patch adds an extra function to nsIPop3Sink (.idl, .cpp)

void UpdateNumNewMessages(in long numNewMessages);

that is necessary since the previous function (still used in other places in
the code) updates Biff state and NewMessages together. Comments tidied up a
little too.

How do we go about getting it 'checked in'?

Comment 34

[Patrick]

*** Bug 204057 has been marked as a duplicate of this bug. ***

Comment 35

[Jon Granrose]

Comment on attachment 122200 [details] [diff] [review]
bug fix mk3

next step is to get Seth to review your change, then it needs to be
superreviewed and approved for 1.4b, then it can be checked in.

Comment 36

[Matthew Elvey]

http://www.mozilla.org/get-involved.html says 
...[Step 2. Y]ou need to find the module owner and get them to review the patch.
...  
This is Seth, who is a bunch of people if you click on his mailto: at 
Module: Mail/News on http://www.mozilla.org/owners.html, for which for some
reason Mozilla won't show me the source!  Looks like a flag somehow got set on
the Attachment that should get his attention (if your and this post don't.)

Comment 37

[Matthias Versen [:Matti]]

*** Bug 205186 has been marked as a duplicate of this bug. ***

Comment 38

[emmet]

This patch still works fine after applying all mail patchs landed so far,
including the junk mail/message filter patches 194273 and 180153.

Comment 39

[timeless]

Comment on attachment 122200 [details] [diff] [review]
bug fix mk3

Some observations:
1. i know -w is nice for reviewers, but since you probably don't have cvs
access a non -w will be needed eventually.
2. don't comment things out, cvs will maintain a history of what used to be
there
+	 // commenting out the next line -- we do this in
onProcessedAllMessages
+	 // SetBiffState(nsIMsgFolder::nsMsgBiffState_NewMail);
3. else is your friend,
+   if (numBiffMsgs > 0)
+   {
+	 server->SetPerformingBiff(true);
+	 InBoxFolder->SetBiffState(nsIMsgFolder::nsMsgBiffState_NewMail);
+	 server->SetPerformingBiff(false);
+   }
+   if (numBiffMsgs <= 0)
this line ^^ could be 'else', right?
4. i know whitespace is silly, but could you try to use it consistently:
+   }
+  return NS_OK;
 }
(return should line up with the } on the line preceding it)
5. don't use tabs (i'm not certain you're using them, but it looks like you
are)
+  if (numBiffMsgs > 0)
+  {
+	 server->SetPerformingBiff(true);

Comment 40

[David :Bienvenu]

if junk mail filtering is turned off, does biff still work, especially for imap?
It's hard to tell from the limited context in the diff.

Comment 41

[emmet]

Attachment: patch mk4

Thanks for the comments Timeless. Bienview you were right.

The old patch did not biff when junk mail control was switched off. Newly
patched patch takes the biff one level further up the abstraction hierarchy so
almost no code is needed in the localmail, Imap specific files (just a call to
the new nsMsgDBFolder::PerformBiffCheck function from the callback
OnProcessedAllMessages). If there are no messages to filter, no filter, no
filtering or only whitelist then PerformBiffCheck is (now) called immediately
from nsMsgDBFolder::CallFilterPlugins otherwise the callback is used. Tested
with POP and IMAP.

Comment 42

[(not reading, please use [e-mail] instead)]

Comment on attachment 122200 [details] [diff] [review]
bug fix mk3

clearing, since obsolete

Comment 43

[(not reading, please use [e-mail] instead)]

sorry, but I don't think this is going to happen for 1.4

clearing target milestone.

this will have to wait for 1.5

Comment 44

[Grey Hodge (jX)]

Req'ing for 1.4, since we have a patch that works in all circumstances, has gone
through a cpuple revisions for increased quality, and 1.4 is the last Suite
milestone, so we may as well make it great. biff is almost useless currently for
anyone with a medium amount of spam. A feature that doens't work is no better
than not having said feature.

Comment 45

[Todd]

Hi All,

   Add me to the list.  Re: comment 3:  My notifier does not trigger 
(chime) until after both 1) all my eMail has completely downloaded and 
2) my junk filter has run (the hard drive rattles pretty loud when junk 
is running) and transfered my spam to junk.  So, since notification is 
"after the fact", it is possible.  Now if you are talking about the look 
ahead feature that puts the green down arrow on my lower left corner's 
inbox icon, then I don't care.  I just do not want my chime and task bar 
icon to go off on spam. 

--Tony

Comment 46

[http://tinymailto.com/oliversl]

What about having a biff config per folder?
Like the "Check this folder for new messages" maybe a option like this could be
done: "Don't alert me when new message arrive in this folder". Is just an idea.

I hope this makes into 1.4, because I think the user should not be notified when
a SPAM have arrived.

Comment 47

[(not reading, please use [e-mail] instead)]

I don't think this will make it into 1.4, too late in the game.

right now, we're focused on bug that prevent us from shipping 1.4, and while we
want to address this, it's not blocking 1.4

1.5 alpha seems like a better place.

Comment 48

[Vaclav Dvorak]

Yeah, realistically, it probably won't be in 1.4. With that extra time, though,
it would be great if the per-folder config could be implemented, as suggested in
comment 46. Either that, or bug 11040. If at all possible, I don't want to be
reminded about every single mailing list posting that arrives.

Comment 49

[Matthias Versen [:Matti]]

*** Bug 207860 has been marked as a duplicate of this bug. ***

Comment 50

[Jo Hermans]

*** Bug 208029 has been marked as a duplicate of this bug. ***

Comment 51

[emmet]

As a heads up I have just built a fresh 1.5a(?) 20030618 source with this patch
applied. Everything seems fine.

Comment 52

[Scott Kester]

I to have been using the mk4 patch in my builds (gcc 3.2 linux) for the last 2
weeks, and it works great.

Comment 53

[Gilles Durys]

*** Bug 210057 has been marked as a duplicate of this bug. ***

Comment 54

[Assaf Lavie]

I'd like to try the patch myself, but I cannot build Mozilla on my XP machine.
Is there somewhere or someone I can get the relevant binaries from?
I sure would appreciate it.

Comment 55

[Matthew Elvey]

Ok, so 1.4 is out, and this has positive feedback from all testers.  
Review for the trunk and 1.4.1 needed. (Flags already set.)  It does NOT seem to
be in the latest wamcom build, but is more testing needed?  Emmett and/or scott
could provide their binaries, I guess.  Need to know if Seth is opposed to the
current patch.

Comment 56

[Marc Loiselle]

PerformBiff can be simplified to:

NS_IMETHODIMP
nsMsgDBFolder::PerformBiffCheck(void)
{
  nsCOMPtr<nsIMsgIncomingServer> server;
  nsresult rv = GetServer(getter_AddRefs(server));
  NS_ENSURE_SUCCESS(rv, rv);

  PRInt32  numBiffMsgs = 0;
  GetNumNewMessages(false, &numBiffMsgs);
  if (numBiffMsgs > 0)
  {
    server->SetPerformingBiff(true);
    SetBiffState(nsIMsgFolder::nsMsgBiffState_NewMail);
    server->SetPerformingBiff(false);
  }
  else
  {
    SetBiffState(nsIMsgFolder::nsMsgBiffState_NoMail);
  }
  return NS_OK;
}

This will allow biff to work on folders other than INBOX.

Comment 57

[emmet]

Thanks Marc,

question, when do other folders get 'new messages'?

Comment 58

[Grey Hodge (jX)]

Other folders can get new mail when you  have filters move mail from INBOX to
other folders. Example: I have all bugmail moved to a special Bugzilla folder,
all MozDev.org mail moved to a MozDev folder, etc.

Comment 59

[Ryan Russell]

>Other folders can get new mail when you  have filters move mail from INBOX to
>other folders. Example: I have all bugmail moved to a special Bugzilla folder,
>all MozDev.org mail moved to a MozDev folder, etc.

I believe it does that now, and that's what we're trying to stop?  At least, for
junk mail.  If all the mail that hits my inbox in a given download is junk
(happens frequently, unfortunately), then it biffs, even though it has all been
moved to the Junk folder.  I don't want to be notified when I get junk.  Maybe
junk is just a special case?  Apologies if I'm misunderstanding.

Comment 60

[Grey Hodge (jX)]

The scope of this bug is to biff everything except trash and Junk. All good mail
_should_ be biffed, it's just trash and a person's Junk folder that shouldn't.

Comment 61

[Gilles Durys]

*** Bug 211676 has been marked as a duplicate of this bug. ***

Comment 62

[emmet]

Attachment: Biff patch mk 6

Update of the patch absorbing comment 56's improvements. Generated against a
fresh 1.4 source and rechecked by patching another fresh 1.4 source and
building. Checked POP and IMAP. (Bugzilla patch revision number brought inline
with my local one).

Comment 63

[Charles Fenwick]

*** Bug 211664 has been marked as a duplicate of this bug. ***

Comment 64

[emmet]

Guys, I have noted a feature/bug with this patch.

The message filter 'mark as read' now works as expected, no biff if marked as
read (bug 11040).

Unfortunately, now messages filtered from the Inbox using the move filter no
longer biff. I have had a good head scratch and can't put my finger on why. One
thing though, if some messages are filtered and some not then the windows
tooltip reports the 'correct' figure computed in FillToolTipInfo(). It just adds
up all the folder->GetNumNewMessages() from the array 'mFoldersWithNewMail' --
*but* a search in LXR fails to find where folders are added to this array.

Comment 65

[Grey Hodge (jX)]

Comment on attachment 123785 [details] [diff] [review]
patch mk4

Removing r/sr req's on obsolete patch

Comment 66

[Grey Hodge (jX)]

Comment on attachment 127044 [details] [diff] [review]
Biff patch mk 6

removing r/sr reqs from buggy patch. No need to make more useless work for
them.

Comment 67

[Mike Cowperthwaite]

To follow up on comment 64, "no biff on marked read" is properly bug 206050, not
11040.

Comment 68

[emmet]

Attachment: Biff patch mk 8

This patch now corrects the problems with patch 6. Further, it was necessary to
fix bug 206050 since, I think even with patch 6 etc, when "filter mark as read"
IMAP would not biff but POP would.

So with this patch mozilla NOT biff if (a junk mail arrives OR message is
filtered to be marked as read).

Please can some people try this patch out, the range of possibilities now
affected is to large for me to test thoroughly.

Comment 69

[Robert Morris]

*** Bug 212119 has been marked as a duplicate of this bug. ***

Comment 70

[emmet]

Attachment: Biff patch mk 8

The last version of this patch wasn't quite right (all occurances of
SetNumNewMessages(0) in SetBiffState should have used the new recursive
function SetNoNewMessages instead).

This patch seems good. I have put up a zip of the 1.4 build patched with this
patch at http://www.spier.org.uk/mozilla-1.4-biff-patched.zip (11Mb). Any
testing gratefully received!

Comment 71

[emmet]

Attachment: Biff patch mk9

Sorry guys, fixing the "do biff if mail filtered to a new folder" broke the 
"don't biff on Junk mail (IMAP)" (jikes, let me tell you, a biff on a junk 
mail is now shockingly unpleasant). This patch corrects this.

(While I still had all this mail code in my head) I noted that if, in IMAP, 
you move a message from (at least a local folder) back into the Inbox you 
get a biff (with or without the previous patches). This obviously should not 
happen and is fixed in this new patch also.

The binary at http://www.spier.org.uk/mozilla-1.4-biff-patched.zip has been 
updated to incorporate this new patch.

Comment 72

[Robert Morris]

*** Bug 212712 has been marked as a duplicate of this bug. ***

Comment 73

[emmet]

Comment on attachment 127548 [details] [diff] [review]
Biff patch mk9

Setting review flags.

I've been running with the lastest patch on my mail mail IMAP account since it
was submitted. Both junk mail and 'mail filtered as read' do not biff -- I note
that the combination of a server side spam filter with the baysian filter of
mozilla  is very effective.

Comment 74

[Jo Hermans]

*** Bug 213326 has been marked as a duplicate of this bug. ***

Comment 75

[emmet]

I have been using the new patch with a 1.4 build with no problems for the last
two weeks. There have been 16 independent downloads of the (Win32) build and no
bug reports (two positive comments).

I have now built the spellchecker into

http://www.spier.org.uk/mozilla-1.4-biff-patched.zip

to encourage further testing (and successfully patched a recent 1.5 nightly). I
feel this patch is now ready for primetime.

Comment 76

[Jon Colverson]

Hello, I came up with the following test cases for this patch (expected results
are in brackets after each one):

---
Enable junk-mail controls and un-set "Move incoming messages determined to be
junk mail to:" checkbox

1. Receive non-junk mail in inbox (biff)

2. (IMAP-only) Read mail, move to another folder which is checked for new
messages, wait for next poll (no biff)

3. Move a mail from a local folder into inbox, wait for next poll (no biff)

4. (IMAP-only) Receive non-junk mail which is server-side filtered into a
non-inbox folder (biff)

5. Receive non-junk mail which is client-side filtered into a non-inbox folder
(biff)

6. (IMAP-only) Receive non-junk mail which is marked read by a server-side
filter (no biff)

7. Receive non-junk mail which is marked read by a client-side filter (no biff)

8. Receive junk mail in inbox (no biff)

9. Receive junk mail and non-junk mail in same poll (biff, only one message is
reported in the Windows notification window)



Set junk-mail controls to move incoming messages determined to be junk mail to a
folder.

10. Receive junk mail (no biff)



Turn off junk-mail controls

11. Receive non-junk mail (biff)

---

I ran through them with both Emmet's Windows binary and my own patched 1.4 Linux
build, using an IMAP account.

Tests 7, 8 and 10 biffed unexpectedly on both builds and test 9 reported two new
messages in the Windows notification window. All other results were as expected.
Can someone else please try these tests (number 8 in particular), in case the
problem is something unusual about my configuration? Thanks for working on this
patch Emmet, the fact that test case 2 works is itself very valuable to me.

Comment 77

[David Crick]

Glad to see this being fixed!

I'd also very much like to see this go into a 1.4.x release.

Comment 78

[emmet]

Comment 76, are you sure you are running the patched versions? This bug is
completely fixed for me.

Comment 79

[Jon Colverson]

Yes, I am sure I was using the correct build (20030711 downloaded from your web
site). The behaviour I'm seeing is different from the official 1.4 build,
because the unpatched build still biffs when there is mail (in an IMAP folder)
which is marked read, but is being seen for the first time by Mozilla. This part
of the patch functionality is working for me in patched builds. The part which
isn't working for me is that Moz is still biffing when mail is received which is
either found to be junk, or marked read by a client-side filter.

The biff happens as soon as the folder with the new message is checked, but the
message is not marked (as read or as spam), until after Mozilla has finished
checking all the other folders that are being checked. I tried turning off
checking of all folders except for the Inbox, and got the same result (biff
first, followed by the message being marked as spam a few seconds later).
Presumably you are seeing different behaviour (biff is delayed until after
spam/filters have been done)?

Comment 80

[emmet]

Yesterday I fetched the latest 1.5b source, applied the mk 9 patch. The source
built and ran with no problems (biff 'fixed').

http://www.spier.org.uk/mozilla-1.5b-biff-patched.zip

(No spellcheck though, the http://www.spier.org.uk/mozilla-1.4-biff-patched.zip
with spellcheck is still available).

Jon, your description sounds exactly as if you were running an unpatched copy of
mozilla, please try this new binary.

Comment 81

[Jon Colverson]

Emmet, if you'd care to read the first paragraph of comment 79 again, I
described how the behaviour of patched builds differs from the behaviour of
unpatched builds. I just tried your new 1.5b-biff-patched build and got the same
results as with your 1.4-biff-patched build.

Comment 82

[Scott MacGregor]

*** Bug 214450 has been marked as a duplicate of this bug. ***

Comment 83

[James Sams]

I filed a bug that overlapped with this and was marked as a duplicate, though it
wasn't in its entirity.  Feature requests from my bug that I have not seen in
this list (unless I misunderstood a post):
    - With messages moved by a filter to a Local Folder, clicking on the message
in the Local Folder does not remove the tray notification.  One must click on
the server folder to remove notification icon. (when mouse hovering on the tray
icon, mozilla knows the message has been read, b/c the number of messages
displayed is "0")
    - An option under user-created filters and entire mail accounts should be
'no new mail notification' for mail that is often received but doesn't need
checked quickly (listhosts and such) (currently, the option is global, all
accounts/email or none)
    - An option under both Mail Accounts and mail filters to have a separate
icon for that account filter.  
    - the notification icon should be designed so that the number of new
messages can go on top of them so the user can see without mouse hovering how
many emails have been received (i know this annoys alot of people, it's easier
to alt-tab to the mail app than it is to mouse hover over the icon for new mail.)

thoughts?

Comment 84

[Mike Cowperthwaite]

> With messages moved by a filter to a Local Folder, clicking on the message
> in the Local Folder does not remove the tray notification.  One must click on
> the server folder to remove notification icon.

That's described in Bug 107206 comment 7 & 8; that bug is kind of a superset of 
notification issues, I don't think there's a bug specifically for this symptom.

> An option under both Mail Accounts and mail filters to have a separate
> icon for that account filter.  

Not a bad idea; open a separate enhancement bug for that.

> the notification icon should be designed so that the number of new
> messages can go on top of them

Number overlaid onto the icon image?  I don't like that.  What if there are 
multiple accounts with new messages?
You can use the WinXP-style pop-up notifier to get a (short-lived) display of 
how many messages in each account, without hovering (altho this is a little 
buggy).
Anyway, that's still a separate issue and should have its own enhancement bug 
opened, if you want to pursue it.

Comment 85

[James Sams]

I've found a problem, of sorts, with the patched version.  That is, when you
manually mark messages as junk, the biff stays up.  It should go away.  This is
probably linked to the similar issue I described earlier

>With messages moved by a filter to a Local Folder, clicking on the message
>in the Local Folder does not remove the tray notification.  One must click on
>the server folder to remove notification icon. (when mouse hovering on the tray
>icon, mozilla knows the message has been read, b/c the number of messages
>displayed is "0")

The difference between these situations is that mail is not read (and thus the
displayed number of messages read does not change).  Also, the mail is still on
the server folder, as opposed to a local folder.  Interestingly, I've found that
reading junkmail in the junkmail folder (apply to manually 'junked' messages
only) DOES_NOT decrease the number of read messages from the mail notification
icon.  I think all of this makes sense

Comment 86

[emmet]

James (comment 85), you are commenting on a different (possibly not logged) bug:
"Clear biff state when message clicked on to read it or mark it as junk". The
current patch here is stable, works and grown in ambition quite enough; also
fixing your problem is independant to this patch. Please log a new bug report.

Comment 87

[Scott MacGregor]

Comment on attachment 127548 [details] [diff] [review]
Biff patch mk9

I'll review this instead of Seth. I'd like to get this in the next thunderbird
milestone release.

Some early comments:

1) Why can you just call setNumNewMessages(0) instead of adding a newmethod for
setNoNewMessages(); Does the existing method not loop through all of
subfolders?

2) getBiffNumNewMessages();

could this be renamed to something like getNumNewMessagesFromBiff() ? We are
returning the number of new messages the biff action found right? 

3) PerformBiffCheck this makes me think we are going to go off and do biff. But
that's not the case. We really just want to send out biff notifications if we
still have new mail (after the junk mail detection). Should this be renamed to
something like SendBiffNotifications or something that implies that we are
generating the right new mail notifications.

4) nsMsgFolder::GetBiffNumNewMessages has some tabbing issues (white space)

5) how about isJunk instead of 
PRBool me_junk;

Comment 88

[emmet]

Attachment: Biff patch mk9, review 1

Thanks Scott,

1) Why can you just call setNumNewMessages(0) instead of adding a newmethod for

setNoNewMessages(); Does the existing method not loop through all of
subfolders?

setNumNewMessages(0) sets ONLY the partciular message folder (which makes
sense) however for biff notification we need to check to see if any new
messages are in sub folders. Hence the need for the new recursive reset
fuction.

2) getBiffNumNewMessages();

could this be renamed to something like getNumNewMessagesFromBiff() ? We are
returning the number of new messages the biff action found right? 

ok, there is something a little wrong with the name, how about
getNumReallyNewMessages() -- a new message is an unread one irrespective of
biff state.

3) PerformBiffCheck this makes me think we are going to go off and do biff. But

that's not the case. We really just want to send out biff notifications if we
still have new mail (after the junk mail detection). Should this be renamed to
something like SendBiffNotifications or something that implies that we are
generating the right new mail notifications.

yup, how abour PerformBiffNotifications() (send to me implies they are going
somewhere)

4) nsMsgFolder::GetBiffNumNewMessages has some tabbing issues (white space)

yup.

5) how about isJunk instead of 
PRBool me_junk;

ok, but I thought it was funny.

[I've test applied the corrected patch but not test built]

Comment 89

[Scott MacGregor]

I'm ready to put an r on this patch and let David do the super review. Only one
last minor nit...

I'm still not happy with the name: getNumReallyNewMessages()

getNumNewMessagesFromBiff is what I suggested but you said that may not make
much sense. 

This method returns the # of new messages in the folder right? 

How about GetNumNewMessages? or do we already have a method by that name?

Comment 90

[Ere Maijala (slow)]

Sorry for jumping in here, but how about changing the name of the old
GetNumNewMessages which seems to return something else (number of downloaded
headers?)? 

Comment 91

[emmet]

"How about GetNumNewMessages? or do we already have a method by that name?"

Ere is correct up to before the application of the patch, after application
GetNumNewMessages returns a modified value that is tweaked if the message is
filtered as read or plugin filtered as junk.

The difference between GetNumNewMessages and GetNumReallyNewMessages is that the
latter does not include any folder with a JUNK tag in the count (and assumes
that it is recursive).

Upon reflection, the function name "GetNumNotifiableNewMessages" would be
long-winded but do exactly what it says on the tin.

Scott on your say so I will make the changes required. 

[Note: I have now built and run a fresh 1.4 source with Biff patch mk9 review 1]

Comment 92

[David :Bienvenu]

First of all, thx for working on this!

I agree that getNumReallyNewMessages is not a good method name. I think I prefer
GetNumNotifiablyNewMsgs or something like that. I do need to think a little
about all this, however. In the meantime, here are some other comments:

NS_IMETHODIMP
+nsMsgDBFolder::PerformBiffNotifications

this should be nsresult, not NS_IMETHODIMP, right? It's not an interface method.

+    {
+    nsCOMPtr<nsIMsgFolder> root;
+    rv = GetRootFolder(getter_AddRefs(root));
+    NS_ENSURE_SUCCESS(rv, rv);
+    root->SetNoNewMessages();
+    }

indentation looks wrong above.

I'm not crazy about "ProvisionalNumNewMessages", either the name, or the
implementation. You're really just interested in the /RECENT messages, I
believe. But, anyway, you're not using

+  PRBool showDeletedMessages = ShowDeletedMessages();
the variable messageIndex should be called numMessages and flagIndex should be
called messageIndex, count should be numNewUnread messages.

in the local mail folder code, I think this can cleaner, and done with less
interface changes. And I'd rather not push all this biff stuff down to these
lower levels, but rather, just ask about the newness of the message. So,

I'd change +nsPop3Sink::IncorporateComplete(nsIMsgWindow *msgWindow, PRBool *noBiff)

to +nsPop3Sink::IncorporateComplete(nsIMsgWindow *msgWindow, PRBool *msgIsNew)

and then I'd change nsParseNewMailState::PublishMsgHeader(nsIMsgWindow
*msgWindow) to return whether the new msg is new or not, look like this:

PRBool nsParseNewMailState::::PublishMsgHeader(nsIMsgWindow *msgWindow)
{
  PRBool moved = PR_FALSE;
  FinishHeader();
  
  PRBool msgIsNew = m_newMsgHdr;  // if null, there's no new msg
  if (m_newMsgHdr)
  {
    FolderTypeSpecificTweakMsgHeader(m_newMsgHdr);
    if (!m_disableFilters)
    {
      // flush the inbox because filters will read from disk
      m_inboxFileStream->flush();
      ApplyFilters(&moved, msgWindow);
    }
    if (!moved)
    {
      if (m_mailDB)
      {
        PRUint32 newFlags, oldFlags;
        m_newMsgHdr->GetFlags(&oldFlags);
        if (!(oldFlags & MSG_FLAG_READ)) // don't mark read messages as new.
           m_newMsgHdr->OrFlags(MSG_FLAG_NEW, &newFlags);
         else
           msgIsNew = PR_FALSE;
        
        m_mailDB->AddNewHdrToDB(m_newMsgHdr, PR_TRUE);
      }
    }		// if it was moved by imap filter, m_parseMsgState->m_newMsgHdr == nsnull
    m_newMsgHdr = nsnull;
  }
  return msgIsNew;
}

this removes the need for m_FilterSaysNoBiff and all the other changes to
PublishMsgHeader, including this one, which I think would crash when noBiff was
null:

+    if ((m_FilterSaysNoBiff == PR_TRUE) && (noBiff != nsnull)) *noBiff =
PR_TRUE; else *noBiff = PR_FALSE;

 Also note that you should change the base class method type signature and
return for PublishMsgHeader, i.e., 
PRInt32 nsMsgMailboxParser::PublishMsgHeader(nsIMsgWindow *msgWindow)

And then I'd change IncorporateComplete to check the return value of
PublishMsgHeader. 

Again, thx for doing this, and I'll try to think a little more about the imap code.

Comment 93

[emmet]

Bienvenu, I know I made a mess of your code, couldn't claim to follow it (c.f.
ProvisionalNumNewMessages, look no idea whatsoever) the patch is as neat a hack
as I could do (though I was careful to make sure when noBiff is null everything
works fine -- this condition is actually used in the code when it doesn't care).

I'm probably not up to making the patch fit beautifully with your code.

Comment 94

[David :Bienvenu]

You're right that null noBiff won't crash, my mistake. The reason it doesn't
crash is that m_filterSaysNoBiff will never be true when noBiff is null, but if
it was null when m_filterSaysNoBiff was true, the code would crash:

+    if ((m_FilterSaysNoBiff == PR_TRUE) && (noBiff != nsnull)) *noBiff =
PR_TRUE; else *noBiff = PR_FALSE;

I didn't mean to be discouraging; I don't think the code is at all beautiful to
start with and most of it isn't my code, at least originally. I just need to
make sure it gets more maintainable by making it easier to read and understand.
You've done the really hard part, which is getting all the logic in the right place.

Comment 95

[Ere Maijala (slow)]

If GetNumNewMessages() and the new one are quite similar, why not combine them
by adding one parameter?

Comment 96

[Allen Castaban]

If I download the official 1.5beta from the http://www.mozilla.org/releases/
page,  does it include this fix.  If so, it stopped working for me...  Seth's
patched version was working for me.

Comment 97

[Stefan Borggraefe]

*** Bug 218450 has been marked as a duplicate of this bug. ***

Comment 98

[Stefan Winopal]

This Bug has to be fixed in Mozilla Thunderbird, too!

Comment 99

[Allen Castaban]

I take this is not integrated into 1.5b yet, it would be really really nice to
be included in 1.5 release, the fix was available since 1.4b days, guys

Comment 100

[Matthew Elvey]

Q: Is this fixed in 1.5b?  

A:You can tell this yourself.  Here's how: The bug status is Assigned. 
Furthermore, the comments show that no code has been reviewed (and possibly
super-reviewed) or checked in to the trunk.  After all that has happened, it
will be in the nightly builds.  (And statuses will generally change: 
Resolved...Verified...Fixed) Even then, it'll be a little while more 'till it
makes it into a milestone release.  It won't be in 1.5 because 1.5's freeze date
has passed.  At least thats how I understand things work.  See
http://www.mozilla.org/roadmap.html . 

Q: What are the flags for?  http://bugzilla.mozilla.org/flag-help.html doesn't
explain.  I set blocking1.4.x thinking I understood what it was for, but Asa
unset it, without explanation, so it seems I don't.  Are they only for Mozilla
embedders? (inferred from a roadmap comment)  Seems pretty clear to me that this
is a bug that severely impacts a critical feature of Mozilla, and had a coded
bug fix for months when I set the flag, it was to see if it could get reviewed
for 1.4.1; perhaps 1.4.1 has been frozen?.
It seems blocking1.4.x turned into blocking1.4.1?  Based on the dox I can find,
setting blocking1.4.2? makes sense, so I'm doing it.  Comments/pointers appreciated.

Comment 101

[Allen Castaban]

I have very limited involvement with this, so I am sorry that I had problems
interpreting that whether this was supposed to be in 1.5b or not. I think I
misunderstood the comment saying 1.5 source pulled out and tried.  Sorry about
that. 
But the fact remains that this fix has been around for a few months now and
although this looks like a minor bug, it most definitely not. Mozilla came up
with this EXCELLENT junk Controls feature which is working very very well. This
bug cripples that excellent feature a lot, as I still check whether there is
"real" mail or not.  I don't know whether this still can go to 1.5, but it would
be REALLY REALLY cool if it could

Comment 102

[Giovanni Gatti]

What about the JUNK MAIL fix for Mac OS X: I still have to run it manually
because it does not check automatically for junk mail upon arrival in most folders.

Comment 103

[Nico Dummer]

This fix is more important to me than any other non fatal Bug, so is there a
private 1.4.1 Windows sea Build available somewhere with the fix compiled in?

Or do i have to switch to some other less annoying Mailclient (when it comes to
Junkmail) perhaps with a Plugin?

I can not understand why it is not getting the attention it deserves from the
dev people because Junkmail filtering makes nearly no sense if the user is
getting bugged and annoyed anway.

I already tried to disable all notifications so that im not tmepted to look for
the arriving mails but the little newmail icon in the systray appears no matter
what i disable and when i look it is only annoying junkmail most of the time.

Comment 104

[Gilles Durys]

*** Bug 219933 has been marked as a duplicate of this bug. ***

Comment 105

[Gilles Durys]

*** Bug 220000 has been marked as a duplicate of this bug. ***

Comment 106

[David :Bienvenu]

I can look at driving this in.

Comment 107

[Sebastian Redl]

Why didn't a search on "mail notification junk" find this bug?

Comment 108

[Adwin Timmer]

I did a search "mail notification spam", and that didn't turn up any results.
For non-english speakers, "spam" is used for junk mail, not "junk".

Comment 109

[http://tinymailto.com/oliversl]

Reporter, please replace summary with this string:
"No new mail notification (biff) when junk (spam) mail arrives"
This will help a lot when searching. Thanks

Comment 110

[David :Bienvenu]

taking

Comment 111

[David :Bienvenu]

for now, I'm just going to fix this for pop3 junk mail - the patch does a lot
more, but I think the fix for just ignoring pop3 junk mail will be a lot
simpler. Then I'll look at imap, and then the general problem.

Comment 112

[Gilles Durys]

*** Bug 220154 has been marked as a duplicate of this bug. ***

Comment 113

[David :Bienvenu]

Attachment: proposed fix

I'm still testing this - this fixes pop3 and imap  not to biff when junk mail
only arrives. It's a rather different approach than the other patches in this
bug, and doesn't require as many interface changes or new methods. It doesn't
deal with messages marked read by filters though I think it shouldn't be hard
to fix that.

Comment 114

[David :Bienvenu]

Attachment: simpler fix

after some more testing, this is the current patch.

Comment 115

[David :Bienvenu]

fix checked in, r/sr=mscott, please let me know if you see any regressions in
biff, or if this doesn't work for you.

Comment 116

[Stephen Donner [:stephend] Not actively reading bugmail]

David, I'm not sure if you've seen this, but bug 64947 has a few Biff 
suggestions by Seth.

Comment 117

[Robert Accettura [:raccettura]]

Not sure if this happens already.

But when using a third party filter, any message that's delivered to a non-inbox
shouldn't trigger the filter.

Hence If I write create a filter that sends all X-Spam-Filter: Yes to Junk.

When mail is sent to junk... no notification.

Many have their own mail filters (DNSBL enabled engine, SpamAssassin, etc.). 
Like myself... don't want to be notified when mail is sent to "Junk".

Comment 118

[Mike Cowperthwaite]

The patch appears to be working for me.  "New" flags are suppressed for the 
message and the receiving account, and for the component-bar icons; and the 
systray icon does not appear, if the arriving new mail is ID'd as junk.  The 
message is still marked as Unread, which is desirable to avoid missing false 
positives.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20030930


Robert Accetura, for suppressing notification on other filtering conditions, see 
the following (summaries mine, rather than what appear on the bugs):
  bug 11040: provide filter action to "suppress notification"
  bug 91498: suppress notification for mail filtered with "delete"
  bug 206050: suppress notification for mail filtered with "mark as read"

I would say that "any message that's delivered to a non-inbox shouldn't trigger 
the filter" is too broad of a rule; I can think of many cases where I'd prefer 
to be notified even if the message is moved.

Comment 119

[Joe Konecny]

I'd rather see them marked read.  If you leave them unread, they are still moved
to junk and you still need to mark all of them read.  Marking them read would
eliminate a step.  You can always look at them for false positives.  Ideally
there would be an option to mark them read or not.  There are several bugs filed
for that.

Comment 120

[Ere Maijala (slow)]

If it's implemented, it must be an option. As Mike, I like to have them unread
so I know what I need to browse through.

Comment 121

[tyl2]

If a mail is marked read, can there be no notification? This bug would seem to
be responsible for that too.

Comment 122

[Stefan Borggraefe]

*** Bug 221933 has been marked as a duplicate of this bug. ***

Comment 123

[Gilles Durys]

*** Bug 221989 has been marked as a duplicate of this bug. ***

Comment 124

[David :Bienvenu]

I've left this bug open to deal with the case that filters mark messages read.
The original patch had that functionality, but I didn't retain it when I
developed my modified patch, since I thought getting it working for junk mail
was the most important thing.

Comment 125

[Oleg Sidletskiy]

*** Bug 224031 has been marked as a duplicate of this bug. ***

Comment 126

[Oleg Sidletskiy]

*** Bug 224614 has been marked as a duplicate of this bug. ***

Comment 127

[Matthias Versen [:Matti]]

*** Bug 224936 has been marked as a duplicate of this bug. ***

Comment 128

[Lorenzo Colitti]

bienvenu, thanks for implementing this! It really raises the SNR.

A small nit, though: when a non-spam message is sent to another folder via a
filter, sometines, but not always, biff fires, saying "<account> has 0 new
messages". In this case, it either shouldn't fire at all or should fire but say
the account has 1 new message.

Comment 129

[David :Bienvenu]

Lorenzo, is that on IMAP? I saw that in some initial testing and never could
figure out how to reproduce it and then I didn't see it again.

Comment 130

[Lorenzo Colitti]

David: yes, I'm using IMAP (Thunderbird 20031024 trunk nightly). The message
arrives into an inbox on one server and is filtered to a subfolder on another
(IMAP over SSL) server.

Is there anything special I should look out for? I don't think it will be easy
to capture a reasonable log, since it seems to be pretty random...

Comment 131

[Jo Hermans]

*** Bug 225356 has been marked as a duplicate of this bug. ***

Comment 132

[Sven Burgener]

Speedy integration of an option "Notify on new Junk E-Mail" along with the
necessary functionality would be greatly appreciated!

It's quite troubling seeing the "Mail Notification Icon" in the windows tray bar
and then loading (or maximizing, which, depending on the machine, can take quite
a bit) and then only finding that there are ten new junk messages. And that
perhaps a few times a day.

Whats the target milestone for this bug? I had already hoped that this feature
would make it for 1.5... Keep up the good work!

Comment 133

[Andreas Kunz]

Sven, please see comment #115 and comment #124: this bug is already fixed in
Mozilla 1.6alpha (and I'm enjoying it!) and in the last six week's nightlies.

Comment 134

[Kai Stukenbrock]

Marking fixed, as per comments.

Comment 135

[Andreas Kunz]

Kai, are you aware of comment #124 ?

Comment 136

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Obviously he is not. Kai: please read the bugzilla guidelines before you do
anything more in bugzilla

Comment 137

[Matthew Elvey]

Kai, Jonas, I'm sure it was an honest mistake, no big deal, IMHO.  Adding "[not
fixed yet, per comment 124 : or when filters mark mail as read]" to Summary. 

Comment 138

[Felix Miata]

Were any of these patches checked into the trunk late Sept/early Oct? If so, the
timing of bug 221165 is mighty suspicious.

Comment 139

[Vaclav Dvorak]

Andreas, are you aware of comment #118? :-)
Andreas, Kai, Jonas, Matthew: I believe the case of filters marking mail as read
is covered by bug 206050, so this one can be closed. But David Bienvenu should
have the final word, I guess.

Comment 140

[David :Bienvenu]

that sounds reasonable - I was going to suggest spinning off another bug for
that issue. Marking fixed.

Comment 141

[Igor Velkov]

I have some folders, where messages from not-emergency robots are stored - like
arpwatch, antivirus reports, backups, etc. 
I need this messages for history, but i dont need "new mail sound", or flag in
my systray, where new message filtered into this folders. Maybe, will be better
not to make "no new mail notification on junk mail", but "no new mail
notification if mail moved by filter to specifical type of folder, or where
filter mark mail as read automaticaly"?

Comment 142

[Sebastian Lisken]

Maybe the question whether an incoming message should get reported
could become a property of a) the folder a message is arriving in
or b) of the filter that matches the message? I'm not sure if the
current fix is compatible with any of these alternatives or if it
even implements one - in that case, apologies.

Comment 143

[Vaclav Dvorak]

This bug is FIXED. Please see comment 118 for pointers to other related bugs.
Adding comments here makes no sense unless there is a problem with what this bug
is about: no notification for spam, and specifically spam only.

Comment 144

[Mike Cowperthwaite]

*** Bug 226611 has been marked as a duplicate of this bug. ***

Comment 145

[Mike Ashcraft]

Can anyone tell me how I add/download the patch for this? Clicking on the above
attachments just brings up jibberish (to me anyway). No exe file to download an
install?

Comment 146

[Joe McCabe]

Mike - The fix has been integrated in the nightly builds since 9/28/2003. It
should be a part of 1.6beta, and any nightly build since that checkin date.

Information on how to acquire these builds can be found on www.mozilla.org.

Comment 147

[Mike Ashcraft]

But I was referring to THUNDERBIRD.

What's the latest version of the standalone Thunderbird, and where can I get 
that? I see the latest on your site is .3

I have .4

Is there a later version?

Comment 148

[Scott MacGregor]

the current version of thunderbird is 0.3

0.4 has not been released yet and is in the alpha stage. Nightlies are provided
for testing purposes for 0.4a

Comment 149

[Trieu Truong]

For Thunderbird bug information, you may want to check out the Thunderbird
website and forums.  As stated on the Thunderbird homepage[1]:

Thunderbird mail forums[2]:  Please file all bugs in the bugs forum here instead
of posting in bugzilla.

[1] http://www.mozilla.org/products/thunderbird/
[2] http://www.mozillazine.org/forums/index.php?c=8

Comment 150

[Ian Nartowicz]

This bug is fixed in the latest version of Thunderbird (0.4 release candidate 1)
at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2003-12-01-trunk/.
 There is no patch, you must download the whole thing.  Sorry for the spam.

Comment 151

[Matthias Versen [:Matti]]

*** Bug 228055 has been marked as a duplicate of this bug. ***

Comment 152

[Andrea Schafferhans]

Unfortunately I can't really agree that this is fixed. Neither 1.6a, 1.6b nor
the new 1.6 version (Linux, IMAP) give the promised result, i.e. no new mail
modification (sound) for messages marked as Junk by mozilla.
Sometimes, but not always, I have observed that messages are moved to a
different folder by a filter, and only when I open that folder, the junk mail
tagging occurs and moves the message to the Junk folder. That probably is a
different bug (and I understand that in such a case the new mail notification
comes).
However, I have also had cases where the only new mail I find after a new mail
notification is mail that has been marked as junk and moved to the Junk folder.
Has anyone else observed the same?

Comment 153

[Simon Males]

I agree with comment 152, if mail is moved to another folder via filter, then
that folder is selected. Junk mail controls are then initialised upon selection
of the folder.

Comment 154

[Henrik Skupin [:whimboo][⌚️UTC+2]]

*** Bug 221300 has been marked as a duplicate of this bug. ***

Comment 155

[Mike Cowperthwaite]

I've just opened the following bugs:
  Bug 233929: Still get notification on junk if messages left in Inbox
  Bug 233930: Still get notification for junk that's been filtered to a
              different folder

Comment 156

[Mike Kaply [:mkaply]]

I don't think this needs to go into the 1.4 branch at all - someone can argue
with me if they want.

Comment 157

[Gary L. Chipman]

How do poor non-programming schmoes like me get to use the "simpler fix" posted
9-26-03? I'm not a techno-idiot, but the "fix" might as well be in Greek.

My Mozilla 1.6 still gives me a notification for two types of incoming spam:

(1)Mail that's modified by Spam Assassin proxy putting "*****SPAM*****" in the
subject line, then marked as "Read" and moved to the "Junk" folder by my Mozilla
custom filter; and,

(2) Mail that's auto-marked as "Junk" by Mozilla and auto-moved to the Junk folder.

As was pointed out early on in this thread, there's little point of having both
new email notification and spam filtration, if spam still triggers the notification.

By the way, the two spam filtering programs together -- SAProxy and Mozilla --
have eliminated nearly all spam from my Inbox folder. About one in a thousand 
gets through, and those are mostly empty -- nothing to filter, I suppose. False
negatives from Mozilla have dropped to nil using the Not Junk button and adding
"White List" senders to my address book.

Ironically, when I set up my Bugzilla Account, Mozilla marked the email
containing my password as Junk and sent it to the local Junk folder. Snort! Does
that qualify as a bug?

To repeat my question: How do I "fix" this otherwise sterling piece of software
 to keep it from notifying me that I have new spam in my Junk folder, but still
notify me when new mail stays in my Inbox folder?

Comment 158

[Gary L. Chipman]

Please make that "...when new unread, unmarked mail stays in my Inbox folder?"

Comment 159

[Mike Cowperthwaite]

Gary Chapman: your case (1) is covered by bug 206050, which in fact has a fix 
that's been checked in and available in 1.7a.  If you had read this bug 
carefully, you would have seen that issue has already been raised several times 
and several times redirected to bug 206050.

Your case (2) is what this bug is about, and in my experience that has in fact 
been fixed.  If you are in fact encountering some situation where you are 
getting notification following the receipt of a new message that's marked as 
Junk and moved the junk folder, please open another bug about it.  I suggest you 
test thoroughly, first.

Comment 160

[Matthias Versen [:Matti]]

*** Bug 240400 has been marked as a duplicate of this bug. ***

Comment 161

[Tahir]

To back up Gary Chipman's comment #157, I experience both issues 1 and 2 that
Gary listed. I was using the contrib 1.6 build:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040118

To be more specific, the MailNews icon in the bottom-left icon-box changes to
reflect new mail arrival, even if the mail has been auto-marked as junk or
marked as read and moved to trash.

Comment 162

[Ian Nartowicz]

I am thinking there may be an issue with profile upgrades?  I upgraded from 1.4
(I think) where this bug existed to 1.7b where this bug is fixed.  I continued
to get notifications when junk was received, auto-marked, and moved to the junk
folder.  Sometimes it would be a popup and sometimes just a chime.  I was using
a single junk folder for multiple POP emails accounts.  To narrow down when this
occurred and when it didn't, I configured separate junk folders for each account
and got no notifications.  Then I configured everything back to one junk folder
and still got no notifications.  Although I apparently have the same
configuration that was giving notifications before, I don't seem to be able to
reproduce the problem now, which is why I suspect some kind of profile hangover.

Comment 163

[jwq]

Bug 248758 raises a clearly related issue, where the new mail notification is
not suppressed when a user-defined message filter includes the action "Set Junk
Status to: Junk."

 I don't know whether Bug 248758 constitutes a duplicate/regression of this bug
or whether the issue would be better dealt with separately, in Bug 248758.

Comment 164

[Thomas Gstoettenmayr]

would be really great to have an extra option in the settings
where you can enable or disable alerts on junk-mail.