527672 - After classification message filters do not work with custom mail headers

Status: NEW

(MailNews Core :: Filters, defect)

Description

[Christian Franke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

If a message filter which is applied 'after classification' contains a condition to match (not match) a string in a custom header line, the condition will never (always) be true.


Reproducible: Always

Steps to Reproduce:
1. Tools|Message Filters

2. Add the following filter with custom header "Received":
Apply filter when: [Checking Mail (after classification) or Manually Run]
Match if: [Received] [contains] [from]
Action: [Tag Message] [ToDo]

3. Add a 2nd filter:
Apply filter when: [Checking Mail or Manually Run]
Match if: [Received] [contains] [from]
Action: [Tag Message] [Later]

4. Close Message Filters
5. Get Msgs
6. Examine Tags of new messages

Actual Results:  
Tags: Later (Only 2nd filter matched)


Expected Results:  
Tags: ToDo Later (After classification filter should also match)


If conditions are changed to
  [Received] [doesn't contain] [from]
the after classification filter does always match.

If both filters are run manually, the result is as expected.

Comment 1

[Kent James (:rkent)]

If someone attempts to reproduce this, it would be good to also try it with a different custom header. "Received" has its own complex issues which something like "X-SPAM" does not.

Comment 2

[Christian Franke]

The issue was actually detected when I used the following condition in a filter:
  [X-Spam-Level] [contains] [*****]

Comment 3

[Kent James (:rkent)]

I can confirm this. I suspect this is the same issue that has been discussed a lot in bug 184490, and that I intend to fix in bug 363238. For now there is the workaround (which bug 363238 will automate) that the custom header needs to be added to the mailnews.customDBHeaders preference, then it will work.

Comment 4

[Bitter, Lemon]

Have the same problem here:

Trying to construct a filter to take messages 1 & 2 from list A and decide if they have attachments:

An older post on a website says I can add the custom header X-Mozilla-Status2 with the criteria
[X-Mozilla-Status2] [Begins with] [1]
[Move to] [Local Folders/Mailing List A/Attachments]

This wasn't working upon 'Checking Mail'; it seemed like Thunderbird was not adding the flag X-Mozilla-Status2 until after mail was checked; 'Manually Run' would work, detecting the status and moving the message properly.


I noticed I only had access to:
[Attachment Status] [is] [Has Attachment]
if I loaded in one of the addons?
In any case, addon or not, 'Attachment Status' criteria is only available for 'Local Folders' filters, which doesn't make any sense to me, as messages are received into the POP account folder, not Local Folders.

.. back to [X-Mozilla-Status2]- With Thunderbird 3.x, has been added '(after classification)'. My filters dependent on X-Mozilla-Status2 and other common fields [List-ID], when switched to (after classification) went completely dead. Turns out it's this bug.

If anyone knows of a workaround please update the thread:
http://forums.mozillazine.org/viewtopic.php?f=29&t=1442365

Meanwhile I've added the workaround from rkent, although the real fix would be helpful, I'm trying to make a video to show adding a filter to move mailing list messages and ones with attachments around.

Thunderbird 3.01

Comment 5

[Bitter, Lemon]

whoops, I made a small mistake. That [Attachment Status] criteria only appears when selecting ...(after classification).... It has nothing to do with a filter for Local Folders vs. the POP account.

This dependency shows that the Attachment filtering will never work without the workaround above from rkent or a fix, because these filters I am testing also always require a custom mail header [List-ID].

Thanks for the workaround rkent. I'm going to go give it a test-drive now. Whew!

Comment 6

[Kent James (:rkent)]

Just a warning about attachment status in filters. We really do not process emails through a full MIME processor prior to hitting the filters, so the attachment status is set simply based on the content type of the email, which is not completely accurate. This really has nothing to do with pre- or post- classification by the way. For subtle reasons we ended up allowing the "attachment" term for the post classification filters, but in retrospect perhaps we shouldn't have. In particular, you should not use this filter for some security use where the sender is trying to trick you, such as quarantining possible virus emails.

Comment 7

[Bitter, Lemon]

In case this wasn't clear from my comments, the (after classification) fails to filter messages when automatically received on a timer-basis. I need to Tools, Run Filters on Folder manually as a workaround to 'clear out' the Inbox folder.

Comment 8

[Bitter, Lemon]

The not moving the message (failure of the filter) after reception when using the (after classification)-type filter, seems to yet be an issue.

20100306 Shredder/3.0.4pre

Messages arrive to the Inbox, and don't sort into Local Folders, until I manually click Tools, Run message filters on folder.