Closed Bug 900142 Opened 11 years ago Closed 6 years ago

Filter does not work with setting: "Apply filter when: Checking Mail (After Classification) or Manually Run"

Categories

(Thunderbird :: Filters, defect)

17 Branch
x86_64
Windows 8
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: walt_northrup, Unassigned)

Details

(Keywords: qawanted)

User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; Tablet PC 2.0; Media Center PC 6.0) Steps to reproduce: Created a filter at the bottom of the list as follows: Checking Mail or Manually Run "Match all of the following" "X-Account-Key" is "account1" "To" doesn't contain "xxxxx@yyyyy.com" Perform these actions: "Forward Message To" xxxxx@yyyyy.com This filter seems to work as expected. Deleted this filter and created another one that is identical EXCEPT Used Checking Mail (after classification) or Manually Run Added a condition under Match all of the following: "Junk Status" isn't "Junk" Actual results: The second filter does not work. Nothing gets forwarded. Creating a filter removing the "Junk Status" isn't "Junk" does not work either, so it appears just changing to "after classification" breaks it, or perhaps I just don't understand what after classification does. Expected results: I think the mail should have been forwarded.
This is actually Tbird 17.0.7.
Walt, thanks for filing this well-written bug report. I've flagged this to be examined, sounds plausible as described. It's just a handful of volunteers like me to handle thousands of bugs, so let's hope somebody has some free cycles to look at this eventually. Might not get high priority as it's pretty advanced stuff, and we have lots of worse things around which affect more users.
Keywords: qawanted
FTR: Reporter talks about the following setting in the "Filter Rules" editing dialogue: Apply filter when: "Checking Mail (After Classification) or Manually Run" With default setting of "Checking Mail or Manually Run", filter works as expected. Changing the setting to "...After Classification..." apparently causes the filter to fail.
Summary: After Classification Filter not Working as Expected → Filter does not work with setting: "Apply filter when: Checking Mail (After Classification) or Manually Run"
Can somebody add a filter expert on this?
Flags: needinfo?
Thanks for the bug update and for all you efforts. Being an old developer myself, I hear what you are saying.
Flags: needinfo?
"Checking Mail (without After Classification)" means Message filter runs first on a mail, Junk filter runs second on the mail(on both mail remains in Inbox and mail moved by message filter without setting Junk/NonJunk status or JunkScore). "Checking Mail (After Classification)" means Junk filter runs first on a mail, Message filter runs second on the mail if the mail is not moved or deleted by Junk filter. So, if a mail is moved or deleted by Junk filter when "Checking Mail (After Classification)", "filter is not applied to the mail" is petty normal phenomenon. To bug opener: Check both message filter log and Junk log/your Junk setting, please.
FYI. (i) Bug 762318 can occur with "Checking Mail (without After Classification)". "Checking Mail (After Classification)" is a known workaround of Bug 762318. (ii) Bug 750630 can occur with "Checking Mail (without After Classification)". "Checking Mail (After Classification)" is also a known workaround of Bug 750630. Both phenomenon looks that "Junk filter" is invoked too early when "Checking Mail (without After Classification)". (i) Bug 762318 : "Junk filter" is invoked before writing message filter log for "move mail" which is done before actual "move mail by message filter" operation. (ii) Bug 750630 : "Junk filter" is invoked while "move/copy mail by message filter" is in progress, and o"Junk filter" interferes filter copy/move.
"To bug opener: Check both message filter log and Junk log/your Junk setting, please." I don't think this could be it. Note in my original email that NO messages are being handled by the filter, even the ones that are not junk. Perhaps I don't understand the comments. This is not a case of some messages not getting handled.
(In reply to Walt Northrup from comment #8) > Note in my original email that NO messages are being handled by the filter, even the ones that are not junk. > Perhaps I don't understand the comments. I think so. - Actual "move of mails by filter" is executed after wrting log of "a mail is moved by filter". After writing filter log, actual "filter move" may silently fail。 => Check of message filter log is needed, isn't it? - Bug 762318 can occur. In this case, useless filter log is written, and actual "filter move" is not executed silently. This case doesn't look "mail is moved by Junk Filter". It looks "Message filter move is interfered by Junk Filter execution" or "Message filter and Junk filter intereferes each other". => "Junk Filter move" may fail silently after writing log, if interfered. It's needed to surely rule out "Junk scrore is added by Junk Filter", isn't it?
Thunderbird 31.7.0 on Fedora From many months, some of my filters ceased to work. Here a message header of not correctly processed e-mail ========================= From - Mon Jun 1 12:00:00 2015 X-Account-Key: account4 X-UIDL: _removed X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Delivered-To: me@foo.com Received: by ip_removed with SMTP id _removed; Mon, 1 Jun 2015 03:32:41 -0700 (PDT) X-Received: by ip_removed with SMTP id _removed; Mon, 01 Jun 2015 03:32:41 -0700 (PDT) Return-Path: <illa@foo.org> Received: from bugs.foo.org (bugs.foo.org. [ip_removed]) by mx.foo.com with ESMTPS id ip_removed for <me@foo.com> (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 01 Jun 2015 03:32:41 -0700 (PDT) Received-SPF: neutral (foo.com: ip_removed is neither permitted nor denied by domain of illa@foo.org) client-ip=ip_removed; Authentication-Results: mx.foo.com; spf=neutral (foo.com: ip_removed is neither permitted nor denied by domain of illa@foo.org) smtp.mail=illa@foo.org; dmarc=fail (p=NONE dis=NONE) header.from=gmail.com Received: from www-data by bugs.foo.org with local (Exim 4.82) (envelope-from <illa@foo.org>) id 1YzN1M-0002U7-UT for me@foo.com; Mon, 01 Jun 2015 10:32:40 +0000 From: FooMan_1 <fooman_1@foo.com> Sender: illa@foo.org To: me@foo.com Subject: removed in Mozilla Firefox is possible Date: Mon, 01 Jun 2015 10:32:39 +0000 Reply-To: asd@bugs.foo.org Message-ID: <bugremoved@http.bugs.foo.org/> In-Reply-To: <bug-a@http.bugs.foo.org/> References: <bug-a@http.bugs.foo.org/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.foo.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 ========================= the e-mail filter is: - if even one condition is satisfied: * from, to, CC, CCN contains asd@bugs.foo.org * reply to contains asd@bugs.foo.org - move to foo folder - when apply filter: * manually; * emails download, before spam detection
The previous message was missing some headers info. I attach a more complete version ========================= From - Mon Jun 1 12:00:00 2015 X-Account-Key: account4 X-UIDL: _removed X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Delivered-To: me@foo.com Received: by ip_removed with SMTP id _removed; Mon, 1 Jun 2015 03:32:41 -0700 (PDT) X-Received: by ip_removed with SMTP id _removed; Mon, 01 Jun 2015 03:32:41 -0700 (PDT) Return-Path: <illa@foo.org> Received: from bugs.foo.org (bugs.foo.org. [ip_removed]) by mx.foo.com with ESMTPS id ip_removed for <me@foo.com> (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 01 Jun 2015 03:32:41 -0700 (PDT) Received-SPF: neutral (foo.com: ip_removed is neither permitted nor denied by domain of illa@foo.org) client-ip=ip_removed; Authentication-Results: mx.foo.com; spf=neutral (foo.com: ip_removed is neither permitted nor denied by domain of illa@foo.org) smtp.mail=illa@foo.org; dmarc=fail (p=NONE dis=NONE) header.from=gmail.com Received: from www-data by bugs.foo.org with local (Exim 4.82) (envelope-from <illa@foo.org>) id 1YzN1M-0002U7-UT for me@foo.com; Mon, 01 Jun 2015 10:32:40 +0000 From: FooMan_1 <fooman_1@foo.com> Sender: illa@foo.org To: me@foo.com Subject: removed in Mozilla Firefox is possible Date: Mon, 01 Jun 2015 10:32:39 +0000 Reply-To: asd@bugs.foo.org X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: foo X-Bugzilla-Component: X-Bugzilla-Version: X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fooman_1@foo.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: NOR X-Bugzilla-Assigned-To: mklapetek@kde.org X-Bugzilla-Target-Milestone: 1.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: <bug-foo1@http.bugs.foo.org/> In-Reply-To: <foo_2@http.bugs.foo.org/> References: <foo_2@http.bugs.foo.org/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.foo.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 =========================
I have had this problem since update to TB 38.3 from TB 38.2.
The problem went away for me after I deleted and recreated the .msf file for the destination folder for my TB filter for Cactus Spam. The "Cactus Spam" TB filter was not moving spam into that file, because somehow its .msf file had been corrupted or deleted. Perhaps (just perhaps) the problem described by others above can be fixed by deleting and recreating the .msf file for the Junk folder.
walt writes "I don't remember what I was trying to do, but I'm not doing it anymore." Germano, if you still see this problem, please file a new bug or clarify how your issue reproduces in a manner smilar to this bug
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
(In reply to Wayne Mery (:wsmwk) from comment #14) > Germano, if you still see this problem, please file a new bug or clarify how > your issue reproduces in a manner smilar to this bug Luckly I ceased to experience the problem a lot of time ago :-)
You need to log in before you can comment on or make changes to this bug.