> /^Subject:.**{5}SPAM*{5}/ REJECT No spammers allowed here.
> /^Subject:.*\*\*\*\*\*SPAM\*\*\*\*\*/ REJECT No spammers allowed.
> /\s**{5}SPAM*{5}/ REJECT No spamming
> hullababballos allowed.
>I think it may be this one above. From the postfix manuals"By default,
>matching is case-insensitive, and newlines are not treated as special
>characters. The behavior is controlled by flags, which are toggled by
>appending one or more of the following characters after the pattern: *i*
>(default: on) Toggles the case sensitivity flag. By default, matching is case
>insensitive."
Case insensitive is declared by putting this /i at the end of a rule.
Postfix has nothing to do with regular expressions (regexp) and regexp is not
controlled by postfix. There should be a regexp library available on the server
where you are using regexp. It’s like PHP, or tml, or js, or css, it cannot be
controlled by postfix.
>And it looks like * needs escaping there too (if you're trying to match
>exactly 5 asterisks, you should probably do "\*{5}" not just *{5}.
Yes, the escape character in front \*{5} to match 5 asterisks is the correct
one. You are right. I am an expert on regexp and this (incorrect one) was there
just for testing purposes because there was a problem with the library on the
server so I had this bad rule over there to follow up on error in logs. The
library has been fixed by now and as I said earlier execution stops on the
first rule matched but does not really do any harm if there is a mistake in the
rule, in this 'mistake' case the rule is simply skipped.
> /^Subject:(.*)SPAM/ REJECT Spam is not allowed. DISCARD.
> were causing the Dovecot Sieve rejection bounce not to go through. The rules
> blocked the spam all right but rejection was turned into discard for some
> reason. Now the question is how do I find out which regular >expressions will
> be in conflict with default.sieve scripting rules?
>That's just about learning Posix Regex syntax.
All the rules are 100% correct as there is a very simple and useful tool in
postfix to check if regexp is correct. The tool can be used even by people who
don't have a foggiest idea how regexp work. All you have to do is to type on a
command line this postmap -q "Subject: *****SPAM***** blablablabla"
regexp:/etc/postfix/header_checks or this postmap -q "X-Spam-Flag: YES"
regexp:/etc/postfix/header_checks and it will tell you if your rule is correct
or not. It is bullet and fool proof system with 100% guarantee. All these rules
have been checked like that despite the fact that I know for a fact that they
are correct by my own knowledge and experience.
>I'm almost 100% sure that that regex also matched the bounce from your sieve
>rules. There is no mysterious interaction between header_checks and sieve
>rules, it's just your pattern was too liberal in the former.
No, no. The regex could not have matched the bounce from my own rules because
it would be silly to send a test message from the same server that would loop
back and block myself by my own rules. I sent test messages from another
server's accounts. Plus, there is a difference. Header_checks in Postfix use
only customized rules that do not involve any Spamassassin's added headers. Now
in my case only Dovecot Sieve goes through Spamassassin headers because as
mentioned earlier I passed delivery from Postfix to dovecot LDA in my
configuration. That's why everything that has Spamassassin's headers and tags
added has to be configured via default.sieve scripting and everything else
(that do not get Spamassassin's headers added) may use header_checks of
Postfix. I have just figured that out by runnning quite a few different and
simple tests.
>I think if you tune that header_checks file correctly you should have no more
>issues.
The header_check rules are fine tuned to their best.
Anyway, I am thankful for your suggestion as it pointed me to the right
direction. Then I picked it up and simply followed onwards by elaborating and
building on top which led me to a solved problem Thank you.
