Mail filters options crippled


Is there any work around (besides hacking .procmailrc) that would allow me to set To: based email filters that use wildcards. Currently the Admin Panel does not let me use * or < > characters. This effectively makes To: filters useless.

I can get it to match an exact email - but if there are multiple emails in the To: line or if the email uses 'Full Name ’ notation the filter does not work.

any ideas?


I’d just edit the .procmailrc directly. The functionality of the filters in the panel is fairly limited for a few reasons:

  1. 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.

  2. 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)[1]. 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.

[1] 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 instead of - an unescaped dot matches any character, not a literal “.”).

So something like:

[some stuff]

instead of:
[some stuff]

(a .* isn’t needed after the ^TO, because ^TO and ^TO_ are special cases - see the procmailrc (5) man page for more info)


What I am doing is deliviring mail to a user mailbox, and not a generic mailbox. The user mailbox has a procmail recipe file that allows me to match messages on more headers and with full regexp support. If I need the message to be delivered to another mailbox, I just forward to an alias for that mailbox using a recipe. The only problem is you won’t be able to use the web panel or mailboxes panels to alter the server filters anymore - make sure you set those up the way you want first then leave them alone and only work with the recipie file directly. Also you better read up on procmail recipies before trying this yourself as the difficulty level is pretty high (easy to mess up and lose mail or worse, too). Works for me but I’ve only done it for the one business e-mail address that gets posted on (other peoples) web sites so it gets mucho spam. If Razor doesn’t catch spam, then a filter that checks to see if the sender used the recipient’s name does.

It would be pretty nifty if the server filters could have modifers like “contains/begins with/ends with” and “does/does not”.

:cool: Perl / MySQL / HTML+CSS


I’m happy to edit the procmailrc - is this possible with mailboxes though?


Nope. You’d have to do this with “real” users.