ABUSE.CH mantains an updated lists of ramsonware lists, here the txt file link :
https://ransomwaretracker.abuse.ch/downloads/RW_URLBL.txt
It is very simple to make a shell script that check file changes every hour,
download if there is a new one, and write a rule .cf using data contained in
the
On 10/14/2016 10:30 AM, Nicola Piazzi wrote:
ABUSE.CH mantains an updated lists of ramsonware lists, here the txt file link :
https://ransomwaretracker.abuse.ch/downloads/RW_URLBL.txt
It is very simple to make a shell script that check file changes every hour,
download if there is a new one, an
Bot not all RW_URLBL.txt are contained in RW_DOMBL.txt and viceversa
For example 25z5g623wpqpdwis.onion.to doesn’t have match in RW_URLBL.txt
And if I extract from http://01ad681.netsolhost.com/7j0jlq3 the domain
01ad681.netsolhost.com is not in RW_DOMBL.txt
?!
Nicola Piazzi
CED - Sistemi
On 03/10/16 21:30, John Hardin wrote:
ClamAV is probably the correct approach to macro-based malware, unless
we want to do a MS Office document plugin with something like an eval
for has_macros().
ClamAV does allow macro detection, but it depends on the MTA glue used
whether you can use this f
On 10/14/2016 02:49 PM, Paul Stead wrote:
On 03/10/16 21:30, John Hardin wrote:
ClamAV is probably the correct approach to macro-based malware, unless
we want to do a MS Office document plugin with something like an eval
for has_macros().
ClamAV does allow macro detection, but it depends on t
On 10/14/2016 03:40 PM, Paul Stead wrote:
On 14/10/16 14:11, Axb wrote:
How's the performance. I know you run hi traffic sites.
Have you felt a difference?
Thanx
Axb
From the week or so of testing, things seem to be efficient and quick -
not to say there's not efficiencies that could be made
On 14/10/16 14:11, Axb wrote:
How's the performance. I know you run hi traffic sites.
Have you felt a difference?
Thanx
Axb
From the week or so of testing, things seem to be efficient and quick -
not to say there's not efficiencies that could be made with this code.
No discernible difference
On 14/10/16 14:44, Axb wrote:
On 10/14/2016 03:40 PM, Paul Stead wrote:
On 14/10/16 14:11, Axb wrote:
How's the performance. I know you run hi traffic sites.
Have you felt a difference?
Thanx
Axb
From the week or so of testing, things seem to be efficient and quick -
not to say there's not
Petr Bena wrote:
> Is there any way to get spam assassin to actually figure out that e-mail
> is spoofed even if it's obviously easy to figure out?
Consider the case of, oh, say, this message. Or virtually every other
interactive mailing list on the Internet.
Were you to do an SPF check on the F
On Fri, 14 Oct 2016 21:24:08 +0200
Petr Bena wrote:
> That is probably true, but it doesn't change the fact that SPF specs
> as they are make SPF completely useless.
It also doesn't change the fact that running SPF on the From: header
domain is completely wrong and will break all kinds of things
On 2016-10-14 21:24, Petr Bena wrote:
I created this BT
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7360 to implement
SPF-like checks on From: sender as well in addition to envelope sender
(if they differ). It was rejected as invalid because SPF specs are
different.
Authentication-Resul
On 10/14/2016 3:43 PM, Kris Deugau wrote:
Petr Bena wrote:
Is there any way to get spam assassin to actually figure out that e-mail
is spoofed even if it's obviously easy to figure out?
Consider the case of, oh, say, this message. Or virtually every other
interactive mailing list on the Intern
Hi,
On Fri, Oct 14, 2016 at 9:11 AM, Axb wrote:
> On 10/14/2016 02:49 PM, Paul Stead wrote:
>>
>>
>> On 03/10/16 21:30, John Hardin wrote:
>>>
>>> ClamAV is probably the correct approach to macro-based malware, unless
>>> we want to do a MS Office document plugin with something like an eval
>>> f
Hello,
I created this BT
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7360 to implement
SPF-like checks on From: sender as well in addition to envelope sender
(if they differ). It was rejected as invalid because SPF specs are
different.
That is probably true, but it doesn't change the fact
On 2016-10-14 23:24, Petr Bena wrote:
P.S. this is extremely easy to implement from programmer point of view,
all you need to do is take existing SPF plugin and just have it verify
SPF against e-mail that is in From header. It's probably a change of
few
lines of code for someone who knows perl
On 14.10.16 23:24, Petr Bena wrote:
> I know that this would break existing standards (which are flawed by
> design TBH), but why not at least make this as an optional feature?
You said it yourself: because it would break existing standards. That's
reason enough not to mess with things. The desig
On 14 Oct 2016, at 17:24, Petr Bena wrote:
Also I don't understand why mailing lists /have to/ work this way. I
know it's long-time established standard just like e-mails, but flawed
and people are abusing it, because it's extremely easy to do that.
Welcome to the Internet: where almost every
Exactly this.
Also I don't understand why mailing lists /have to/ work this way. I
know it's long-time established standard just like e-mails, but flawed
and people are abusing it, because it's extremely easy to do that.
Mailing list daemon doesn't have to pretend that e-mail was sent by me
or so
Hello,
I got a false positive because the test AM.WBL results in score 7. It
was a mail by email.apple.com (a bill). What is AM.WBL? I cant find it
in the test list: https://spamassassin.apache.org/tests_3_3_x.html
Do I have to set "score AM.WBL 0"?
19 matches
Mail list logo
