RoundCube Development Team;

im offering this message filtering system as an idea for roundcube, and does not have to be used by any means. this could use several kicks in a live chat to sharpen its edges, etc if ever considered. i find roundcube to THE best webmail frontend around, and figured it could use a better then normal cheesy filtering system.

this proposel is also available at: http://plastik.us/txt/rmf.txt

• Zachery Hostens roundcube@plastik.us

Ruleset Message Filtering System By: Zachery Hostens rmf@plastik.com Last Modified: 2005.11.10 17:42 (EST)

this is a propesed message filtering system. i designed this cause i was sick and tired of the generic, annoying filtering every mail system has grown to use over the years. if i ever find the time i may implement this as a stand alone application much like procmail or maildrop. ideas may or may have not been inspired from outside sources. later on ill add credits.

• Message Filtering Heirarchy

instead of giving users a generic filter name, AND|OR option, for a few generic matching schemes, give them more of a ruleset, like a firewall. this will allow for more active filtering (not something you hate to think about doing in your mail client) and a more simplistic look into filtering (albiet not at first.)

• Design

this is more of a simplistic overview of how i feel filtering rulesets should look and in no way how it will be implemented, (yet.)

• Rule Structure

[OR] [!]Command|Header ["string-match"] [Mailbox] [children]

OR: optional OR (||), default is 'AND' except for root filters. this is still a scetchy subject on its use/purpose in this type of filtering

!: negate the match.

Command|Header: required 'actions' or matching requests. commands could probably even grow to do more then planned, aidful things.

string-match: required depending on the command. if one is given for a command that doesnt take one then the string is just silently 'dropped' (ignored)

command examples:

To "someone@domain.com" - match mail thats destined for said user Subject "*(weekly|daily|monthly)*" - match subjects containing 'weekly' or 'daily' etc Mailbox(INBOX) - 'true' of said mailbox exists this comes useful later on

Mailbox: optional destination (if not set then the parent's destination is used) if the final destination is not set, the rule is defined as a no-match and searching continues.

• Match Results

during match requests (To, From, Subject, etc) its possible to return matching variables to be used in a later set. at first i considered having different match requests return different results but leaning toward generic matching easier for the user and developer.

examples:

Delivery-To "(*)@(*).com" - example of possible mailing list seperation Mailbox "$2/$1" $2/$1 and deliver message to Domain/MailListName mailbox.

• Hierarchy Walking

searching for results. root filters are executed in sequential order until a filter is found matching WITH a destination. children filters are walked as the roots are, as well until a match WITH destination is found. if commands such as MatchChild (shown in the ruleset example below) would be expected to work, there must be a mechanism some how for the parent to know that a child has matched (even though there is no destination specified)

• Regular Expression Usage

the examples below use a rather 'crap' regular expression. in a production use id imagine using perl compatible regular expressions, which ill modify examples to match later. for examples note '*' would be the same as '*.' in perl. for perl compatible expressions. people would have to remember that stuff like: (com|net|org) would count as a matched result as well.

• Example Ruleset

this is a large example of a ruleset i'd use (or similar there to) for my email.

# system messages To "root@eclipse.plastik.us" Trash From "root@eclipse.plastik.us" System Subject "eclipse.plastik.us (daily|weekly|monthly)*" System/Cron From "*@eclipse.plastik.us" System/Users

# match domain names for mailing lists # we match lists.domain.com as well To "*@(lists.)?(*).*" Mailbox "List/$2" List/$2

# example non string-match command # matchchild is just an example command, but would be possible MatchChild Trash From "*@spamdomain.com" From "*@anotherspammer.com" From "evilman@big-corp.com"

# Match1 im not especially fond of. # maybe have like Command(param) "string-match" so you could go like # Match($1) "boss". but i dont know how far these parameters would extend

From "(*)@workdomain.com" Work

Match1 "bosses-name" Work/Boss Mailbox "Work/$1" Work/$1

none of these examples display the OR use. as at first i kinda felt they may be needed but the more i think about it, they way the rules are defined OR may be more of 'in the way' with the heirarchy manner of the rulesets. as well with commands like MatchChild really not needed.