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