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

UNCONFIRMED
Unassigned

Status

Thunderbird
Filters
UNCONFIRMED
5 years ago
3 years ago

People

(Reporter: Walt Northrup, Unassigned)

Tracking

({qawanted})

17 Branch
x86_64
Windows 8
qawanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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?
(Reporter)

Comment 5

5 years ago
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.
(Reporter)

Comment 8

5 years ago
"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?

Comment 10

3 years ago
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

Comment 11

3 years ago
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
=========================

Comment 12

3 years ago
I have had this problem since update to TB 38.3 from TB 38.2.

Comment 13

3 years ago
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.
You need to log in before you can comment on or make changes to this bug.