On 9/15/2017 8:51 PM, Chris wrote:
Ok, I see now that in 72_active.cf there is
Does adding a score RCVD_IN_BRBL_LASTEXT 0 to your local.cf work?
On Fri, 2017-09-15 at 20:35 -0400, Kevin A. McGrail wrote:
> On 9/15/2017 8:22 PM, RW wrote:
> >
> > $ grep -ri barracudacentral /var/db/spamassassin/
> > /var/db/spamassassin/3.004001/updates_spamassassin_org/72_active.cf
> > :header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-
> > lastexternal',
On 9/15/2017 8:22 PM, RW wrote:
$ grep -ri barracudacentral /var/db/spamassassin/
/var/db/spamassassin/3.004001/updates_spamassassin_org/72_active.cf:header
RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal','bb.barracudacentral.org')
That sounds like a mistake. Does it meet our defaul
On Fri, 15 Sep 2017 18:51:22 -0400
Kevin A. McGrail wrote:
> On 9/15/2017 6:46 PM, Chris wrote:
> > On Fri, 2017-09-15 at 18:20 -0400, Kevin A. McGrail wrote:
> >> On 9/15/2017 5:50 PM, Chris wrote:
> >>> It's not a 'show stopper' it's just annoying to keep seeing this
> >>> and
> >>> wonderin
On 9/15/2017 6:46 PM, Chris wrote:
On Fri, 2017-09-15 at 18:20 -0400, Kevin A. McGrail wrote:
On 9/15/2017 5:50 PM, Chris wrote:
It's not a 'show stopper' it's just annoying to keep seeing this
and
wondering what the cause is.
You have configured your installation with the Baraccuda Reputation
On Fri, 2017-09-15 at 18:20 -0400, Kevin A. McGrail wrote:
> On 9/15/2017 5:50 PM, Chris wrote:
> >
> > It's not a 'show stopper' it's just annoying to keep seeing this
> > and
> > wondering what the cause is.
> You have configured your installation with the Baraccuda Reputation
> Black List but
On 15.09.17 23:50, Chris wrote:
> localhost named[1284]: connection refused resolving
> '190.129.2.198.bb.barracudacentral.org/A/IN': 64.235.154.72#53
According to http://barracudacentral.org/rbl/how-to-use that should be
b.barracudacentral.org, not bb.barracudacentral.org (single 'b').
-Ralph
On 9/15/2017 5:50 PM, Chris wrote:
It's not a 'show stopper' it's just annoying to keep seeing this and
wondering what the cause is.
You have configured your installation with the Baraccuda Reputation
Black List but likely not subscribed your IP address.
See http://barracudacentral.org/rbl
I wasn't quite sure what to put for the subject line. I didn't want to
include the whole issue I'm seeing as I wanted to put it below. Every
time SA is run on a message I'm seeing:
spamd[15128]: spamd: processing message <1f44a5c57d9ff7ab8a90e109b.6708
c37fa7.20170915204926.d9a014b97f.eaede...@mai
On Fri, 15 Sep 2017 15:46:31 -0500 (CDT)
sha...@shanew.net wrote:
> So, my rule for just matching TLDs looks like:
>
> uri __TEST_URLS /\.(vn|pl|my|lu|vn|ar)\b[^\.-]/i
>
> The "\b" part excludes the letters, numbers and underscore because
> those wouldn't be a word boundary. The "[^\.-]" part
On Fri, 15 Sep 2017, Robert Boyl wrote:
uri
__KAM_SHORT/(\/|^|\b)(?:j\.mp|bit\.ly|goo\.gl|x\.co|t\.co|t\.cn|tinyurl\.com|hop\.kz|u
rla\.ru|fw\.to)(\/|$|\b)/i
Seems a bit complicated.
It would be to make this rule check that suffixes are at the end of URI.
uri __TEST_URLS /\b(\.vn
On 9/15/2017 12:48 PM, Robert Boyl wrote:
Thanks! I didnt find this info in Writing rules tutorial.
Yeah, I rewrote the rule a bit already. Thanks!
It's in the latest KAM.cf.
On Sep 15, 2017, at 12:24 PM, David Jones wrote:
> You kinda have to work backwards through the scripts to find what is
> generating the scores-set0 file and turning it into 72_scores.cf. I am
> grep'ing through the work dir on the SA server now but it contains a lot of
> files. I need to fin
On Sep 15, 2017, at 12:24 PM, David Jones wrote:
> 1. Actually start here with the runGA call:
>
> http://svn.apache.org/viewvc/spamassassin/trunk/masses/rule-update-score-gen/generate-new-scores.sh?revision=1798589&view=markup#l271
>
> 2. Here is the runGA script (not changed in almost 8 years)
On 15/09/2017, 20:59, "Paul Stead" wrote:
On 15/09/2017, 20:57, "sha...@shanew.net" wrote:
If you're only looking at uris, it probably is (though I wonder a
little about processing time between a long list of such entries and a
single (if also long) regular expre
On 15/09/2017, 20:57, "sha...@shanew.net" wrote:
If you're only looking at uris, it probably is (though I wonder a
little about processing time between a long list of such entries and a
single (if also long) regular expression). I have rules for "bad"
tlds that look in headers
On Fri, 15 Sep 2017, Paul Stead wrote:
Something along the following still seems the easiest to read approach to me
enlist_uri_host (BADTLDS) vn
enlist_uri_host (BADTLDS) pl
enlist_uri_host (BADTLDS) my
enlist_uri_host (BADTLDS) lu
enlist_uri_host (BADTLDS) ar
header __TEST_URLS eval:check
Something along the following still seems the easiest to read approach to me
enlist_uri_host (BADTLDS) vn
enlist_uri_host (BADTLDS) pl
enlist_uri_host (BADTLDS) my
enlist_uri_host (BADTLDS) lu
enlist_uri_host (BADTLDS) ar
header __TEST_URLS eval:check_uri_host_listed('BADTLDS')
Paul
From: Rober
Hi,
On Fri, Sep 15, 2017 at 9:34 AM, Kevin A. McGrail
wrote:
> On 9/15/2017 8:26 AM, RW wrote:
>>
>> The rule was created and scored when spoofing Yahoo was very common,
>> but it isn't any more. I don't think it's worth keeping as it is - high
>> maintenance and error prone.
>
>
> Agreed. Score
On 15/09/17 14:34, Kevin A. McGrail wrote:
On 9/15/2017 8:26 AM, RW wrote:
The rule was created and scored when spoofing Yahoo was very common,
but it isn't any more. I don't think it's worth keeping as it is - high
maintenance and error prone.
Agreed. Score FORGED_YAHOO_RCVD to zero locally
On 2017-09-15 13:32, RW wrote:
> The default is 500kB for spamc, 256kB is a default for sa-learn.
I have asked this before:
Does this mean 500 * 1000 bytes or 512 * 1024 bytes, or something else
still?
(this is relevant when configuring other stuff which only understands
straight byte counts
Hi!
Thanks! I didnt find this info in Writing rules tutorial.
I see
uri __KAM_SHORT
/(\/|^|\b)(?:j\.mp|bit\.ly|goo\.gl|x\.co|t\.co|t\.cn|tinyurl\.com|hop\.kz|urla\.ru|fw\.to)(\/|$|\b)/i
Seems a bit complicated.
It would be to make this rule check that suffixes are at the end of URI
On 09/15/2017 09:52 AM, Merijn van den Kroonenberg wrote:
On Sep 15, 2017, at 9:46 AM, David Jones wrote:
3. I have narrowed down the problem to the general area of a perl
Makefile which builds a custom garescorer.c file which does some
statistical analysis to determine the best score for rules
> On Sep 15, 2017, at 9:46 AM, David Jones wrote:
>> 3. I have narrowed down the problem to the general area of a perl
>> Makefile which builds a custom garescorer.c file which does some
>> statistical analysis to determine the best score for rules in the
>> 72_scores.cf. These 72_scores.cf are e
On Sep 15, 2017, at 9:46 AM, David Jones wrote:
> 3. I have narrowed down the problem to the general area of a perl Makefile
> which builds a custom garescorer.c file which does some statistical analysis
> to determine the best score for rules in the 72_scores.cf. These
> 72_scores.cf are excl
On 09/15/2017 07:26 AM, Kevin A. McGrail wrote:
On 9/15/2017 8:22 AM, Merijn van den Kroonenberg wrote:
So one of the problems with solving this is because getting help
requires
a complicated enrollment.
Maybe there are chunks of work which can be offloaded to the community
without requiring f
On 9/15/2017 8:26 AM, RW wrote:
The rule was created and scored when spoofing Yahoo was very common,
but it isn't any more. I don't think it's worth keeping as it is - high
maintenance and error prone.
Agreed. Score FORGED_YAHOO_RCVD to zero locally and will get a bug open
to deprecate it.
On Fri, 15 Sep 2017 00:39:35 +0100
Sebastian Arcus wrote:
> I had to add on my systems a while ago an
> /etc/mail/spamassassin/spamc.conf containing:
>
> -s 200
>
> to increase the maximum size of emails passed to SA. It seems some
> spammers have cottoned onto the fact that 256KB is stil
On Fri, 15 Sep 2017 11:50:25 +0100
Sebastian Arcus wrote:
> I see this has come up again and again. Since FORGED_YAHOO_RCVD seems
> to work by checking the address of the Yahoo smtp server in the
> headers against a predefined list of Yahoo servers in SA, and Yahoo
> seems to add new servers all t
On 9/15/2017 8:22 AM, Merijn van den Kroonenberg wrote:
So one of the problems with solving this is because getting help requires
a complicated enrollment.
Maybe there are chunks of work which can be offloaded to the community
without requiring full sysadmin enrollment?
I can imagine lots of sc
> On 9/15/2017 7:43 AM, Merijn van den Kroonenberg wrote:
>> It sounds a bit like you guys are hitting a wall?
>>
>> Could any help from the community get things going again? If so, what
>> kind
>> of skillset would be useful to tackle this thing?
>
> Yes, help is always welcome. More hands make
On 9/15/2017 7:43 AM, Merijn van den Kroonenberg wrote:
It sounds a bit like you guys are hitting a wall?
Could any help from the community get things going again? If so, what kind
of skillset would be useful to tackle this thing?
Yes, help is always welcome. More hands make light work. We s
On 15/09/17 12:21, Kevin A. McGrail wrote:
On 9/15/2017 6:54 AM, Sebastian Arcus wrote:
Thank you for the reply. Does that mean that no new rules have been
pushed to SA installations in the past 5 months - or only some rules
get pushed through?
The system has been "down" since March 15 in tha
> On 9/15/2017 6:54 AM, Sebastian Arcus wrote:
>> Thank you for the reply. Does that mean that no new rules have been
>> pushed to SA installations in the past 5 months - or only some rules
>> get pushed through?
>
> The system has been "down" since March 15 in that everything is working
> but we a
> On 15/09/17 11:41, Kevin A. McGrail wrote:
>> On 9/15/2017 6:11 AM, Sebastian Arcus wrote:
>>> I am having problems with false positives for FORGED_MUA_MOZILLA for
>>> Yahoo emails. I see this has been already dealt with here and pushed
>>> to the 3.4 and trunk branches:
>>>
>>> https://bz.apache
On 9/15/2017 6:54 AM, Sebastian Arcus wrote:
Thank you for the reply. Does that mean that no new rules have been
pushed to SA installations in the past 5 months - or only some rules
get pushed through?
The system has been "down" since March 15 in that everything is working
but we are purposef
On 15/09/17 11:41, Kevin A. McGrail wrote:
On 9/15/2017 6:11 AM, Sebastian Arcus wrote:
I am having problems with false positives for FORGED_MUA_MOZILLA for
Yahoo emails. I see this has been already dealt with here and pushed
to the 3.4 and trunk branches:
https://bz.apache.org/SpamAssassin/s
I see this has come up again and again. Since FORGED_YAHOO_RCVD seems to
work by checking the address of the Yahoo smtp server in the headers
against a predefined list of Yahoo servers in SA, and Yahoo seems to add
new servers all the time - which causes false positives, is there much
point to
On 9/15/2017 6:11 AM, Sebastian Arcus wrote:
I am having problems with false positives for FORGED_MUA_MOZILLA for
Yahoo emails. I see this has been already dealt with here and pushed
to the 3.4 and trunk branches:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7411
However, even after run
I am having problems with false positives for FORGED_MUA_MOZILLA for
Yahoo emails. I see this has been already dealt with here and pushed to
the 3.4 and trunk branches:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7411
However, even after running sa-update, the file 20_meta_tests.cf stil
40 matches
Mail list logo
