> Thank you Wietse, Viktor, > > Learned something new today. > Even though I read the documentation regarding content filtering, it seems I > missed that part. > Will look for a complementary solution.
http://www.postfix.org/CONTENT_INSPECTION_README.html before queue, built-in, light-weight This method inspects mail BEFORE it is stored in the queue, and uses Postfix's built-in message header and message body inspection. Although the main purpose is to stop a specific flood of mail from worms or viruses, it is also useful to block a flood of bounced junk email and email notifications from virus detection systems. The built-in regular expressions are not meant to implement general SPAM and virus detection. For that, you should use one of the content inspection methods described below. Details are described in the BUILTIN_FILTER_README and BACKSCATTER_README documents. http://www.postfix.org/BUILTIN_FILTER_README.html Limitations of Postfix header/body checks Header/body checks do not decode message headers or message body content. For example, if text in the message body is BASE64 encoded (RFC 2045) then your regular expressions will have to match the BASE64 encoded form. Likewise, message headers with encoded non-ASCII characters (RFC 2047) need to be matched in their encoded form. Header/body checks cannot filter on a combination of message headers or body lines. Header/body checks examine content one message header at a time, or one message body line at a time, and cannot carry a decision over to the next message header or body line. Header/body checks cannot depend on the recipient of a message. One message can have multiple recipients, and all recipients of a message receive the same treatment. Workarounds have been proposed that involve selectively deferring some recipients of multi-recipient mail, but that results in poor SMTP performance and does not work for non-SMTP mail. Some sources of mail send the headers and content ahead of the recipient information. It would be inefficient to buffer up an entire message before deciding if it needs to be filtered, and it would be clumsy to filter mail and to buffer up all the actions until it is known whether those actions need to be executed. Despite warnings, some people try to use the built-in filter feature for general junk email and/or virus blocking, using hundreds or even thousands of regular expressions. This can result in catastrophic performance failure. The symptoms are as follows: The cleanup(8) processes use up all available CPU time in order to process the regular expressions, and/or they use up all available memory so that the system begins to swap. This slows down all incoming mail deliveries. As Postfix needs more and more time to receive an email message, the number of simultaneous SMTP sessions increases to the point that the SMTP server process limit is reached. While all SMTP server processes are waiting for the cleanup(8) servers to finish, new SMTP clients have to wait until an SMTP server process becomes available. This causes mail deliveries to time out before they have even begun. The remedy for this type of performance problem is simple: don't use header/body checks for general junk email and/or virus blocking, and don't filter mail before it is queued. When performance is a concern, use an external content filter that runs after mail is queued, as described in the FILTER_README document. Wietse
