Dovecot Sieve and Postfix header_checks Issue

[Alex Crow]

On 26/09/14 15:27, Klaipedaville on Google wrote:
>> /^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.
So why does it state in man 5 regexp_table that such tables are *case 
insensitive* by default and the /i actually toggles that? Are you saying 
that man page is wrong? I'd be surprised as I don't think I've yet come 
across an occasion where postfix man pages are incorrect!

>
>> 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.
>
>

So if the regexes were all correct, then:

a) what was your actual problem once you identified it

and

b) for the benefit of the list, how did you actually solve it?

Alex

-- 
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
"Transact" is operated by Integrated Financial Arrangements plc. 29
Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300. (Registered office: as above; Registered in England and Wales
under number: 3727592). Authorised and regulated by the Financial
Conduct Authority (entered on the Financial Services Register; no. 190856).