Re: KAM_Back rule
On 10/26/2018 3:13 PM, John wrote: > I just got an email from a mailing list of which i am a member (UK > academic geophysics) which was scored at 5, mainly from a 5.5 > contribution from KAM_BACK, described as background check SPAM. I have > not managed to work out what that rule is trying to do, but it is the > first detected oh-nasty from using the KAM rules. > > Clearly I can reduce the score but I am struggling to see what was > wrong with the message, attached. > ==John ffitch Hi John, thanks for the FP. I've tweaked the rules. -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: CryptoBL [was: Bitcoin rules]
+1. I had the same thought. -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Wed, Oct 31, 2018 at 12:21 PM Henrik K wrote: > On Wed, Oct 31, 2018 at 03:11:51PM +, RW wrote: > > On Wed, 31 Oct 2018 12:03:38 +0100 > > Daniele Duca wrote: > > > > > Hello everyone, > > > > > > as said some days ago I started a DNSBL based on abused/malign BTC > > > addresses. This list is queried by an SA plugin that takes the md5 > > > hash (I know, outdated algorithm, but good enough for this purpose > > > IMHO) > > > > As I pointed out before hashing isn't needed to avoid FPs on case > > insensitive matches, and it does make things less transparent in > > debugging. > > > > These addresses contain a 160 bit hash of the public key and a 256 bit > > validity hash. When you convert an alphanumeric string to lower case > > you only lose about 13% of the entropy, so the probability that two > > valid and distinct addresses have a case insensitive match is > > approximately: > > > > 1 in 2^360 > > > > compare that with the probability of the same md5 hash value: > > > >1 in 2^128 > > > > and the probability that two wallets have the same address: > > > > 1 in 2^160 > > > > > > With email address lookups the main reason for hashing was privacy, > > but that obviously doesn't apply here. > > No matter, I will implement BTC (and ETH etc), URL and other imaginable > "hash bl" checks to HashBL.pm with options for raw/md5/sha1 etc. Everyone > can run their BLs then how they wish. ;-) > >
Re: CryptoBL [was: Bitcoin rules]
On Wed, Oct 31, 2018 at 03:11:51PM +, RW wrote: > On Wed, 31 Oct 2018 12:03:38 +0100 > Daniele Duca wrote: > > > Hello everyone, > > > > as said some days ago I started a DNSBL based on abused/malign BTC > > addresses. This list is queried by an SA plugin that takes the md5 > > hash (I know, outdated algorithm, but good enough for this purpose > > IMHO) > > As I pointed out before hashing isn't needed to avoid FPs on case > insensitive matches, and it does make things less transparent in > debugging. > > These addresses contain a 160 bit hash of the public key and a 256 bit > validity hash. When you convert an alphanumeric string to lower case > you only lose about 13% of the entropy, so the probability that two > valid and distinct addresses have a case insensitive match is > approximately: > > 1 in 2^360 > > compare that with the probability of the same md5 hash value: > >1 in 2^128 > > and the probability that two wallets have the same address: > > 1 in 2^160 > > > With email address lookups the main reason for hashing was privacy, > but that obviously doesn't apply here. No matter, I will implement BTC (and ETH etc), URL and other imaginable "hash bl" checks to HashBL.pm with options for raw/md5/sha1 etc. Everyone can run their BLs then how they wish. ;-)
Re: CryptoBL [was: Bitcoin rules]
On Wed, 31 Oct 2018 12:03:38 +0100 Daniele Duca wrote: > Hello everyone, > > as said some days ago I started a DNSBL based on abused/malign BTC > addresses. This list is queried by an SA plugin that takes the md5 > hash (I know, outdated algorithm, but good enough for this purpose > IMHO) As I pointed out before hashing isn't needed to avoid FPs on case insensitive matches, and it does make things less transparent in debugging. These addresses contain a 160 bit hash of the public key and a 256 bit validity hash. When you convert an alphanumeric string to lower case you only lose about 13% of the entropy, so the probability that two valid and distinct addresses have a case insensitive match is approximately: 1 in 2^360 compare that with the probability of the same md5 hash value: 1 in 2^128 and the probability that two wallets have the same address: 1 in 2^160 With email address lookups the main reason for hashing was privacy, but that obviously doesn't apply here.
Re: Error running sa-update - cannot refresh mirrors file
On Wednesday, 31 October 2018 7:29:51 ACDT RW wrote:
> On Mon, 29 Oct 2018 09:07:09 -0400
>
> Kevin A. McGrail wrote:
> > On 10/29/2018 8:03 AM, Rodney Baker wrote:
> > > re: renaming curl and using wget
> > >
> > > Thanks. Did that - it worked with wget instead of curl, successfully
> > > downloading the mirrors file and all updates. The last failure with
> > > curl was last night.
>
> Can you try
>
> curl --verbose -L -O --remote-time -g --max-redirs 2 --connect-timeout 30
> --max-time 300 http://spamassassin.apache.org/updates/MIRRORED.BY
> > Then you are likely caught up in the buggy curl we've seen on other
> > distros. Thanks for helping confirm it.
>
> I don't think anything has been confirmed. The problem with curl
> failing on an http uri redirecting to https is no longer relevant, and
> presumably curl has successfully fetched the mirror file since the
> current version of SpamAssassin was installed or there wouldn't be a
> cached copy.
Here's the output from that command:
root@mailpi ~ # curl --verbose -L -O --remote-time -g --max-redirs 2 --
connect-timeout 30 --max-time 300 http://spamassassin.apache.org/updates/
MIRRORED.BY
* Hostname was NOT found in DNS cache
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Trying 40.79.78.1...
0 00 00 0 0 0 --:--:-- 0:00:01 --:--:-- 0*
Connected to spamassassin.apache.org (40.79.78.1) port 80 (#0)
> GET /updates/MIRRORED.BY HTTP/1.1
> User-Agent: curl/7.38.0
> Host: spamassassin.apache.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 31 Oct 2018 12:26:54 GMT
* Server Apache/2.4.18 (Ubuntu) is not blacklisted
< Server: Apache/2.4.18 (Ubuntu)
< Last-Modified: Sat, 27 Oct 2018 16:35:00 GMT
< ETag: "576-579386aca20a2"
< Accept-Ranges: bytes
< Content-Length: 1398
<
{ [data not shown]
100 1398 100 13980 0707 0 0:00:01 0:00:01 --:--:-- 707
* Connection #0 to host spamassassin.apache.org left intact
--
==
Rodney Baker VK5ZTV
rodney.ba...@iinet.net.au
CCNA #CSCO12880208
==
Re: check_header_count_range() for MIME sections?
On 10/30/2018 12:16 AM, Philip Prindeville wrote: > I’d like to be able to detect duplicated header types in MIME sections. > > I think you all have been seeing them too. Is there an easy way to see if a > message contains any MIME sections where particular headers occur more than > once? > I am not aware of the issue you are describing but was going to suggest you look at Mail::SpamAssassin::Plugin::MIMEHeader Regards, KAM -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Error running sa-update - cannot refresh mirrors file
On Wednesday, 31 October 2018 7:29:51 ACDT RW wrote:
> On Mon, 29 Oct 2018 09:07:09 -0400
>
> Kevin A. McGrail wrote:
> > On 10/29/2018 8:03 AM, Rodney Baker wrote:
> > > re: renaming curl and using wget
> > >
> > > Thanks. Did that - it worked with wget instead of curl, successfully
> > > downloading the mirrors file and all updates. The last failure with
> > > curl was last night.
>
> Can you try
>
> curl --verbose -L -O --remote-time -g --max-redirs 2 --connect-timeout 30
> --max-time 300 http://spamassassin.apache.org/updates/MIRRORED.BY
> > Then you are likely caught up in the buggy curl we've seen on other
> > distros. Thanks for helping confirm it.
>
> I don't think anything has been confirmed. The problem with curl
> failing on an http uri redirecting to https is no longer relevant, and
> presumably curl has successfully fetched the mirror file since the
> current version of SpamAssassin was installed or there wouldn't be a
> cached copy.
Here's the output from that command:
root@mailpi ~ # curl --verbose -L -O --remote-time -g --max-redirs 2 --
connect-timeout 30 --max-time 300 http://spamassassin.apache.org/updates/
MIRRORED.BY
* Hostname was NOT found in DNS cache
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Trying 40.79.78.1...
0 00 00 0 0 0 --:--:-- 0:00:01 --:--:-- 0*
Connected to spamassassin.apache.org (40.79.78.1) port 80 (#0)
> GET /updates/MIRRORED.BY HTTP/1.1
> User-Agent: curl/7.38.0
> Host: spamassassin.apache.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 31 Oct 2018 12:26:54 GMT
* Server Apache/2.4.18 (Ubuntu) is not blacklisted
< Server: Apache/2.4.18 (Ubuntu)
< Last-Modified: Sat, 27 Oct 2018 16:35:00 GMT
< ETag: "576-579386aca20a2"
< Accept-Ranges: bytes
< Content-Length: 1398
<
{ [data not shown]
100 1398 100 13980 0707 0 0:00:01 0:00:01 --:--:-- 707
* Connection #0 to host spamassassin.apache.org left intact
--
==
Rodney Baker VK5ZTV
rodney.ba...@iinet.net.au
CCNA #CSCO12880208
==
CryptoBL [was: Bitcoin rules]
Hello everyone, as said some days ago I started a DNSBL based on abused/malign BTC addresses. This list is queried by an SA plugin that takes the md5 hash (I know, outdated algorithm, but good enough for this purpose IMHO) of a BTC wallet found in the body and looks it up in the DNSBL. The DNSBL is (mostly) automatically populated by trap feeds and from bitcoinabuse.com What I'm looking for are people that would like to try it and possibly polish the plugin (I'm not a coder) and/or contribute with malign BTC wallets, or other cryptovalues found in sextortions. If interested please PM me offlist Thanks Daniele Duca
