On September 24, 2014 6:49:22 AM Webmaster wrote:
The requsted information simply does not exit.
Then the problem does not exit
not working
From: wie...@porcupine.org
To: Postfix users
CC: Re: header checks not working
> Wietse:
> If you still want help, post actual technical details:
>
> 1) non-verbose logging,
> 2) the "postconf -n" for the configuration that produced that logging,
> 3) the
> Wietse:
> If you still want help, post actual technical details:
>
> 1) non-verbose logging,
> 2) the "postconf -n" for the configuration that produced that logging,
> 3) the content of the email message that produced that logging,
> 3) any commands that you type in order to produce that logging
>If you still want help, post actual technical details:
>
>1) non-verbose logging,
>2) the "postconf -n" for the configuration that produced that logging
>
>I also recommend http://www.postfix.org/DEBUG_README.html#mail
>
>Then, someone may be able to see what mistake you are making.
>
If you still want help, post actual technical details:
1) non-verbose logging,
2) the "postconf -n" for the configuration that produced that logging,
3) the content of the email message that produced that logging,
3) any commands that you type in order to produce that logging,
4) any commands that
>quote author="li...@rhsoft.net"
>since you still have not solved your issue:
>if you would have used "spamass-milter" from the very begin
>besides the before-queue filtering you would not need to
>mangle around in postfix configurations to drop messages
I have by now tried it with milters = no j
Am 12.09.2014 um 11:29 schrieb Den:
>> run the spamfilter after queue
>> http://www.postfix.org/MILTER_README.html
>
> Thanks. Will double-check on that. Chances also are that I missed something
> too or I might as well have to try to switch to these milters as running SA
> daemonized doesn't wor
On Fri, Sep 12, 2014 at 10:12:38PM -0700, Den wrote:
> I was just wondering what exactly does the line below do? Could anybody
> comment / advise, please? It does not actually check and *confirm* that the
> code, syntax, etc. of any regexp present in /filter/ (example) is 100%
> correct does it?
>
Hello there Postfix experts!
I was just wondering what exactly does the line below do? Could anybody
comment / advise, please? It does not actually check and *confirm* that the
code, syntax, etc. of any regexp present in /filter/ (example) is 100%
correct does it?
postmap -q "/^Subject:.*\*{5}SP
>quote author="li...@rhsoft.net"
>
>SA default is
>rewrite_header Subject [SPAM]
>
>why don't you just stick with defaults and after all...
Postfix version 2.9.6. My SA 3.3.2 (2011-06-06) default says rewrite_header
Subject *SPAM* and I do stick to its defaults.
On the other hand there is
Am 12.09.2014 um 14:53 schrieb Den:
>> "li...@rhsoft.net"
>> no but the regexp is entirely wrong
>>
>> the subject starts with [SPAM] so no need for .*
>> {5} - what is that supposed to do?
>> avoid a * in the action for safety
>>
>> /^Subject: \[SPAM.*/ DISCARD SPAM
>
> Strongly disagree. Regex
>"li...@rhsoft.net"
>no but the regexp is entirely wrong
>
> the subject starts with [SPAM] so no need for .*
>{5} - what is that supposed to do?
>avoid a * in the action for safety
>
>/^Subject: \[SPAM.*/ DISCARD SPAM
Strongly disagree. Regexp is 100% correct because:
1. postmap -q "/^Subject:.
Den:
> Does it work successively as PHP does?
Postfix works as documented in regexp_table(5) and pcre_table(5),
i.e. each query stops at the first matching rule.
Postfix also works as documented in header_checks(5), i.e. DISCARD
causes Postfix to ignore the remainder of the message.
> Then my be
Am 12.09.2014 um 14:23 schrieb Den:
> /^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
> /^Subject:/WARN
>
> that is without having anything before discard*spam*. Is that correct?
>
> I also begin to think that there is a regexp issue somewhere. Is it actually
> poss
Wietse:
> /^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
>
>Please look for warnings like the following in your maillog file:
>
>postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line
1: unknown regexp >option "D": skipping this rule
>
> Wietse
Thank you. I will try it and go
Den:
> /^Subject:.*\*{5}SPAM\*{5}/DISCARD *SPAM*
PLease look for warnings like the following in your maillog file:
postfix/cleanup[2632]: warning: regexp map /etc/postfix/header_checks, line 1:
unknown regexp option "D": skipping this rule
Wietse
>you have 3 processes as part of the game:
>
>* spamd running as daemon and listening on TCP
>* spamass-milter running as deamon and listening on a unix socket
>* postfix talks to spamass-milter via the socket
>* spamass-milter takls to spamd via TCP
>* spamd has prefroking childs for the scanning
Am 12.09.2014 um 11:29 schrieb Den:
>> run the spamfilter after queue
>> http://www.postfix.org/MILTER_README.html
>
> Thanks. Will double-check on that. Chances also are that I missed something
> too or I might as well have to try to switch to these milters as running SA
> daemonized doesn't wor
>run the spamfilter after queue
>http://www.postfix.org/MILTER_README.html
Thanks. Will double-check on that. Chances also are that I missed something
too or I might as well have to try to switch to these milters as running SA
daemonized doesn't work. I posted my main.cf and my master.cf a bit ear
Wietse:
>You can expose the on-the-wire form with a header_checks rule:
>
>/^Subject:/ WARN
>
>That will log each header.
>
> Wietse
>
Could you please, elaborate a little further how to put it to work in
practice? Looks like it works successively and any rule that goes after
/^Subject:/
Am 12.09.2014 um 10:13 schrieb Den:
>> in context of "the spam detector" you need to name it
>> "GTUBE not supported by postfix filters" makes no sense without naming the
> filter
>
> Right. It's spamassassin. Thanks.
>
>> don't do that - depending on...
>
> I am not sure I follow. Don't do w
>in context of "the spam detector" you need to name it
>"GTUBE not supported by postfix filters" makes no sense without naming the
filter
Right. It's spamassassin. Thanks.
>don't do that - depending on...
I am not sure I follow. Don't do what? I am saying here that my header
checks do not wor
Am 12.09.2014 um 09:21 schrieb Den:
> Hello there again Michael,
>
> I think you "nailed" my issue.
>
> Let me quote a little from documentation of GTUBE for clearance. It stands
> for Generic Test for Unsolicited Bulk Email. /quote,/ "It's been agreed upon
> a single string of characters that s
Hello there again Michael,
I think you "nailed" my issue.
Let me quote a little from documentation of GTUBE for clearance. It stands
for Generic Test for Unsolicited Bulk Email. /quote,/ "It's been agreed upon
a single string of characters that should always set off any spam detectors.
The GTUBE
Viktor:
>Depending on your locale and MUA, subjects are sometimes encoded
>using either Quoted Printable or Base64 encoding. What you see
>on the screen may differ from the subject header on the wire.
>Header checks is a crude mechanism, that only deals with raw
>wire-form data.
Good point.
Right, Michael.
Thank you for bringing this up and I really do appreciate your feedback.
I'll try to test this string with all the headers, not just my subject
field. Not sure it may get me somewhere though.
However, I think no matter what I put in my subject field or in the body
field the header
> It would be real kind of you
> if you could put the following into your subject field:
If you are going to refer to the GTUBE, best to just cite it by NAME, or
include an URL like:
http://spamassassin.apache.org/gtube/
Actually including it in a message is ... unwise.
Why is left as an exerci
tests to see
how it works when simplified to the very minimum then will start building on
top of that, making it more complex step by step...
Regards,
Dennis.
-Original Message-
From: "Wietse Venema [via Postfix]"
To: Den
Sent: Fri, 12 Sep 2014 0:21
Subject: Re: header check
Den:
> I have a feeling that my subject line is a problem because much simpler
> header checks that contain only two or three simple dictionary words work
> just fine. Therefore I was also wondering if anyone who runs reject,
What text editor are you using? If it is any kind of word processor
soft
On Thu, Sep 11, 2014 at 10:47:09AM -0700, Den wrote:
> That's right Viktor. Your are absolutely right.
>
> The correct line is header_checks = regexp:/etc/postfix/spamdiscard
>
> and running this: postmap -q "X-Spam-Flag: YES/"
> regexp:/etc/postfix/spamdiscard
>
> returns no errors.
>
> The
That's right Viktor. Your are absolutely right.
The correct line is header_checks = regexp:/etc/postfix/spamdiscard
and running this: postmap -q "X-Spam-Flag: YES/"
regexp:/etc/postfix/spamdiscard
returns no errors.
The postmap -q "X-Spam-Flag: YES/" regexp:/etc/postfix/filter
is a typo as I
On Thu, Sep 11, 2014 at 10:20:06AM -0700, Den wrote:
> header_checks = regexp:/etc/postfix/spamdiscard
So this is is the actual setting.
On Thu, Sep 11, 2014 at 09:24:38AM -0700, Den wrote:
> header_checks = regexp:/etc/postfix/filter
And this is not.
On Thu, Sep 11, 2014 at 08:24:40AM -0700,
Hello Wietse and Viktor,
OK. Let me post the postconf -n with just one domain name I am fine to
disclose. Hope it will help. Thank you so much for your fast replies.
Appreciate your taking part in troubleshooting my problem...
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_myd
Den:
> Hello Viktor,
>
> Thank you for your message.
>
> It is my functional, active, and fully operational main.cf that has been
> working perfectly fine. The only thing removed for privacy / security
> reasons was a big list of actual domain names hosted on this server. Not
> sure if it is real
Hello Viktor,
Thank you for your message.
It is my functional, active, and fully operational main.cf that has been
working perfectly fine. The only thing removed for privacy / security
reasons was a big list of actual domain names hosted on this server. Not
sure if it is really needed to know the
Den:
> Hello again Wietse,
>
> Here goes my main.cf. There is no
> "receive_override_options=no_header_body_checks"
> anywhere here as well. Would be absolutely and genuinely thankful for any
> suggestions...
>
> # See /usr/share/postfix/main.cf.dist for a commented, more complete version
>
>
On Thu, Sep 11, 2014 at 09:24:38AM -0700, Den wrote:
Do not post main.cf files. Rather, post or attach output of
"postconf -n" that is not line-wrapped after cut/paste, you
need to post it with the original line-breaks preserved.
> # Debian specific: Specifying a file name will cause the first
Hello again Wietse,
Here goes my main.cf. There is no
"receive_override_options=no_header_body_checks"
anywhere here as well. Would be absolutely and genuinely thankful for any
suggestions...
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Speci
Hello Wetsie,
That's a piece of cake.
My master.cf in full is below.
Would you like to see my main.cf?
receive_override_options=no_header_body_checks is not actually found in
main.cf as I selectively chose every single line in main.cf myself but I can
copy-paste it for clarity should that help
Den:
> I do not have any of these "receive_override_options=no_header_body_checks"
> in my master.cf or any other places anywhere.
Prove it.
Wietse
On Wed, 01 Jul 2009, Magnus Bäck wrote:
> > Sahil Tandon wrote:
> >
> > > I prefer pcre:, but the following patterns should work with regexp:
> > > as well.
>
> No, {n} isn't supported by regexp.
It is. As noted in regexp_table(5), each pattern is a POSIX regular
expression, whose syntax is doc
On Wed, Jul 01, 2009 at 01:50:02PM -0700, Rob Brandt wrote:
>
>
> Jan P. Kessler wrote, On 7/1/2009 12:34 PM:
>>> Bingo:
>>>
>>> -o
>>> receive_override_options=no_header_body_checks,no_unknown_recipient_checks
>>>
>>>
>>> Any negative consequences for eliminating this line, or changing it to:
>>>
Jan P. Kessler wrote, On 7/1/2009 12:34 PM:
Bingo:
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks
Any negative consequences for eliminating this line, or changing it to:
-o receive_override_options=no_unknown_recipient_checks
header_checks will be executed t
> Bingo:
>
> -o
> receive_override_options=no_header_body_checks,no_unknown_recipient_checks
>
>
> Any negative consequences for eliminating this line, or changing it to:
>
> -o receive_override_options=no_unknown_recipient_checks
header_checks will be executed twice
Brian Evans - Postfix List wrote, On 7/1/2009 10:40 AM:
Do you have anything like:
"receive_override_options=no_header_body_checks" in master.cf for the
content_filter reinjection?
This will not match if so.
Bingo:
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_che
> Rob Brandt wrote, On 7/1/2009 9:09 AM:
>
>>
>> Excellent, I now get a match using postmap. If the spam doesn't cease,
>> I'll be back. Thanks everyone!
>>
>> Rob
>>
>
> Nuts. I am still getting spam. Is there any reason header_checks might
> not be enabled? Is header_checks being run before
Rob Brandt wrote:
>
>
> Rob Brandt wrote, On 7/1/2009 9:09 AM:
>
>>
>> Excellent, I now get a match using postmap. If the spam doesn't
>> cease, I'll be back. Thanks everyone!
>>
>> Rob
>>
>
> Nuts. I am still getting spam. Is there any reason header_checks
> might not be enabled? Is header_ch
Rob Brandt wrote, On 7/1/2009 9:09 AM:
Excellent, I now get a match using postmap. If the spam doesn't cease,
I'll be back. Thanks everyone!
Rob
Nuts. I am still getting spam. Is there any reason header_checks might
not be enabled? Is header_checks being run before SA processes it
Magnus Bäck wrote, On 6/30/2009 11:39 PM:
On Wed, July 1, 2009 8:13 am, Rob Brandt said:
Could I get an example of how to use postmap -q? I have tried:
postmap -q "X-Spam-Flag: YES" /etc/postfix/header_checks
where "X-Spam-Flag: YES" is the header I am trying to check and
/etc/postfix/head
Jason Bailey, Sun Advocate Webmaster wrote:
Rob Brandt wrote:
I'm trying to set up a basic header check to get rid of emails sa
marks as spam. I've added the following link to main.cf:
header_checks = regexp:/etc/postfix/filter
/etc/postfix/filter has:
# No ***SPAM***
/^Subject .*\*\*\*SPA
On Wed, 01 Jul 2009, Magnus Bäck wrote:
> On Wednesday, July 01, 2009 at 07:02 CEST,
> Rob Brandt wrote:
>
>
> > Sahil Tandon wrote:
> >
> > > I prefer pcre:, but the following patterns should work with regexp:
> > > as well.
>
> No, {n} isn't supported by regexp.
I too was surprised tha
On Wed, July 1, 2009 8:13 am, Rob Brandt said:
> Could I get an example of how to use postmap -q? I have tried:
>
> postmap -q "X-Spam-Flag: YES" /etc/postfix/header_checks
>
> where "X-Spam-Flag: YES" is the header I am trying to check and
> /etc/postfix/header_checks is the current name of my h
Magnus Bäck wrote:
On Wednesday, July 01, 2009 at 07:02 CEST,
Rob Brandt wrote:
Sahil Tandon wrote:
I prefer pcre:, but the following patterns should work with regexp:
as well.
No, {n} isn't supported by regexp.
/^Subject:.*\*{3}SPAM\*{3}/ DISCARD ***SPAM***
/^X-Spam-Flag: YES$/ D
On Wednesday, July 01, 2009 at 03:25 CEST,
"Jason Bailey, Sun Advocate Webmaster" wrote:
[...]
> The "/i" at the end implies case insensitivity when matching. I'm not
> sure if Postfix honors such pattern modifiers, but generally speaking,
> when dealing with Perl-compatible regex, that's w
On Wednesday, July 01, 2009 at 07:02 CEST,
Rob Brandt wrote:
> Sahil Tandon wrote:
>
> > I prefer pcre:, but the following patterns should work with regexp:
> > as well.
No, {n} isn't supported by regexp.
> > /^Subject:.*\*{3}SPAM\*{3}/ DISCARD ***SPAM***
> >
> > /^X-Spam-Flag: YES$/ DISC
Still doesn't seem to be working. Still using regexp, it seems I don't
have pcre installed as postfix throws errors when I try it. I'm
focusing on the X-Spam-Flag one since they both should eliminate the
same emails anyway. I've tried it both with the colon and without. Is
here a log somewh
Sahil Tandon wrote:
On Tue, 30 Jun 2009, Rob Brandt wrote:
I'm trying to set up a basic header check to get rid of emails sa marks
as spam. I've added the following link to main.cf:
header_checks = regexp:/etc/postfix/filter
I prefer pcre:, but the following patterns should work w
On Tue, 30 Jun 2009, Rob Brandt wrote:
> I'm trying to set up a basic header check to get rid of emails sa marks
> as spam. I've added the following link to main.cf:
>
> header_checks = regexp:/etc/postfix/filter
I prefer pcre:, but the following patterns should work with regexp: as well.
> #
Rob Brandt wrote:
I'm trying to set up a basic header check to get rid of emails sa marks
as spam. I've added the following link to main.cf:
header_checks = regexp:/etc/postfix/filter
/etc/postfix/filter has:
# No ***SPAM***
/^Subject .*\*\*\*SPAM\*\*\*/DISCARD ***SPAM***
# SPam flag
/^
59 matches
Mail list logo
