Section: File Format Descriptions (5)
Updated: September 2004Index
murxex - Murx configuration file examples
For a description of the rcfile format and its keywords see the murxrc
(5) manpage or get a basic set of options from the examples/ directory of the Murxdistribution.
This man page contains several configuration examples and real-life use casesfor the Murx program.
The following examples assume you are familiar in using (extended) regularexpressions. General information on regular expressions can be found in theregex
(7) man page or in any good book on UNIX/POSIX. You could also useslightly modified examples from procmail
(1) if it is available on your system.
To create a very restrictive set of filter rules at least two keywords shouldbe used: ALLOW and DENY. DENY could match all messages coming from an annoyingpublic mail service, while ALLOW matches messages from a good friend who alsouses this annoying public mailer.
- DENY = "^From:.*public-mail\.com"
ALLOW = "^From:.*friendAATTpublic-mail\.com"
These two lines are enough to block all but your friend's e-mail from thepublic-mail.com domain.
In general case-sensivity is controlled by the IGNORE_CASE keyword. HavingMurx treat expressions case-insensitive is almost always more efficient.
- IGNORE_CASE = "yes"
DENY = "^Subject:.*win money"
In this example Murx would delete all messages with subject lines like`WIN MONEY', `Win Money' or any other mix of capital and non-capitalcharacters. IGNORE_CASE makes filters ignore the case.
A more complex set up can be achieved by additionally using the CASE keyword.
- DENY CASE = "^Subject:.*BUSINESS"
In this example only e-mails that have `BUSINESS' in their subject match thefilter, even though in general Murx ignores the case. So in this exampleall messages with `business' or `Business' in their subjects would not beaffected by this filter.
Such an option is very useful if you are not interested in commercial bulk mailthat offers amazing business opportunities, but in all your business partnerswho contact you by e-mail.
The keyword ALLOW can be used to override any spam filters. Similar to theearlier example ALLOW defines a `friend'. Normally it is useful andmore secure to use case indenpendant rules.
- ALLOW NOCASE = "^From:.*some.friendAATTexample.com"
ALLOW = "^Subject:.*murx"
Adding the last rule to the rcfile would mean all messages thatcontain anything about Murx in their subject lines can pass the spamfilters. But even friends tend to send large e-mails sometimes toshare their joy about the latest joke that just made the round intheir office. In such cases a limit can be defined that affectsparticularly `friends'.
- MAXSIZE_ALLOW = 500000
Setting MAXSIZE_ALLOW to 500000 means no message can be larger than 500kBytes. (Scanned `office-jokes' are usually around that size.)
If you know your `special friends' by name it could be a good idea to defineonly locally size-dependant ALLOW rule like this:
SIZE < 500000
This filter would match any mail from your `special friend' with a mail sizenot greater than 500000. The mail is allowed if the mail size is lessthan 500000 Byte. If the mail size supercedes this value the mailcould be deleted by a limit set via MAXSIZE_DENY because the ALLOWfilter does not match.
Negative Message Filters
In order to create a very restrictive spam protection it can be more usefulsometimes to define which e-mails should not be deleted instantly andconsequently get rid of messages that can not be matched to this criterion -rather than vice versa. This can be achieved by using negation. The typicaluse case is looking at the message tags `To:' or `Cc:' of an e-mail.
- DENY <> "^(To|Cc):.*my-emailAATTaddress\.com"
Having added such a filter to your personal rule set keeps away a lot of spamthat is not directly addressed to your e-mail account. Mails send via Bccusually don't match this criteria. Since this is a very aggressive way offiltering, you are well advised to keep your `friends list' up to date.
Instead of setting up spam filters, it is also possible to define scoreswhich can be accumulated until a certain threshold is reached. This is veryuseful to delete advertisements on mailing lists, for instance. Highscoremarks the threshold:
- HIGHSCORE = 100
SCORE +100 = "^Subject:.*viagra"
SCORE +100 = "^Content-Type:.*html"
SCORE -100 = "^(To|From):.*my_mailing_list"
This simple example is useful to delete mails with a score greater than 100,i.e. if someone sends an HTML mail to my_mailing_list, the message willreach score 0. However, should an HTML mail regarding Viagra reach the list,then the message will classify as spam, because it reached an overall scoreof 100.
The SIZE keyword can be used to add to the accumulated score foran e-mail. The following will cause all emails not directly addressed to therecipient and greater than 60000 bytes in size to be deleted (a useful way ofrejecting many common MS targeted worms and trojans which can clog up yourinbox).
- HIGHSCORE = 100
SCORE +50 SIZE > 60000
SCORE +50 <> "^(To|Cc):.*my-emailAATTaddress\.com"
This is a less aggressive way of dealing with e-mail sizes than the using theMAXSIZE_DENY keyword. Note that this example (by using the expression (To|Cc):.*my-emailAATTaddress\.com) works only with extended regular expressions.
The above rules can also be combined in one filter using an AND block:
- HIGHSCORE = 100
SIZE > 60000
In this case the score of 100 is added to mails matching both criteria while inthe example above every mail which exceeds a size of 60000 would get a score of50.
Filtering in body lines
Sometimes it is not enough just to check the header lines (especially thesubject line) for typical spam detection. Murx has the possibility to get alsoa defined amount of body lines of each message to scan for keywords. The amountis defined via the BODYLINES keyword like:
- BODYLINES = 10
A filter with rules for body lines looks like already described above with apreceeding BODY before the rule, e.g.
BODY NOCASE = "v.agra"
The above filter searches for some variants of the Wort viagra (v1agra, v|agra,etc.) but only in body lines of the messages. The message score is increased by100 each time a body line with such variant is detected. Depending on the valueset for BODYLINES above, only the first 10 lines of the message body arechecked.
General Message Size Limits
It is always a good idea to define a very general size limit for e-mails.Murx uses the keyword MAXSIZE_DENY for that purpose.
- MAXSIZE_DENY = 200000
Setting it to 200 kBytes can save you a couple of hours, depending on how muchmail you get everyday. Messages bigger than that get deleted on the server,unless they match any of the ALLOW rules. To achieve maximum efficiency itmakes sense to use both MAXSIZE_DENY and MAXSIZE_ALLOW. No one should block upyour mail box, no `friends', no others.
A rule of thumb is to be twice as tolerant towards friends than you are towardsanonymous people.
Dealing with Duplicates
Most people want to download a message only once, even though it might havebeen sent to two or three of their accounts at the same time. The simple line
- DELETE_DUPLICATES = "yes"
will take care of duplicates and makes sure that only one copy of a messagehas to be delivered.
Normalisation of Message Subjects
Every now and then some clever sales person comes up with the brilliant idea towrap spam in funny little characters. If you get a message with a subject linesimilar to this one `,L.E-G,A.L; ,C.A-B`L`E, .B-O`X`', then ordinary filterswould fail to detect the junk.
- NORMALIZE_SUBJECT = "yes"
Adding this directive to the rcfile tells Murx to `normalise' subjectstrings, i.e. leave in only the alpha-numeric characters and delete the rest.`,L.E-G,A.L; ,C.A-B`L`E, .B-O`X`' would then become `LEGAL CABLE BOX' whichcan easily be matched to a spam filter.
Note that Murx first tries to match the original subject string, beforeit checks on the normalised one.
Since Murx deletes e-mails remotely, before they have to be downloadedinto the local machine, it is also important to know what is going on while theprogram is being executed. The least you should do is define a proper level ofverbosity and a log file.
- LOGFILE = "$HOME/logs/murx-`date +\"%m-%y\"`"
LOGLEVEL = 3
Level three is the default verbosity level. Using it Murx reportsinformation on deleted messages, run-time errors and dates to the screen andthe log file.
You can use `command` to embed shell skripts into your path names. In theabove example it is used to store log files separately for each month andyear.
If you are new to regular expressions and new to Murx, you might want toexperiment a bit, before you accidently delete messages for real. For suchcases Murx provides two keywords. TEST can be used to only simulate thedeletion of messages and HEADERFILE stores all the e-mail headers that getexamined by the program.
- TEST = "yes"
HEADERFILE = "$HOME/logs/murx-headers.txt"
Use this setup if you are not yet comfortable with the concept of spamfiltering. It may help to understand regular expressions better and how to usethem. The keyword TEST can also be used in filters overriding the global value:
- TEST DENY = "new.filter"
This works with the keywords ALLOW, DENY, MOVETO and SCORE. The preceding TESTkeyword will lead to not executing the action i.e. in case of a match the mailwould not be allowed, denied, moved or get a score.
Copyright © 2004-2006 Kai Hildebrandt <kai.hildebrandtAATTweb.de>
Derived from the mailfilterex(5) manpage originally written by Andreas Bauer.
This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- Filtering Domains
- Case Sensivity
- Defining Friends
- Negative Message Filters
- Filtering in body lines
- General Message Size Limits
- Dealing with Duplicates
- Normalisation of Message Subjects
- Control Mechanism
- SEE ALSO
This document was created byman2html,using the manual pages.