Re: spamassassin-3.4.2 and reload command

[Vlad Shpolyanskiy]

Kevin A. McGrail-5 wrote
> What command are you using to restart?  There was a small change in the
> process listing that might affect tools from distros.  I think it is this
> bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7594
> 
> -- 
> Kevin A. McGrail
> VP Fundraising, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin
> Projecthttps://www.linkedin.com/in/kmcgrail - 703.798.0171

Hi Kevin, 
I'm using standart freebsd script from /usr/local/etc/rc.d.
For reload it's sa-spamd reload, for restart it's sa-spamd restart. 



--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

Re: spamassassin-3.4.2 and reload command

[Kevin A. McGrail]

 On 10/4/2018 3:39 PM, Vlad Shpolyanskiy wrote:

Hi All!

I have recently upgraded SA to the latest version.
I'm running SA on FreeBSD 11.2-RELEASE-p4, SA installed via pkg utility with
default set of options.
The running command looks like:
/usr/local/bin/perl -T -w /usr/local/bin/spamd -m 5 -4 -d -r
/var/run/spamd/spamd.pid
Now I have a problem with reloading SA, e.g. after sa-update.
Reloading first time works as expected, but second time fails with error:
spamd not running? (check /var/run/spamd/spamd.pid)
The pid file is present, the permissions are fine.
If I use restart instead of  reload it works fine, no matter how many times.
spamassassin-3.4.1_12 does not have this problem.
Please, advice.
Thank you!

What command are you using to restart?  There was a small change in the
process listing that might affect tools from distros.  I think it is this
bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7594

-- 
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin
Projecthttps://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: deleting old data from txrep

[Alex]

Hi,

On Thu, Oct 4, 2018 at 2:54 AM Giovanni Bechis  wrote:
>
> On 10/04/18 04:30, Alex wrote:
> > Hi,
> >
> > I need to delete some of the old entries from my txrep database as
> > it's grown to 3GB, oops. When attempting to do this, it fails with
> > "error 14":
> >
> do you have enough space for tmp tables ? What if you try to delete less data 
> ? Does mysqlcheck(1) spots anything wrong ?

There's nearly 500GB left on the partition and probably 50GB RAM free.

I was successful deleting about 15 days of data at a time.
mysqlcheck(1) reported no problems on the txrep table.

There's now less than 60 days of data in the database, but the file
still shows 3GB.

# ls -l
total 3141664
-rw-rw 1 mysql mysql 65 Oct 19  2017 db.opt
-rw-rw 1 mysql mysql    Oct  4 11:39 txrep.frm
-rw-rw 1 mysql mysql 3217031168 Oct  4 15:51 txrep.ibd

I ran "optimize table txrep;" and it shrunk it down to 350MB. I'll add
an entry to cron to delete more regularly.

spamassassin-3.4.2 and reload command

[Vlad Shpolyanskiy]

Hi All!

I have recently upgraded SA to the latest version.
I'm running SA on FreeBSD 11.2-RELEASE-p4, SA installed via pkg utility with
default set of options.
The running command looks like:
/usr/local/bin/perl -T -w /usr/local/bin/spamd -m 5 -4 -d -r
/var/run/spamd/spamd.pid
Now I have a problem with reloading SA, e.g. after sa-update.
Reloading first time works as expected, but second time fails with error:
spamd not running? (check /var/run/spamd/spamd.pid)
The pid file is present, the permissions are fine.
If I use restart instead of  reload it works fine, no matter how many times.
spamassassin-3.4.1_12 does not have this problem.
Please, advice.
Thank you!



--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

Re: Bitcoin update

[Kevin A. McGrail]

Interesting.  Any chance for an unmodified pastebin spample?

On Thu, Oct 4, 2018, 12:07 Joseph Brennan  wrote:

>
> Two days ago the Bitcoin threats from Outlook.com started arriving in the
> Windows-1256 charset, which is Arabic, but including Latin characters. The
> text has Arabic character 9D all over the place. 9D is "ZERO WIDTH
> NON-JOINER" so it takes up no space and the English language text looks
> normal. But it breaks pattern matching.
>
> That ALL of the Bitcoin threats from outlook.com changed the evening of
> October 1 means they are all from one source.
>
> Sample of the mime part header and a raw paragraph:
>
> --_000_AM0PR04MB488298EB0071C1677D7C5BA9BAE90AM0PR04MB4882eurp_
> Content-Type: text/plain; charset="windows-1256"
> Content-Transfer-Encoding: quoted-printable
>
> Yo=9Du wi=9Dll ha=9Dv=9De two diff=9Derent so=9Dluti=9Do=9Dns. Why dont w=
> =9De check o=9Dut =9Dea=9Dch on=9De o=9Df thes=9De o=9Dpti=9Dons in
> deta=9D=
> i=9Dls:
>
>
> Joseph Brennan
> Columbia U I T
>
>

Bitcoin update

[Joseph Brennan]

Two days ago the Bitcoin threats from Outlook.com started arriving in the
Windows-1256 charset, which is Arabic, but including Latin characters. The
text has Arabic character 9D all over the place. 9D is "ZERO WIDTH
NON-JOINER" so it takes up no space and the English language text looks
normal. But it breaks pattern matching.

That ALL of the Bitcoin threats from outlook.com changed the evening of
October 1 means they are all from one source.

Sample of the mime part header and a raw paragraph:

--_000_AM0PR04MB488298EB0071C1677D7C5BA9BAE90AM0PR04MB4882eurp_
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

Yo=9Du wi=9Dll ha=9Dv=9De two diff=9Derent so=9Dluti=9Do=9Dns. Why dont w=
=9De check o=9Dut =9Dea=9Dch on=9De o=9Df thes=9De o=9Dpti=9Dons in deta=9D=
i=9Dls:


Joseph Brennan
Columbia U I T

Re: Hints needed for spf rule

[RW]

On Thu, 4 Oct 2018 01:29:11 -0400
Adam Katz wrote:


> The ptr mechanism in SPF is officially “do not use” right in the spec
> ; PTR records aren’t
> vetted (any network operator can assign literally any rDNS to their
> IPs), so it trivializes forgery that would elicit an SPF pass.

It marked as "do not use" because it slow, and it's more sensitive to
packet loss, not because it can be forged. The implementation  is
required to check that the DNS is full-circle by performing  A-record
look-ups on the rDNS result(s).

Re: txrep doesn't respect txrep_ipv4_mask_len

[Kevin A. McGrail]

Great.  Please open a bugzilla so I can get that fixed and check the
module for other similar bugs.  The ipv6 mask will have the same issue I
am sure.

Regards,
KAM

On 10/4/2018 8:40 AM, Daniele Duca wrote:
> Thanks Kevin, this did the trick!
>
> Daniele
>
> On 04/10/2018 14:19, Kevin A. McGrail wrote:
>> Can you open a bugzilla bug, please?  It sounds like you have found a
>> bug and it needs to be tracked.
>>
>> 16 is the default and the only uses of self in ip_to_awl_key are for the
>> mask length.
>>
>> Off the cuff, I'm thinking it's referencing the wrong hash for self and
>> missing conf:
>>
>> my $mask_len = $self->{conf}->{ipv4_mask_len};
>>
>> Does that work for you?
>>
>> regards,
>> KAM
>>
>> On 10/4/2018 3:38 AM, Daniele Duca wrote:
>>> Hi,
>>>
>>> I'm experimenting an odd behaviour while using TxRep. I have set in my
>>> local.cf "txrep_ipv4_mask_len 24" , but the database is populated by
>>> /16 instead of the expected /24.
>>>
>>> Digging in TxRep.pm I started using dbg() to see if it would at least
>>> read the correct value "24" from the .cf , and confirmed that, around
>>> line 528, the code
>>>
>>> $self->{txrep_ipv4_mask_len} = $value;
>>>
>>> is correctly working, meaning that $value has the value of "24"
>>>
>>> The problem arise around line 1727, in the following snippet:
>>>
>>> my $mask_len = $self->{txrep_ipv4_mask_len};
>>> $mask_len = 16  if !defined $mask_len;
>>>
>>> In this case "$self->{txrep_ipv4_mask_len}" is empty, and the value is
>>> set to the default of "16".
>>>
>>> This behaviour is consistent in nine different installations with the
>>> following specs:
>>>
>>> Ubuntu 16.04.4 - SA 3.4.1 - Perl v5.22.1
>>> Ubuntu 18.04.1 - SA 3.4.2 (CPAN) - Perl v5.26.1
>>>
>>> Any thoughts? My perl-fu is not good enough to debug this :/
>>>
>>> Thanks
>>> Daniele Duca
>>
>

-- 
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: FPs on FORGED_MUA_MOZILLA (for my own hand-typed messages from my latest-version Thunderbird)

[RW]

On Wed, 3 Oct 2018 12:31:32 -0400
Rob McEwen wrote:


> I really don't think I've done anything unusual with my setup of 
> Thunderbird. Does anyone have other suggestions? Is there anything I
> can do with my Thunderbird settings to mitigate this?

My guess is that your client hasn't updated the the rules in the 16
months since __MOZILLA_MSGID was updated for the new format, or has an
old version of SA that is no longer gets rule updates.

Re: txrep doesn't respect txrep_ipv4_mask_len

[Daniele Duca]

Thanks Kevin, this did the trick!

Daniele

On 04/10/2018 14:19, Kevin A. McGrail wrote:

Can you open a bugzilla bug, please?  It sounds like you have found a
bug and it needs to be tracked.

16 is the default and the only uses of self in ip_to_awl_key are for the
mask length.

Off the cuff, I'm thinking it's referencing the wrong hash for self and
missing conf:

my $mask_len = $self->{conf}->{ipv4_mask_len};

Does that work for you?

regards,
KAM

On 10/4/2018 3:38 AM, Daniele Duca wrote:

Hi,

I'm experimenting an odd behaviour while using TxRep. I have set in my
local.cf "txrep_ipv4_mask_len 24" , but the database is populated by
/16 instead of the expected /24.

Digging in TxRep.pm I started using dbg() to see if it would at least
read the correct value "24" from the .cf , and confirmed that, around
line 528, the code

$self->{txrep_ipv4_mask_len} = $value;

is correctly working, meaning that $value has the value of "24"

The problem arise around line 1727, in the following snippet:

my $mask_len = $self->{txrep_ipv4_mask_len};
$mask_len = 16  if !defined $mask_len;

In this case "$self->{txrep_ipv4_mask_len}" is empty, and the value is
set to the default of "16".

This behaviour is consistent in nine different installations with the
following specs:

Ubuntu 16.04.4 - SA 3.4.1 - Perl v5.22.1
Ubuntu 18.04.1 - SA 3.4.2 (CPAN) - Perl v5.26.1

Any thoughts? My perl-fu is not good enough to debug this :/

Thanks
Daniele Duca

Re: txrep doesn't respect txrep_ipv4_mask_len

[Kevin A. McGrail]

Can you open a bugzilla bug, please?  It sounds like you have found a
bug and it needs to be tracked.

16 is the default and the only uses of self in ip_to_awl_key are for the
mask length.

Off the cuff, I'm thinking it's referencing the wrong hash for self and
missing conf:

my $mask_len = $self->{conf}->{ipv4_mask_len};

Does that work for you?

regards,
KAM

On 10/4/2018 3:38 AM, Daniele Duca wrote:
> Hi,
>
> I'm experimenting an odd behaviour while using TxRep. I have set in my
> local.cf "txrep_ipv4_mask_len 24" , but the database is populated by
> /16 instead of the expected /24.
>
> Digging in TxRep.pm I started using dbg() to see if it would at least
> read the correct value "24" from the .cf , and confirmed that, around
> line 528, the code
>
> $self->{txrep_ipv4_mask_len} = $value;
>
> is correctly working, meaning that $value has the value of "24"
>
> The problem arise around line 1727, in the following snippet:
>
> my $mask_len = $self->{txrep_ipv4_mask_len};
> $mask_len = 16  if !defined $mask_len;
>
> In this case "$self->{txrep_ipv4_mask_len}" is empty, and the value is
> set to the default of "16".
>
> This behaviour is consistent in nine different installations with the
> following specs:
>
> Ubuntu 16.04.4 - SA 3.4.1 - Perl v5.22.1
> Ubuntu 18.04.1 - SA 3.4.2 (CPAN) - Perl v5.26.1
>
> Any thoughts? My perl-fu is not good enough to debug this :/
>
> Thanks
> Daniele Duca


-- 
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: txrep doesn't respect txrep_ipv4_mask_len

[Giovanni Bechis]

On 10/04/18 09:38, Daniele Duca wrote:
> Hi,
> 
> I'm experimenting an odd behaviour while using TxRep. I have set in my 
> local.cf "txrep_ipv4_mask_len 24" , but the database is populated by /16 
> instead of the expected /24.
> 
> Digging in TxRep.pm I started using dbg() to see if it would at least read 
> the correct value "24" from the .cf , and confirmed that, around line 528, 
> the code
> 
Completely untested patch attached, will double check it later.
 Cheers 
  Giovanni

> $self->{txrep_ipv4_mask_len} = $value;
> 
> is correctly working, meaning that $value has the value of "24"
> 
> The problem arise around line 1727, in the following snippet:
> 
> my $mask_len = $self->{txrep_ipv4_mask_len};
> $mask_len = 16  if !defined $mask_len;
> 
> In this case "$self->{txrep_ipv4_mask_len}" is empty, and the value is set to 
> the default of "16".
> 
> This behaviour is consistent in nine different installations with the 
> following specs:
> 
> Ubuntu 16.04.4 - SA 3.4.1 - Perl v5.22.1
> Ubuntu 18.04.1 - SA 3.4.2 (CPAN) - Perl v5.26.1
> 
> Any thoughts? My perl-fu is not good enough to debug this :/
> 
> Thanks
> Daniele Duca

Index: lib/Mail/SpamAssassin/Plugin/TxRep.pm
===
--- lib/Mail/SpamAssassin/Plugin/TxRep.pm	(revision 1842596)
+++ lib/Mail/SpamAssassin/Plugin/TxRep.pm	(working copy)
@@ -523,7 +523,7 @@
 {return $Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE;}
 elsif ($value !~ /^\d+$/ || $value < 0 || $value > 32)
 {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
-$self->{txrep_ipv4_mask_len} = $value;
+$self->{ipv4_mask_len} = $value;
 }
   });
 
@@ -556,7 +556,7 @@
 {return $Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE;}
 elsif ($value !~ /^\d+$/ || $value < 0 || $value > 128)
 {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
-$self->{txrep_ipv6_mask_len} = $value;
+$self->{ipv6_mask_len} = $value;
 }
   });
 

txrep doesn't respect txrep_ipv4_mask_len

[Daniele Duca]

Hi,

I'm experimenting an odd behaviour while using TxRep. I have set in my 
local.cf "txrep_ipv4_mask_len 24" , but the database is populated by /16 
instead of the expected /24.


Digging in TxRep.pm I started using dbg() to see if it would at least 
read the correct value "24" from the .cf , and confirmed that, around 
line 528, the code


$self->{txrep_ipv4_mask_len} = $value;

is correctly working, meaning that $value has the value of "24"

The problem arise around line 1727, in the following snippet:

my $mask_len = $self->{txrep_ipv4_mask_len};
$mask_len = 16  if !defined $mask_len;

In this case "$self->{txrep_ipv4_mask_len}" is empty, and the value is 
set to the default of "16".


This behaviour is consistent in nine different installations with the 
following specs:


Ubuntu 16.04.4 - SA 3.4.1 - Perl v5.22.1
Ubuntu 18.04.1 - SA 3.4.2 (CPAN) - Perl v5.26.1

Any thoughts? My perl-fu is not good enough to debug this :/

Thanks
Daniele Duca

Re: deleting old data from txrep

[Giovanni Bechis]

On 10/04/18 04:30, Alex wrote:
> Hi,
> 
> I need to delete some of the old entries from my txrep database as
> it's grown to 3GB, oops. When attempting to do this, it fails with
> "error 14":
>
do you have enough space for tmp tables ? What if you try to delete less data ? 
Does mysqlcheck(1) spots anything wrong ?
 Cheers
   Giovanni
 
> # rpm -q mariadb
> mariadb-10.2.17-2.fc28.x86_64
> 
> # ls -l
> total 3141664
> -rw-rw 1 mysql mysql 65 Oct 19  2017 db.opt
> -rw-rw 1 mysql mysql    Oct 19  2017 txrep.frm
> -rw-rw 1 mysql mysql 3217031168 Oct  3 22:29 txrep.ibd
> 
> MariaDB [txrepdb]> delete from txrep where last_hit <= '2018-01-01 00:00:00';
> ERROR 14 (HY000): Can't change size of file (Errcode: -1048710496
> "Internal error < 0 (Not system error)")
> 
> Searches show this can happen when the filesystem is full, but it's
> not. Any ideas of what could be wrong? Maybe write the last, say, 120
> days to another database then rename it?
>