257421 - Using Global Inbox for multiple accounts, filters send spam to hidden Trash folder

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[Meaker]

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

I have 5 accounts all using the Global Inbox (Local Folders) feature. During a
spam mail flood incident some days ago, I set a filter for incoming email for
/one/ of these accounts, and found later that some 90-odd spam messages of the
filtered mail had gone to that individual account's hidden Trash folder. 

It looks like not every part of the program is Golbal Inbox aware.

Reproducible: Didn't try
Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Cowperthwaite]

When setting up a filter, the deferred accounts are not listed in the dropdown 
for selecting a destination folder.  
Either that was broken in your case, or you set up the filter before deferring 
the account to the global inbox.  When you defer an account, the warning box 
reads, in part, "If you have filters that filter mail into this account, you 
should disable them or change the destination folder."
See bug 250212 comment 8 et seq.

Comment 2

[David :Bienvenu]

Was the filter action "Delete"? It's possible that action is not global inbox
aware...

Comment 3

[Meaker]

(In reply to comment #1)
> When setting up a filter, the deferred accounts are not listed in the dropdown 
> for selecting a destination folder.  

Correct, and that's how it worked in my case.

> Either that was broken in your case, or you set up the filter before deferring 
> the account to the global inbox.

Neither condition applies. The accounts were all changed to Global Inbox at install.

Comment 4

[Meaker]

(In reply to comment #2)
> Was the filter action "Delete"? It's possible that action is not global inbox
> aware...

Yes, the action was "Delete".

Comment 5

[Meaker]

I have a further serious anomaly to report. Since switching my 5 email accounts
from Global Inbox  (GI) to using individual folders and then back to GI again, I
now find that even though Global Inbox is checked for all accounts, mail is
being sent intermittently to the individual accounts hidden Indox and Trash
folders. Whoops! This is now a major bug. What alerted me to this bug is that on
several occasions I saw that the status bar indicated that mail was arriving,
yet I got no pop-up message stating mail had arrived and no mail appeared in the
Global Inbox or in the Global Junk or Trash. Where had they gone? I went back to
the non-GI format and found mail in two accounts.

I shall have to abandon using Global Inbox until these bugs are sorted out.
Global Inbox is now unusable in my opinion for a production, serious
environment, and needs an urgent fix.

Comment 6

[David :Bienvenu]

Intermittently? Any idea what makes it behave differently? Are you sure that the
new mail arrived when you had the account set to global inbox? The status window
popping up is not conclusive evidence... And do you have filters that move mail
around that you don't fix up when switching back and forth?

Comment 7

[David :Bienvenu]

Attachment: fix delete action on deferred accounts

get the trash folder that's a subfolder of the deferred to account, not the
original account...

Comment 8

[David :Bienvenu]

Re mail intermittently going to the wrong account, I'd need info about how to
reproduce this...

Comment 9

[David :Bienvenu]

also, did you shut down between changing the state between global inbox and not?
I'm not saying you should have to shut down, but if you didn't shut down, that's
one area to investigate.

Comment 10

[David :Bienvenu]

fix for delete filter action case checked into trunk and branch. We should open
a new bug for the other issue, if we can get some traction on it.

Comment 11

[Meaker]

(In reply to comment #6)
> Intermittently? Any idea what makes it behave differently? Are you sure that the
> new mail arrived when you had the account set to global inbox? The status window
> popping up is not conclusive evidence... And do you have filters that move mail
> around that you don't fix up when switching back and forth?

I have no filters that move stuff around.

Yes, the errant mail definitely arrived while set to GI, yet ended up in the
non-GI folders. This has only started happening since I did a GI then non-GI
juggling act, and during all of this I have not REBOOTED the machine, and I'm
not even sure I've killed Moz from memory, although I have closed and opened
mozmailnews a few times. I've got Moz memory-resident for fast startup, so that
may be an issue. You may be setting flags that don't get properly reset without
a complete restart.

Comment 12

[Meaker]

(In reply to comment #9)
> also, did you shut down between changing the state between global inbox and not?
> I'm not saying you should have to shut down, but if you didn't shut down, that's
> one area to investigate.

To test, I'm going to 1) block internet access [to prevent any mail arriving
while I'm making changes] then 2) change all accounts back to GI, then 3) reboot
machine, and lastly, 4) recheck the hidden folders in a day or three. If no mail
in them, then we can assume this is a bug related to flag setting and restarts.

Comment 13

[David :Bienvenu]

yes, mozilla has to really shut down all the way to clear out any member
variables that might be set incorrectly. That being said, it wouldn't cause an
intermittent problem - for each server, that server would either download new
mail into its inbox, or the deferred to inbox but not go back and forth. Looking
at the code, we do cache the root msg folder for each pop3 server, and I don't
think we're clearing that correctly when you switch back and forth. Clearing it
would force us to recalculate the correct value.

Comment 14

[Meaker]

> To test, I'm going to 1) block internet access [to prevent any mail arriving
> while I'm making changes] then 2) change all accounts back to GI, then 3) reboot
> machine, and lastly, 4) recheck the hidden folders in a day or three. If no mail
> in them, then we can assume this is a bug related to flag setting and restarts.

I've just done the restart, and noticed another bug that may be the actual
culprit. :-)

When I went in to change all accounts back to using GI while they were currently
using individual folder sets, I changed the first account to GI and, as
expected, its folders popped out of sight in the left hand pane of mailnews. I
then went to change the next account to use GI, and found that it was *already
using* GI acording to the dialog box, whereas it is /not/ -- I had checked it a
moment before and it was set to non-GI, plus its folders were still all visible
in the pane alongside. So here's a bug that could lead people and mailnews
itself to think that an account is using GI whereas it actually isn't.

I managed to fix this (I hope), by clicking "OK" on the dialog box, EVEN THOUGH
I HAD MADE NO CHANGES. The left pane then updated to remove the accounts
folders, as per true GI mode. So the dialog box opened to show GI was being used
when in fact it wasn't, and you have to click OK to get it to actually go into
GI mode.

I wnet ahead and did this for each account. All accounts exhibited the same bug
(says GI, but isn't).

Hmmm. This important GI facility is still a little flaky, David.

Comment 15

[David :Bienvenu]

>I've just done the restart, and noticed another bug that may be the actual
>culprit
I see that behaviour as well - I'm not sure it could account for what you saw,
however.

I only see that behaviour if I don't select any other line in the account
settings dialog between selecting the server settings (e.g., instead of
selecting the server settings for the second server, if you select the top level
settings for the first account, and then select the server settings for the
second server, you won't see the bug). So I suspect this is a very specific bug...

Comment 16

[David :Bienvenu]

Attachment: proposed fix

this fixes the potential issue with newly deferred accounts not realizing
they're deferred, or not deferred until restart, and it fixes the problem with
Global Inbox getting set for the second server automatically after setting it
for the first server - it was a tangled web, but it turns out that since we
didn't have a default empty value for the deferred_to_account, the automatic
form <-> account page data code errored out and would not clear the old value.
I also removed some code that explicitly set the deferredToAccount so that the
user could cancel out of the dialog and not set the account as deferred.

Comment 17

[David :Bienvenu]

second patch also checked into aviary branch.

Comment 18

[David :Bienvenu]

fixed on trunk as well.