The first thing that needs to be done is to enable body checks in the Postfix main.cf configuration file. This will tell postfix where to look for the body checks file.
To do this, add the following line to the file:
body_checks = regexp:/etc/postfix/maps/body_checks
If you are using pcre instead of regexp, you will use:
body_checks = pcre:/etc/postfix/body_checks
The format for each line in the body_checks file is as follows:
The ACTION that will be taken has a number of options available:
REJECT is the most common, and this will cause the email to be rejected by Postfix. In this case, the incoming email will be blocked before it can enter your server. As an option, you can add text after the work REJECT, whereas that text will appear in both your log and the bounce message to the sender of the email. It is a good practice to number your lines in any checks file, as you may sometimes have difficulty identifying which rule caused a particular email to be rejected. A sample reject is as follows:
/Free Money/ REJECT Spam Body Rule #42
This will cause any email that has the words “Free Money” in the body to be rejected. The bounce message to the sender and your mail log will both have the text “Spam Body Rule #42” in them. This will allow you to more efficiently find what rule is causing problems or false rejects.
IGNORE will cause that particular header to be removed from the email, and will continue to process the email as normal. This can be useful in some situations. Please see the Header Removal Guide for more information.
WARN can be very useful when testing new spam filters. An entry will be made in your mail log with a warning on the header, as well as any text that you place after the word “WARN” like with REJECT. It is often advisable to test new filters for a day or two with WARN before implementing them in production. This especially applies to complex rules that could easily have errors.
HOLD will hold the email in a hold queue, so that the system administrator can later take action (delete or release the email).
DISCARD will cause the sending server to think that the email was sent properly, but your Postfix server will silently discard (delete) the email. This option is for instances where you don’t want the remote person or server to know that the email was deleted.
FILTER will allow you to specify another instance of postfix, filter, or server where to send the email. After the word FILTER, you will add an entry like in the transport map file of transport:nexthop. Please see the transport map documentation for more information.
Following are a few examples of body checks. Remember that when using alpha characters (letters) the line is not case sensitive. “WORDS” is considered the same as “words” or “Words”.
/Real Bad Words/ REJECT
This will reject any email that contains the phrase “real bad words” in any case (upper, lower, or mixed).
Spammers sometimes use “=20” instead of a space to separate words. This is because most email clients will display a “=20” as a space, even if they are not intending to display html or rich text encoded messages. This line will reject any email that uses four or more “=20” on one line. There may be some valid reasons to do so, but in our experience we have not come across any.
You can also use body checks to filter out some links to web sites. In the latest revision of our body checks file, there are a number of entries in the format of /www.badwebsite/ REJECT. This will reject any email that has that site listed. This can be beneficial when dealing with something that is obviously pornography, or something that you definitely don’t want to see, but some people may spam using an account at a real merchant, from whom you will want to receive information in the future. Like with all other spam filtration mechanisms and rules, please be certain that you want to implement a particular rule before moving into a production environment.
As you can see, body checks can be configured to block even the most obscenely strange methods that spammers use to try and get past spam filters.