On Sat, 26 Jan 2019, John Hardin wrote:
On Sat, 26 Jan 2019, Mark London wrote:
Does anyone have any rules that can catch this type of obfuscated spam?
https://pastebin.com/qi8dsREW
There's some "invisible font" subrules in my sandbox that this hits
(__STY_INVIS_MANY, __FONT_
ey do well against your Bayes but that's not sufficient to block
them, you could define local booster metas like:
meta LCL_SPAM_BOOST_123 BAYES_99 && __STY_INVIS_MANY
meta LCL_SPAM_BOOST_124 BAYES_99 && __FONT_INVIS_MANY
--
John Hardin KA7OHZ
On Thu, 24 Jan 2019, Amir Caspi wrote:
On Jan 15, 2019, at 8:46 AM, John Hardin wrote:
On Dec 20, 2018, at 6:16 PM, Amir Caspi wrote:
header AC_FROM_MANY_DOTS From =~ /<(?:\w{2,}\.){2,}\w+@/
Argh. I lost track of that over the holidays. Thanks for the reminder, adding
it
On Tue, 22 Jan 2019, John Hardin wrote:
On Tue, 22 Jan 2019, Joseph Brennan wrote:
Sent to me personally. Incredible amount of obfuscation.
Okay, it looks like the fuzzy versions are still needed...
Restored.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar
On Tue, 22 Jan 2019, Joseph Brennan wrote:
Sent to me personally. Incredible amount of obfuscation.
Okay, it looks like the fuzzy versions are still needed...
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar
rgh. I lost track of that over the holidays. Thanks for the reminder,
adding it now.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2
> got hit:
"Jano"
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C
ot; is not optional in that RE, so it would never match "ján".
While it doesn't directly answer your question about normalize-charset,
this might work a little better:
ifplugin Mail::SpamAssassin::Plugin::ReplaceTags
body LOCAL_JANO /\bjno?\b/i
replace_rules LO
content is ever accepted and passed to SpamAssassin.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
own, but the two-dot could be better in
combo... not sure.
Hopefully it's helpful...
Cheers.
--- Amir
Can you also provide a spample? Thanks!
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
IN_POISONED 10.000 # poison pill
__LOCAL_BITCOIN_WHITELIST is an exercise for the student... :)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 64
On Thu, 13 Dec 2018, John Hardin wrote:
On Thu, 13 Dec 2018, Chip M. wrote:
As requested:
http://puffin.net/software/spam/samples/0061_bitcoin_splosion.txt
I MUNGED the "To".
It's the latest of two sent to me by an awesome volunteer. :)
First thoughts:
Both were base64 enc
s" that they're not terrorists. :roll-eyes:
It hits damned near nothing...
John Hardin: I'll ask for a full bundle from this volunteer (he's in your time
zone), and send you full spamples of everything relevant.
- "Chip"
Thanks. I'll see what I can do, but I suspect that not hav
for it.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Our
some FP-avoidance tuning and see if it can be made
publishable.
I'm not sure whether it's hitting on a From header like:
"Johnny Fnord "
I'll review that, too.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pg
(,)_
but I periodically like to see what's going on.
It would be reasonable to file a bug that _SUBTESTS reports duplicates. I
would characterize that as a misbehavior.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar
corpus. Potentially we
should set a fixed override score for it.
I've tweaked a couple of other rules that this hit that were either
testing-only or filtered out. It should score higher soon.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org
-update
processing (will require managing DNS entries and generating SHA checksums
for the rules file)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76
that!
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
7 days until
On Fri, 7 Dec 2018, Amir Caspi wrote:
On Dec 6, 2018, at 12:14 PM, John Hardin wrote:
Runaway backtracking that was killing masscheck for several people.
Hrm, that is disconcerting. I'm not sure where any backtracking might be
occurring...
This sort of thing is risky, especially
On Tue, 4 Dec 2018, Amir Caspi wrote:
On Dec 1, 2018, at 10:31 AM, John Hardin wrote:
On Thu, 29 Nov 2018, Amir Caspi wrote:
A) Could you sandbox the proposed rule change (AC_HTML_ENTITY_BONANZA_NEW) and
see how it performs, including possible FPs?
Done.
Any preliminary results
All headers together in one hit
header __ALL_HEADERS_ALLALL =~ /(?:.+$)+/sm
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76
On Wed, 5 Dec 2018, Grant Taylor wrote:
On 12/5/18 5:43 PM, John Hardin wrote:
Potentially, but it's hard to use something like that in regular rule REs.
That sort of smarts would probably need to be in a plugin.
Maybe (from my naive point of view) if not probably (from your more
On Wed, 5 Dec 2018, Grant Taylor wrote:
On 12/05/2018 03:27 PM, John Hardin wrote:
Take a look at replace_rules in the repo (both standard and sandboxes).
Thank you for the reference. replace_rules look very intriguing.
Link - Mail::SpamAssassin::Plugin::ReplaceTags - tags for SpamAssassin
On Wed, 5 Dec 2018, Bill Cole wrote:
On 5 Dec 2018, at 16:45, John Hardin wrote:
Those aren't zero-width, those are just standard Unicode obfuscations of
regular ASCII text.
Not precisely. In this case they seem to all be Cyrillic characters which
happen to look like Latin characters
On Wed, 5 Dec 2018, Grant Taylor wrote:
On 12/05/2018 02:45 PM, John Hardin wrote:
I've added a "too many [ascii][unicode][ascii]" rule based on that but I
suspect it will be pretty FP-prone and will be pretty large if we want to
avoid whack-a-mole syndrome. For this, normali
d some of the new phrases from that to the bitcoin extort
components.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507
On Wed, 5 Dec 2018, Mark London wrote:
The __UNICODE_OBFU_ZW rule is not being triggered on this email. Maybe it
needs updating? - Mark
Will do, I don't have a zero response time as much as I wish I did... :)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar
On Tue, 4 Dec 2018, Amir Caspi wrote:
On Dec 1, 2018, at 10:31 AM, John Hardin wrote:
On Thu, 29 Nov 2018, Amir Caspi wrote:
A) Could you sandbox the proposed rule change (AC_HTML_ENTITY_BONANZA_NEW) and
see how it performs, including possible FPs?
Done.
Any preliminary results
cy, but don't change anything else) it would help
writing a rule that actually does match.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76
of web server error messaging...
How difficult would it be to detect that and include it in the logging?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76
On Thu, 29 Nov 2018, John Hardin wrote:
On Thu, 29 Nov 2018, Amir Caspi wrote:
On Nov 29, 2018, at 3:27 PM, John Hardin wrote:
I'll see whether those can be incorporated into the existing
UNICODE_OBFU_ZW rule (which of course will no longer actually be UNICODE
:) )
Great. Maybe rename
to reject
messages missing a Message-ID during the SMTP phase before it ever touches
SA.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6
On Thu, 29 Nov 2018, Amir Caspi wrote:
On Nov 29, 2018, at 3:27 PM, John Hardin wrote:
I'll see whether those can be incorporated into the existing UNICODE_OBFU_ZW
rule (which of course will no longer actually be UNICODE :) )
Great. Maybe rename the rule. ;-)
What are your thoughts
those can be incorporated into the existing
UNICODE_OBFU_ZW rule (which of course will no longer actually be UNICODE :) )
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F
On Fri, 23 Nov 2018, RW wrote:
On Fri, 23 Nov 2018 08:24:07 -0800 (PST)
John Hardin wrote:
On Fri, 23 Nov 2018, RW wrote:
On Fri, 23 Nov 2018 09:49:34 +0100
Matus UHLAR - fantomas wrote:
But as I said it's the decimal fractions that cause it to fail
and the above rule doesn't need
or all of the *components* of the meta).
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C
se rules has
"tflags multiple" set (unless with maxhits=1)
Actually, that comment applies to *any* mathematical meta threshold logic
involving "tflags multiple" rules.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgF
On Tue, 20 Nov 2018, RW wrote:
On Mon, 19 Nov 2018 13:31:47 -0800 (PST)
John Hardin wrote:
On Mon, 19 Nov 2018, Joseph Brennan wrote:
Example: Obvi=9Do=9Dusly yo=9Du=9D ca=9Dn can cha=9Dnge=9D i=9Dt
In windows-1256, the presence of =9D between characters under
decimal-128 is suspicious
On Wed, 21 Nov 2018, Rupert Gallagher wrote:
On Wed, Nov 21, 2018 at 03:41, John Hardin wrote:
On Tue, 20 Nov 2018, Rupert Gallagher wrote:
The email address is an address, part of your personally identifiable
data.
I'm not disputing that. I write software that deals with PII in my day
filtering tool with SA
hooks such that this failure should be reported to *them*?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
l presence outside the US.
On Tue, Nov 20, 2018 at 17:03, John Hardin wrote:
On Tue, 20 Nov 2018, Rupert Gallagher wrote:
Yes, if you are European, and might get some money as compensation.
From a US political advocacy group which has no commercial presence in EU?
How does GDPR apply in that
do "> 2")
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D82
?
Multiply everything by 10:(__rulename * 4) ...etc... > 10
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2
On Tue, 20 Nov 2018, RW wrote:
On Mon, 19 Nov 2018 13:31:47 -0800 (PST)
John Hardin wrote:
On Mon, 19 Nov 2018, Joseph Brennan wrote:
Example: Obvi=9Do=9Dusly yo=9Du=9D ca=9Dn can cha=9Dnge=9D i=9Dt
In windows-1256, the presence of =9D between characters under
decimal-128 is suspicious
as
well.
While I can just dump their mail, it offends my finely hones sense of
propriety, justice and my all around good nature. Besides, it hoses me off.
So, is there some "authority" to which I can report these a**holes? that might
have an effect?
--
John Hardin KA7OHZ
blackmail spam.
...probably for this reason.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
ip" M.
---
{snip}
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6
On Sat, 17 Nov 2018, David Jones wrote:
On 11/17/18 9:52 AM, John Hardin wrote:
From: John D. Smith
To: kdeu...@vianet.ca
Message-ID: <35706717752563516902.8f4660866aa84...@vianet.ca>
Couple of things:
1. Recent discussions on this mailing list showed me that the Message-ID
should
don't cause a problem
blocking a real invoice in the first month or two as you are tuning your
rules and scores.
Good suggestions.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D
...
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
From
, though.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
On Thu, 15 Nov 2018, Amir Caspi wrote:
On Nov 15, 2018, at 2:36 PM, John Hardin wrote:
It doesn't seem to have a very high score just yet... I'm still getting FNs
with the rule hitting (due to those messages hitting BAYES_00/05).
Manually train those messages as spam and that should
On Thu, 15 Nov 2018, Amir Caspi wrote:
On Nov 15, 2018, at 2:36 PM, John Hardin wrote:
That and its resistance to FP avoidance.
Despite the generality, I don't see a significant FP risk on the general unicode version.
I don't see ANY legitimate reason why an email would hard-encode long
common answer to that question is: you're training to a different
Bayes database than spamassassin is using during message processing.
What is your glue - how is SA hooked into your MTA?
What user is SA (typically spamd) running under?
What user are you logged in as for training?
--
John Hardin
On Thu, 15 Nov 2018, Amir Caspi wrote:
On Nov 10, 2018, at 11:30 AM, John Hardin wrote:
The rawbody rules perform much better (unsurprising), and the ASCII-only one
has a better raw S/O:
It looks like HTML_ENTITY_ASCII has been rolled out -- did you decide
against the more general
adecimal sequence
It's not "is pure hex", it's "contains long hex".
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 13
On Sun, 11 Nov 2018, John Hardin wrote:
On Sat, 10 Nov 2018, listsb wrote:
what am i misunderstanding?
Is there some possibility that you're stripping external Received headers?
(grasping at straws here)
Heh. Ignore that. I have *got* to learn to catch up *before* replying to
stuff
On Sat, 10 Nov 2018, listsb wrote:
On Nov 10, 2018, at 21.01, John Hardin wrote:
On Sat, 10 Nov 2018, listsb wrote:
i've just noticed that every mail received seems to be hitting the ALL_TRUSTED
test [ALL_TRUSTED=-1], regardless of where the message has come from. i have
the following
!= trusted_networks.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
On Fri, 9 Nov 2018, John Hardin wrote:
On Fri, 9 Nov 2018, John Hardin wrote:
On Fri, 9 Nov 2018, Amir Caspi wrote:
I'd be interested to know if there's a performance difference between my
two proposed rules. I suspect the second should run (slightly) faster.
It looks that way - only
On Fri, 9 Nov 2018, John Hardin wrote:
On Fri, 9 Nov 2018, Amir Caspi wrote:
I'd be interested to know if there's a performance difference between my
two proposed rules. I suspect the second should run (slightly) faster.
It looks that way - only .0001s difference on *some* messages.
Re
On Fri, 9 Nov 2018, Amir Caspi wrote:
On Nov 9, 2018, at 8:49 AM, John Hardin wrote:
rawbody HTML_ENC_ASCII
/(?:&\#(?:(?:\d{1,2}|1[01]\d|12[0-7])|x[0-7][0-9a-f])\s*;\s*){10}/i
I'll add that too so that we can compare the results.
Per my reply a few minutes ago, I t
s are <5 points.
I think we have a winner. Thanks, Amir (and possibly RW)!
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E
On Thu, 8 Nov 2018, Bill Cole wrote:
On 8 Nov 2018, at 21:55, John Hardin wrote:
On Thu, 8 Nov 2018, Amir Caspi wrote:
On Nov 8, 2018, at 7:41 PM, John Hardin wrote:
Sure, but I't also prefer to have a sample to test on before committing.
I'll see if I can get the pastebin to work (i.e
On Thu, 8 Nov 2018, Amir Caspi wrote:
On Nov 8, 2018, at 7:55 PM, John Hardin wrote:
I left it case-sensitive; is there some reason the entities cannot be coded as
(e.g.) ? I kinda doubt it, so it should *probably* be case-insensitive
to avoid trivial bypass.
I think it should
On Thu, 8 Nov 2018, Amir Caspi wrote:
On Nov 8, 2018, at 7:41 PM, John Hardin wrote:
Sure, but I't also prefer to have a sample to test on before committing. I'll
see if I can get the pastebin to work (i.e. fix the boundary)
I can send you some new spamples via attachment, privately
z0-9#]{2,};\s*){20}
Either should work, I believe.
Cheers.
--- Amir
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B
behind like this? Are they suffering
from resource shortages (e.g. in the feeds and evaluation teams)?
Just curious.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411
On Sun, 4 Nov 2018, John Hardin wrote:
Why is your system doing that?
...never mind, explained in a later post.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411
blocks my named now, i cant resolve any cf domains with it
Why is your system doing that?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6
be considered.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
On Tue, 30 Oct 2018, RW wrote:
On Tue, 30 Oct 2018 17:27:18 +0200
Jari Fredriksson wrote:
John Hardin kirjoitti 24.10.2018 kello 18.10:
As was suggested earlier, disable auto-expiry and run a cron job to
expire Bayes tokens.
I seem to have auto expiry on, but have not seen any problems
roblem with this approach is the *presence* of such characters is a
pretty strong spam sign.
Potentially those tests could be moved to RAWBODY rules, though - I'll
investigate that for the ZW rule.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impse
On Mon, 29 Oct 2018, Emanuel Gonzalez wrote:
Hi.!!
the permits of the directory are correct:
ll -d /.spamassassin/
drwxrwxr-x 2 nobody nobody 63 oct 29 08:54 /.spamassassin/
The parameter bayes_auto_learn is set to "0".
The advice was for auto *expire*.
--
John Har
u have any idea how to solve it?
As was suggested earlier, disable auto-expiry and run a cron job to expire
Bayes tokens.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C
bayes_learn_to_journal 1
bayes_auto_learn 0
you may need to set
bayes_auto_expire 0
and do your expiry from cron using sa-learn
This is best practice, yes.
What are the permissions on the files themselves?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org
changes to reduce the overlap in the FRNAME rules. The
reason they are scoring that high even with overlap is those are strong
spam signs in the masscheck corpus.
And: Bayes and TxRep did exactly what they are supposed to do here.
--
John Hardin KA7OHZhttp://www.impsec.org
that.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
If stress
On Sat, 20 Oct 2018, Kevin A. McGrail wrote:
John, check out haveibeenpwned.com and see if this breach is listed. Great
site.
LJ does not appear to be listed.
On Sat, Oct 20, 2018, 13:54 John Hardin wrote:
All:
This isn't as far as I can tell getting publicitly yet, but I just got
immediately.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
the possibility.
Yup.
It's only hitting 80 spams and one ham in the current masscheck corpora.
If it *is* causing FPs, please report here it as such and I'll reduce the
score limit. It was hitting more when it was first created.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin
says possible phishing, but how would an end-user
be in a position to create a public link that involves their WP admin
directory in the first place?
It's generally a sign of a hacked server.
However, 3 points may be extreme given it's hitting only 0.0280% of spam
--
John Hardin KA7OHZ
be done for attachhed .doc, .pdf files etc.
...which would be much more reliable than OCR.
If it was a resource-allocation decision for pulling text from doc/pdf vs.
updating OCR, I'd push for the former.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org
technology and method.
Thanks in advance.
Regards
Brent
P.s. Here is a pastebin link of what I am seeing.
https://pastebin.com/raw/gurvFrZw
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key:
archives for Postfix and RBL, there have been
discussions and good suggestions for weighted multi-RBL checks before.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411
SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Mon, Oct 8, 2018 at 11:18 AM John Hardin wrote:
On Mon, 8 Oct 2018, Chuck McManis wrote:
I have been trying to tune scores to achieve better matches with spam
that
is getting through. And one test which shows up
is *very* low
in the masscheck corpora - 0.114 - 4% spam hits vs. 31% ham hits.
You might want to be careful if you intend to treat that as a poison pill
by itself...
I'll take a look at whether its performance can be improved.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin
angerous. "*" in a body rule opens you to DoS attacks.
I recommend \W{0,10}instead of \W* to reduce that exposure.
Also, it's a bit more efficient to not use capturing parens if you're not
going to do anything with the match:
/\b\W*(?:w\W*e\W*b\W*)?c\W*a\W*m\W*(?:e\W
On Sat, 6 Oct 2018, Pedro David Marco wrote:
On Saturday, October 6, 2018, 8:36:11 PM GMT+2, John Hardin
wrote:
The version of this in my sandbox doesn't have that weakness. I did some
tuning compared to what Steve proposed.
John, would it be possible for you to share with us those
s appear to be going to the list multiple times (or
is that just me?)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B
On Fri, 5 Oct 2018, Zinski, Steve wrote:
Yes, absolutely.
OK, cleaned up a bit and checked in. We'll see what masscheck thinks...
On 10/5/18, 1:42 PM, "John Hardin" wrote:
On Fri, 5 Oct 2018, Zinski, Steve wrote:
> Here's how I'm blocking bitcoin emails with Unico
On Fri, 5 Oct 2018, sebast...@debianfan.de wrote:
https://pastebin.com/TRD7FzRQ
i have a sample here
There doesn't appear to be any obfuscation (apart from the email address)
in that message...
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org
" Bah.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6
de glyph. It's not bitcoin-specific.
With your permission I can add that to my sandbox and see how it does in
masscheck.
On 10/5/18, 10:54 AM, "John Hardin" wrote:
On Fri, 5 Oct 2018, Pedro David Marco wrote:
> >On Thursday, October 4, 2018, 9:08:10 PM GMT+2,
x last night...
Initial results aren't too promising.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B87
p a local, recursive,
***NON-FORWARDING*** DNS server for the use of SA (and likely their MTA).
Searching for URIBL_BLOCKED in the mailing list archives will cover it in
*excruciating* detail. It's a VFAQ.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@imp
+ __MG_LOT2 ) > 1.5 )
scoreMG_LOTTO 2.0
This rule has been around and working as expected for several years.
Looks like the lint got broken, then, and needs to accept decimal
numbers...
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaho
On Fri, 7 Sep 2018, Matus UHLAR - fantomas wrote:
For now, I believe that using (ALL_TRUSTED && __DOS_SINGLE_EXT_RELAY)
is just what I need to prevent all rules from firing:
I think you mean !ALL_TRUSTED, right?
Will digest and comment on the rest in a bit.
--
John Hardi
If anyone here works for Cloudflare or has high-level personal contacts
there, could you contact me offlist? Thanks!
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4
401 - 500 of 3243 matches
Mail list logo
