Postfix postmap header_checks warnings

Question

I have the following postfix header_checks and they have worked well for years:

/^Date: .* 21.*/ REJECT Your email has a date from the far future. Fix your system clock and try again.
/^Date: .* 20[3.*].*/ REJECT Your email has a date from the far future. Fix your system clock and try again.
/^Date: .* 20[2][5-9]/ REJECT Your email has a date from the future. Fix your system clock and try again.
/^Date: .* 20[2][0-3]/ REJECT Your email has a date from the past. Fix your system clock and try again.
/^Date: .* 20[1][0-9]/ REJECT Your email has a date from the past. Fix your system clock and try again.
/^Date: .* 200[0-9]/ REJECT Your email has a date from the past. Fix your system clock and try again.
/^Date: .* 19[0-9][0-9]/ REJECT Your email has a date from the past. Fix your system clock and try again.

I get the following warnings when I run postmap hash://... with the file:

postmap: warning: //etc/postfix/header_checks, line 1: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks, line 2: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks, line 3: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks.db: duplicate entry: "/^date:"
postmap: warning: //etc/postfix/header_checks, line 4: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks.db: duplicate entry: "/^date:"
postmap: warning: //etc/postfix/header_checks, line 5: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks.db: duplicate entry: "/^date:"
postmap: warning: //etc/postfix/header_checks, line 6: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks.db: duplicate entry: "/^date:"
postmap: warning: //etc/postfix/header_checks, line 7: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks.db: duplicate entry: "/^date:"
postmap: warning: //etc/postfix/header_checks, line 8: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks.db: duplicate entry: "/^date:"
postmap: warning: //etc/postfix/header_checks, line 9: record is in "key: value" format; is this an alias file?
postmap: warning: //etc/postfix/header_checks, line 10: record is in "key: value" format; is this an alias file?

It seems to work, but I am always cautious with regard to warning on duplicates and this "key value" format warnings.

Any ideas on if these should work to filter out unwanted date-based timestamps? I've never had a problem, but I noticed more 21* messages lately (and some 1969 messages, which makes no sense except for the fact that you can tell the system to use a time before epoch and usually indicates a more insidious error in the timestamp).

Or ... is there a better way to wrap the date stamps to prevent useless spam from previous or post eras?

Answer 1

You are trying to generate the hashed .db Berkeley DB on a file that does not contain indexed tables but regular expressions. Hence, it complains about incorrectly formatted files and duplicate entries, although it guesses wrong and suggest key:value just because /^Date: has an : in it.

Take a look at Postfix lookup table types, more specifically:

hash
An indexed file type based on hashing. This is available only on systems with support for Berkeley DB databases. Public database files are created with the postmap(1) or postalias(1) command, and private databases are maintained by Postfix daemons. The database name as used in hash:table is the database file name without the .db suffix.

pcre (read-only)
A lookup table based on Perl Compatible Regular Expressions. The file format is described in pcre_table(5). The lookup table name as used in pcre:table is the name of the regular expression file.

It works because you have header_checks = pcre:/etc/postfix/header_checks in your configuration. The pcre: does not read the header_checks.db file, and the header_checks file is left intact by postmap.

---

As a side note, using hard-coded dates in rules like this tends to fail. The /^Date: .* 20[2][5-9]/ will be forgotten there, and starting from January 1, 2025 every message gets rejected as a message from the future. As a a short history lesson, SpamAssassin had Y2K10 Rule Bug in January 2010 when the rule FH_DATE_PAST_20XX relied on hard coded dates.