Hi,
> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>
> header __RCVD_IN_BRBL eval:check_rbl('brbl',
> 'bb.barracudacentral.org')
> tflags __RCVD_IN_BRBL net
>
> header __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
> '127.0.0.2')
> metaRCVD_IN_BRBL_
On 2/5/2018 6:29 PM, John Hardin wrote:
Any suggestions on where to start? nOOb here!
Do you have Bayes enabled and are you training it?
Also do you have KAM.cf?
Regards,
kAM
On Mon, 5 Feb 2018, Alex wrote:
Hi,
Is it possible to identify if the Subject contains the sender?
You mean like __SUBJ_HAS_FROM_1 ?
I realize this probably isn't a significant spam indicator, but I think
it would be helpful.
From: example.com
To: mor...@example.com
Subject: mor...@ex
On Mon, 05 Feb 2018 17:12:08 +0100
Benny Pedersen wrote:
> Kevin A. McGrail skrev den 2018-02-05 16:53:
>
> > I don't think that will apply will it because it will be looking up
> > something like 1.2.3.4.bb.barracuda.blah which isn't cached.
>
> the first qurry can make a qurry with very low
Hi,
Is it possible to identify if the Subject contains the sender? I
realize this probably isn't a significant spam indicator, but I think
it would be helpful.
From: example.com
To: mor...@example.com
Subject: mor...@example.com You have just 15 hours to verify your account
I'm also think
On Tue, 6 Feb 2018, Philip wrote:
So lately I'm getting LOTS of emails coming directly though the filters so
most likely time to investigate how to create one.
The subject is always 'hey'
Subject: hey
Date: Mon, 29 Jan 2018 09:07:40 +0300
From: Darya Message-ID: <8f35b00fb4e07d18ce82448ec974
So lately I'm getting LOTS of emails coming directly though the filters
so most likely time to investigate how to create one.
The subject is always 'hey'
Subject: hey
Date: Mon, 29 Jan 2018 09:07:40 +0300
From: Darya Message-ID: <8f35b00fb4e07d18ce82448ec9747...@112it4u.ro>
X-Mailer: PHPMailer
On 2/5/2018 11:48 AM, Benny Pedersen wrote:
Kevin A. McGrail skrev den 2018-02-05 10:46:
tflags TEST_RULE nice
Then in a later file you decide to add:
tflags TEST_RULE net
tflags TEST_RULE config=inherit net
could be usefull :=)
tflags TEST_RULE config=override net
that way we have
Kevin A. McGrail skrev den 2018-02-05 10:46:
tflags TEST_RULE nice
Then in a later file you decide to add:
tflags TEST_RULE net
tflags TEST_RULE config=inherit net
could be usefull :=)
tflags TEST_RULE config=override net
that way we have a choice to use defaults still
On 2/5/2018 11:32 AM, RW wrote:
Just to clarify, there is no legal or moral obligation to do this, the
'bb' subdomain was created specifically so SA users wouldn't need to
register. Anything you may read on the Barracuda site applies to the
'b' version. Barracuda has given no indication that anyt
On Mon, 5 Feb 2018 08:09:55 -0600
David Jones wrote:
> Heads up! This RBL has been removed from the core SA ruleset. In 36
> to 48 hours sa-update will remove the RCVD_IN_BRBL_LASTEXT rule after
> it has gone through the masscheck and rule promotion process.
>
> Details can be found here:
>
>
Kevin A. McGrail skrev den 2018-02-05 16:53:
I don't think that will apply will it because it will be looking up
something like 1.2.3.4.bb.barracuda.blah which isn't cached.
the first qurry can make a qurry with very low ttl, so it would not be
cached, that means number 2 query still mkae dns
On 02/05/2018 09:44 AM, Reindl Harald wrote:
Am 05.02.2018 um 16:36 schrieb David Jones:
On 02/05/2018 09:26 AM, Benny Pedersen wrote:
David Jones skrev den 2018-02-05 15:09:
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header __RCVD_IN_BRBL eval:check_rbl('brbl',
'bb.barracudacen
On 2/5/2018 10:36 AM, David Jones wrote:
If you are running a local DNS cache like this list and the SA
documention recommends, does this really matter? My MTA should have
already queried this before SA does it so it should be in the local
DNS cache and not require a full recursive lookup from
David Jones skrev den 2018-02-05 16:36:
If you are running a local DNS cache like this list and the SA
documention recommends, does this really matter? My MTA should have
already queried this before SA does it so it should be in the local
DNS cache and not require a full recursive lookup from t
On 02/05/2018 09:26 AM, Benny Pedersen wrote:
David Jones skrev den 2018-02-05 15:09:
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header __RCVD_IN_BRBL eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags __RCVD_IN_BRBL net
header __RCVD_IN_BRBL_2 eval
David Jones skrev den 2018-02-05 15:09:
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header __RCVD_IN_BRBL eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags __RCVD_IN_BRBL net
header __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
'127.0.0.2')
meta
Heads up! This RBL has been removed from the core SA ruleset. In 36 to
48 hours sa-update will remove the RCVD_IN_BRBL_LASTEXT rule after it
has gone through the masscheck and rule promotion process.
Details can be found here:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7417
To add t
On 2/5/2018 4:07 AM, Matus UHLAR - fantomas wrote:
then I repeatedly use the "tflags" directive in official rules and
locally:
So I think you are saying you have a rule in one file, for example, a
default cf file with this line:
tflags TEST_RULE nice
Then in a later file you decide to
Hello,
then I repeatedly use the "tflags" directive in official rules and locally:
Does second appearance of "tflags" override the old value or just adds new
flags?
in other words:
Do I have to repeat all flags in tflags directive, or is it enough to add
new flag?
there are rules with high ne
20 matches
Mail list logo
