Bug 54984 - additional filter matching choices
Summary: additional filter matching choices
Status: RESOLVED NOT A BUG
Alias: None
Product: kmail
Classification: Applications
Component: filtering (show other bugs)
Version: 1.5
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-21 20:02 UTC by Tom Emerson
Modified: 2007-09-14 12:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Emerson 2003-02-21 20:02:01 UTC
Version:           1.5 (using KDE 3.1.0)
Installed from:    SuSE
Compiler:          gcc version 3.2
OS:          Linux (i686) release 2.4.19-4GB

I have a few "wishlist" items for filter matching criteria [one of which duplicates an existing item]

1) a "true" condition -- this is trivial, but avoids "kludgy" looking match criteria such as "size > 1" 
1a) an alternate would be a "pre-filter" action -- this would be primarilly in support of external programs such as spamassassin, but I have some other uses in mind [more in a moment]
1b) "based on result of external program" [this is the duplicate, and basically another way of specifying (1a) ]

2) a "header doesn't exist" criteria -- this is kind of the converse to the above problem: when piping through external programs, they have the ability to add a header to indicate "something was done"; this would allow the creation of a rule to only perform the external process if the header isn't already there [avoids re-processing messages]

3) an enhanced "contains" to search a file of possible matches, rather than a single match.  This would allow for easier management of "killfile" type rules -- you add a line to a file to indicate "you do not want to see this" rather than continually update the "rule" [and as threads die their own natural deaths, you can trim the file of "old" items far easier than removing a single item from a list of several "match any" rules...]

4a) specifically for the sender/to headers, match against members of a "distribution list"
4b) match against an address-book criteria, specifically, the "categories" field.  This way, I can identify "friends and family" [for instance] by placing their address in the address book and setting a category of "family" for that address.  I can then place a "rule" to match against "from e-mail address contains-category x" to identify people who [generally] don't need to be spam-filtered [but might need to be virus-checked...]

Note that this last item can be done via the "pre-filter" idea, which is what I was alluding to earlier -- with a "prefilter action", I could write my own program to scan for e-mail addresses that are in particular dist. lists, in a given promote/kill file, or where their address in kaddressbook contains a given category and set an "I found it" header for the rest of the "match-if..." criteria to find and act upon
Comment 1 jos poortvliet 2003-09-06 23:43:21 UTC
esp 4b is much needed... if you recieve alot mails from alot ppl, you dont 
have to make >40 filters (and change them for every time an adress is changed) 
but just 1 filter, and only change in your adressbook.
Comment 2 Ingo Klöcker 2003-11-05 14:04:59 UTC
Sorry, but please re-submit your wishes one-per-bug-report. Else it's much too difficult for us to keep track of what's already there and what's still missing. Please check for duplicates before you re-submit your wishes.
ad 1) an empty rule is now (as of KMail 1.6 in KDE 3.2) treated as true
ad 2) use "some header" "doesn't match regular expression" "." (yes, I know that this isn't a good solution for normal users, so feel free to submit a wish for this one)
ad 3) that's only useful for power users and for power users this can easily be solved by the "external program for rule matching". So that's IMO a duplicate.
ad 4) extended wish to "addressbook contains" rule. So also a duplicate.