I’d just edit the .procmailrc directly. The functionality of the filters in the panel is fairly limited for a few reasons:
The more complex filters we allow and the more “special cases” we have to allow for, the more difficult it is to make sure the filter rules will be written correctly. Writing this sort of thing in a way which makes it “idiotproof” is a lot more difficult than it might seem.
The more we allow people to use wildcards, the more chance of someone writing a rule without really understanding what they’re doing (I see this happen a lot already), and accidentally deleting wanted mail, or at least writing rules that contain redundant wildcards. This can all happen, of course, if a user is writing their own procmail recipes, but at least then we can say “hey - sorry - not our fault”, and one hopes that the main people who would be doing this would be people who are at least somewhat tech savvy.
As a side note, < and > can probably be allowed; I’d have to look into it, but I think as long as they’re not preceded by a backslash, procmail will interpret them correctly. You can send a support message about this if you want.
I think that if you want to do anything complicated with filtering, it’s probably worth the effort to learn the basics of procmail (or maildrop), so that you can write your own recipes. There are some links in the kbase article on procmail which may help you get started (and hopefully avoid some common pitfalls). Also, you can always create the filters you want, and then copy our .procmailrc, delete the filters from the panel, and use our file as a starting point.
I usually explain to people that the filters in the panel provide “sledgehammer” like functionality; they’re provided to deal with simple problems that most people may run into… A sledgehammer is very useful for certain tasks, but there are obviously cases where an exacto knife or a scalpel will be much more useful. Incidentally, one thing which you really want to avoid is writing filters through the panel which go to /dev/null, at least without a good month or two of advance testing.
Hope this helps.
 The two errors I see users make most often are using redundant “."s (a trailing ".” is always redundant, for example), and not escaping literal periods (i.e., using example.com instead of example.com - an unescaped dot matches any character, not a literal “.”).
So something like:
(a .* isn’t needed after the ^TO, because ^TO and ^TO_ are special cases - see the procmailrc (5) man page for more info)