I have the main.cf config:

header_checks = regexp:/etc/postfix/header_checks

And the /etc/postfix/header_checks:

/^Subject:.*viagra.*/i DISCARD
/^Subject:.*pills.*/i DISCARD
/^Subject:.*f\*ckbuddy.*/i DISCARD
/^Subject:.*f\*ckfriend.*/i DISCARD
/^Subject:.*f\@ck.*/i DISCARD

/^From:.*viagra.*/i DISCARD

Notice I have added the /i to make case insensitive. Not sure if it allows this?

I have tried sending emails from a hotmail to my server with pills in the subject but still no luck! Also is there a return to sender method instead of DISCARD?


If postmap -q "<put test header here>" regexp:/etc/postfix/header_checks is correctly returning DISCARD (or the appropriate action for the match) but postfix is not actually performing said action, then there is probably a receive_override_options=no_header_body_checks somewhere in main.cf or master.cf that is turning off the header checks. In the master.cf file, it would be a -o option in one of the service configuration entries.

There are 4 options for receive_override_options:

  • no_unknown_recipient_checks Do not try to reject unknown recipients (SMTP server only). This is typically specified AFTER an external content filter.
  • no_address_mappings Disable canonical address mapping, virtual alias map expansion, address masquerading, and automatic BCC (blind carbon-copy) recipients. This is typically specified BEFORE an external content filter.
  • no_header_body_checks Disable header/body_checks. This is typically specified AFTER an external content filter.
  • no_milters Disable Milter (mail filter) applications. This is typically specified AFTER an external content filter.

The no_address_mappings options will typically be located in main.cf while the other options, in master.cf

The "-o receive_override_options" overrides main.cf settings to avoid duplicating work that was already done before the content filter. These options are complementary to the options that are specified in main.cf

Source: Postfix After-Queue Content Filter

  • regex: and pcre: patterns are case-insensitive by default. However, the i flag should work.
  • You can use REJECT instead of DISCARD to inform the sender.
  • Did you use postmap /etc/postfix/header_checks and reloaded postfix?
  • You can test regexes online at many sites. http://www.pagecolumn.com/tool/pregtest.htm allows POSIX regexes.
  • If available, using pcre regexes is usually faster then using the Posix implementation with regexp:. Use header_checks = pcre:/etc/postfix/header_checks

  • What are the log files saying?

  • 2
    The postmap is not needed for pcre, but a postfix reload – Dom Oct 1 '16 at 18:40

As @HZC says it could be an -o receive_override_options issue. I had the same problem here: My issue and solved it following the post postfix header_checks using regexp proper setup. My case was a REJECT instead DISCARD. You use DISCARD in case you want to cheat spammer, the spammer won't receive any notification. For more info about this you can visit this link and see the REJECTS ACTIONS section.

DISCARD estructure:

              DISCARD optional text...
              Claim successful delivery and silently discard the message.  Log
              the optional text if specified, otherwise log a generic message.

In the header_checks(5) manual page, there is this paragraph which says that for a while now the default for all regular expressions is to view them as case insensitive:

      With Postfix version 2.2 and earlier specify "postmap -fq" to query a table that contains case sensitive patterns. By default, regexp: and pcre: patterns are case insensitive.

So adding a flag to your regular expression would not fix your problem.

As others have mentioned, your first step is to verify that it works with a:

postmap -q "<string to test--i.e. Subject: Viagra>" /etc/postfix/header_checks.re

The output is going to be the action for the line. (DISCARD in your case)

If that works, you may be missing the line to include the header or a line that prevents the inclusion as others have mentioned.

header_checks = regexp:/etc/postfix/header_checks.re

Since you say you have that line there, the latter much be the problem.

Note that I have a .re extension. I don't think that matters, but it may be a good idea to have some kind of extension to know what the file contains.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.