418620 - Filter enhancement: combine ANDs and ORs for filtering rules

Status: RESOLVED DUPLICATE of bug 297852

(Thunderbird :: General, enhancement)

Description

[Antonio Freixas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: version 2.0.0.9 (20071031)

When defining a filter, I can choose to "Match all of the following" or "Match any of the following". These are equivalent to ANDing or ORing, respectively, the matching rules for the filter.

I use POPFile to add an X-Text-Classification header to my e-mail. POPFile seems to do a better job of identifying spam than your junk mail algorithm. 

These days, I'm starting to see spam counts of 100+ messages in a few hours. I review all spam message headers before deleting the messages to ensure that I don't miss out on an important e-mail.

It occurred to me that I could delete POPFile identified spam containing certain keywords. For instance, if POPFile says the message is spam and the subject line contains the string "viagra", it's probably safe to delete. There are many other keywords that would be nice to use.

So I would like to create a filter that says IF POPFile marks this as spam AND (the subject line contains viagra OR the subject line contains VPXL or ...) THEN delete the message. 

I can't see any way of doing this short of creating one new filter rule for each keyword I want to use. There isn't even an option for duplicating an existing filter so as to make the task easier.

Adding regular expression support would be one solution (at least, for those of use who know how to use them) since RE's allow ORing. Adding a UI that permits ANDing and ORing would solve the problem for more people. Adding an option to duplicate existing filters would help.

Here's one way of enhancing the UI. Currently, you have a set of controls "For incoming messages that:". Let's call this the match block. If you allowed users to create more than one match block and if each match block was ANDed with all others, then you would get a lot more flexibility with only a little more coding.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 2

[zug_treno]

(In reply to comment #0)
> Adding regular expression support would be one solution (at least, for those of
> use who know how to use them) since RE's allow ORing. 

Duplicate of Core bug 19442?

> Adding an option to
> duplicate existing filters would help.

Duplicate of Core bug 214548.

Comment 3

[Antonio Freixas]

I'd be happier if duplicates were assigned because the problem was the same rather than that the solution was the same. For instance, this bug is now marked as a duplicate of bug 274192. Comment #2 states that it is also a duplicate of 214548 and a possible duplicate of 19442. Standard logic would then lead us to say that bug 274192 is also a duplicate of bug 214548 (which it isn't) and bug 19442 (which actually would be one solution for bug 274192).

In addition, we normally want one bug or enhancement per bug report. I listed one enhancement request that has multiple solutions. Being marked as a duplicate of bugs that aren't duplicates of each other implies that more than one "bug" was reported.

Finally, when solutions dictate when bugs are duplicates, fixing one bug resolves the duplicates without any review of whether that solution was actually the best solution for the original problem.

My preference would be to leave this enhancement as not a duplicate (I haven't found anyone else asking for the same thing) and create an association to bugs whose solutions may also resolve this enhancement request. Ideally, this would be a bugzilla field. Less ideally, it would be noted in the comments field.