On Wed, 27 Nov 2019, Philipp Ewald wrote:
Hi Tobi,
we only want to trust "X-Spam-Flag: YES" or why should someone (spammer,
other mailserver with outgoing spamfilter) set this Flag to Yes?
but like RW wrote:
If you want to
match on such a header you need to rewrite it before SA sees it.
It makes no difference for your network traffic, only SA 4.0 / trunk handles
shortcircuiting and network lookups properly. But sure, marginal CPU
savings..
On Thu, Nov 28, 2019 at 01:50:31PM +0100, Philipp Ewald wrote:
> Hi Benny,
>
> thanks for your link! ( i did not follow any BOFH Rules
Hi Benny,
thanks for your link! ( i did not follow any BOFH Rules from this site ;-) )
i check headers and if "X-SPam-Flag: YES" is set, i write a custom Header from
postfix.
and in Spamassassin i search this custom header in shortcircuit.
It works!
X-Spam-Status: Yes, score=98.7
Hi Benny
yeah your links definitely show massive abuse of mta header/body checks :-)
But nonetheless mta header checks are way more performant and efficient
than such checks in a filter software. As long as the header you check
is used for a kill-shot its best place still is the mta header checks
On 2019-11-27 17:56, Philipp Ewald wrote:
we only want to trust "X-Spam-Flag: YES" or why should someone
(spammer, other mailserver with outgoing spamfilter) set this Flag to
Yes?
trustness
https://www.techiepark.com/tutorials/blocking-spam-using-postfix-header_checks-and-spamassassin/
bad
Hi Philipp
> or why should someone (spammer, other mailserver with outgoing
> spamfilter) set this Flag to Yes?
I would not think about the spammers here too much but more about a
misconfigured SA on sending side? Or the admin added a fancy rbl list
which suddenly stops working and returns a hit
On 2019-11-27 17:15, Tobi wrote:
Philipp,
Think you should ask yourself the following question: do I trust the
spam result from a remote server? If yes then why using a spamassassin
rule and not straight-out reject such mails on mta (header check)? And
if you do not trust the remote server
Hi Tobi,
we only want to trust "X-Spam-Flag: YES" or why should someone (spammer, other
mailserver with outgoing spamfilter) set this Flag to Yes?
but like RW wrote:
If you want to
match on such a header you need to rewrite it before SA sees it.
i thought shortcircuit will test before any
Philipp,
Think you should ask yourself the following question: do I trust the
spam result from a remote server? If yes then why using a spamassassin
rule and not straight-out reject such mails on mta (header check)? And
if you do not trust the remote server then why using its spam decission
at
On 26 Nov 2019, at 08:11, Philipp Ewald wrote:
we have "old customer" (with historical terms) there have forwarding rules for
any mail and we are not allowed to set SPAM Filter rule or to change the forwarding rules.
On 26.11.19 13:22, @lbutlr wrote:
Forwarding spam is a good way to be
On Tue, 26 Nov 2019 14:06:15 +0100
Philipp Ewald wrote:
> Hi guys,
>
> i want to bypas scanning mail if mail has already X-Spam-Flag: YES
> set. I found "clear_headers" in
> "/usr/share/spamassassin/10_default_prefs.cf".
>
> how can i override this setting? (include next update)
clear_headers
Oops. Sorry about that.
> On 26 Nov 2019, at 13:22, @lbutlr wrote:
>
> You know a thorn can main / But a lover does the same / A gem will
> reflect light / And a Fool will marvel at the sight / A fool such
> as me,
> /Who sees not the gold, but the beauty of the shine
> /%
> 'You
On 26 Nov 2019, at 08:11, Philipp Ewald wrote:
> we have "old customer" (with historical terms) there have forwarding rules
> for any mail and we are not allowed to set SPAM Filter rule or to change the
> forwarding rules.
Forwarding spam is a good way to be blacklisted as a spam source. This
Am 26.11.19 um 15:43 schrieb Matus UHLAR - fantomas:
On 26.11.19 15:08, Philipp Ewald wrote:
Not really... or why should some one set this header on non-spam?
FP means false positive. Mail that was evaluated as spam but is not.
On 26.11.19 16:30, Philipp Ewald wrote:
i know ;-)
Am 26.11.19 um 15:43 schrieb Matus UHLAR - fantomas:
On 26.11.19 15:08, Philipp Ewald wrote:
Not really... or why should some one set this header on non-spam?
FP means false positive. Mail that was evaluated as spam but is not.
i know ;-) X-Spam-Flag: yes on non spam is false positiv :)
Am 26.11.19 um 15:28 schrieb Reindl Harald:
Am 26.11.19 um 15:08 schrieb Philipp Ewald:
Not really... or why should some one set this header on non-spam?
strange question
why should anybody forard a mail instead reject it when it's 100% spam?
we have "old customer" (with historical
On 26.11.19 15:08, Philipp Ewald wrote:
Not really... or why should some one set this header on non-spam?
FP means false positive. Mail that was evaluated as spam but is not.
On 26.11.19 14:06, Philipp Ewald wrote:
i want to bypas scanning mail if mail has already X-Spam-Flag: YES set.
I
Not really... or why should some one set this header on non-spam?
Am 26.11.19 um 14:44 schrieb Matus UHLAR - fantomas:
On 26.11.19 14:06, Philipp Ewald wrote:
i want to bypas scanning mail if mail has already X-Spam-Flag: YES set.
I found "clear_headers" in
On 26.11.19 14:06, Philipp Ewald wrote:
i want to bypas scanning mail if mail has already X-Spam-Flag: YES set.
I found "clear_headers" in "/usr/share/spamassassin/10_default_prefs.cf".
how can i override this setting? (include next update)
don't you care about incoming FPs?
--
Matus UHLAR -
Hi guys,
i want to bypas scanning mail if mail has already X-Spam-Flag: YES set.
I found "clear_headers" in "/usr/share/spamassassin/10_default_prefs.cf".
how can i override this setting? (include next update)
Kind regards
Philipp
--
Philipp Ewald
Administrator
DigiOnline GmbH,
20 matches
Mail list logo
