for them to reel in victims via that contact address.
The fact that after five months of reporting that contact address they are
still using it to lure victims strongly suggests to me that google is
ignoring such reports.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin
On Sat, 24 Oct 2020, Benny Pedersen wrote:
John skrev den 2020-10-24 21:30:
A regular source of spam is outlook.com;
is spamassassin say is not spam ?
in that case:
blacklist_from *@outlook.com
...and then whitelist specific desireable-correspondent outlook.com
addresses.
--
John
to pastebin and post their URIs
here so that we can see what they look like, that would be very helpful.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76
Thanks
Tim Wetterek Andersson
Digitaliseringsavdelningen, Norrköpings kommun
Telefon/SMS: +46725935115
-Ursprungligt meddelande-
Från: John Hardin
Skickat: den 22 september 2020 19:51
Till: users@spamassassin.apache.org
Ämne: Re: Character encoding in Report Templates
On Tue, 22 Sep 2020, Tim We
out actual samples of the spam, there's nothing anyone else can do to
help figure out why SA isn't catching it and how it might get caught.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E
/spamassassin Riccardo and see no extra
'.' anywhere.
Do you find a urirhssub line for {anything}dbl.dq.spamhaus.net there?
Did you check *all* of the local .cf files?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk
the cause, then it might be worthwhile to open a bug to
strip leading dot(s) from urirhssub config lines to avoid this, or at
least generate a lint warning if they are present.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pg
On Tue, 6 Oct 2020, Chris wrote:
On Tue, 2020-10-06 at 18:54 -0700, John Hardin wrote:
On Tue, 6 Oct 2020, Chris wrote:
The complete error looks like this:
spamd[435769]: dns: new_dns_packet
(domain=o279.send.iheartdogs.com..xx/dbl.dq
.spamhaus.net. type=A class
That was converted from a warning to an info, so it looks like your SA
version may be a bit stale.
I don't think we ever pulled the trigger on normalizing ".." ⇒ "." for
URIBL lookups as a URL with a malformed FQDN like that doesn't work in a
browser.
--
John Hardin KA7OHZ
block
connections from hostile ASNs.
Hostile email sources should be TCP tarpitted. :)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
?
If the latter, then the most efficient approach is to tell your MTA to
reject SMTP sessions from that IP block with an appropriate message. Avoid
the SA scanning overhead entirely.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org
On Wed, 23 Sep 2020, Jerry Malcolm wrote:
On 9/23/2020 12:46 PM, John Hardin wrote:
On Wed, 23 Sep 2020, Jerry Malcolm wrote:
I am sending test emails from one of my hosting environments to another of
my hosting environments. I get this line in the SA report:
1.6 FORGED_MUA_MOZILLA
On Wed, 23 Sep 2020, Grant Taylor wrote:
On 9/23/20 11:46 AM, John Hardin wrote:
It doesn't believe the Message-ID was generated by Thunderbird. What's the
message ID?
This piques my interest because I tell Thunderbird to use a custom Message-ID
domain.
Where can I read more about what
from Mozilla. But it is not
forged mail pretending to be from Mozilla.
What is triggering this?
meta FORGED_MUA_MOZILLA (__MOZILLA_MUA && !__UNUSABLE_MSGID &&
!__MOZILLA_MSGID)
It doesn't believe the Message-ID was generated by Thunderbird. What's the
message ID?
verbatim? Explicit
hex values shouldn't be needed. See the report lines of this for example:
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TranslateFrench
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...
for compromised sendgrid user IDs. See the thread
starting at:
https://marc.info/?l=spamassassin-users=159803815425176=2
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411
(zipped,
with all message headers intact) then I might be able to do a better job
of that.
As a workaround, you could whitelist the spiceworks.com help desk email
address.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org
On Mon, 14 Sep 2020, Bill Cole wrote:
On 14 Sep 2020, at 11:22, John Hardin wrote:
On Mon, 14 Sep 2020, Philipp Ewald wrote:
Does anyone else checks the HELO/ELHO?
I don't check for FCrDNS explicitly, but I do reject non-FQDN HELO strings
(e.g. no dots present) from the Internet
On Mon, 14 Sep 2020, Philipp Ewald wrote:
Does anyone else checks the HELO/ELHO?
I don't check for FCrDNS explicitly, but I do reject non-FQDN HELO strings
(e.g. no dots present) from the Internet. That catches a surprising
percentage of garbage up front.
--
John Hardin KA7OHZ
hat MTA you're using, perhaps the list can provide
suggestions for that approach.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76
On Tue, 25 Aug 2020, Rob McEwen wrote:
On 8/25/2020 11:04 PM, John Hardin wrote:
I just wrote something similar to generate a rule, in case for some reason
you don't want to use a plugin. Let me know if there's any interest in it.
yes - please share!
http://www.impsec.org/~jhardin
a rule, in case for some reason
you don't want to use a plugin. Let me know if there's any interest in it.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C
On Mon, 24 Aug 2020, micah anderson wrote:
John Hardin writes:
On Mon, 24 Aug 2020, Marc Roos wrote:
You should use spf for this.
Duh.
+1
whitelist_auth *@amazon.com
blacklist_from *@amazon.com
whitelist_auth *@*.amazon.com
blacklist_from
On Mon, 24 Aug 2020, Martin Gregorie wrote:
On Mon, 2020-08-24 at 11:51 -0700, John Hardin wrote:
Might want some \b in there, just to be safe. The from check would
also
hit domains like "amazon-river.org". Perhaps:
header SUBRULE13a From:name =~ /\bAmazon\b/
header SUBRULE13b
On Mon, 24 Aug 2020, Marc Roos wrote:
You should use spf for this.
Duh.
+1
whitelist_auth *@amazon.com
blacklist_from *@amazon.com
whitelist_auth *@*.amazon.com
blacklist_from *@*.amazon.com
--
John Hardin KA7OHZhttp
ays has
"amazon" in the sender name. Perhaps:
meta SUBRULE13 SUBRULE13a && !SUBRULE13b
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F
On Fri, 21 Aug 2020, John Hardin wrote:
On Fri, 21 Aug 2020, John Hardin wrote:
On Fri, 21 Aug 2020, Kenneth Porter wrote:
--On Thursday, August 20, 2020 5:30 PM -0700 John Hardin
wrote:
Fix committed.
Where will this show up?
It will probably be published tonight.
I just got one
On Fri, 21 Aug 2020, John Hardin wrote:
On Fri, 21 Aug 2020, Kenneth Porter wrote:
--On Thursday, August 20, 2020 5:30 PM -0700 John Hardin
wrote:
Fix committed.
Where will this show up?
It will probably be published tonight.
I just got one with this tag:
Another:
OK
On Fri, 21 Aug 2020, Kenneth Porter wrote:
--On Thursday, August 20, 2020 5:30 PM -0700 John Hardin
wrote:
Fix committed.
Where will this show up?
It will probably be published tonight.
I just got one with this tag:
Another:
OK, it doesn't catch those. One more fix coming
don't seem to
catch this.
lzdtec
On Fri, 21 Aug 2020, Matus UHLAR - fantomas wrote:
I have noticed those some time ago.
I wonder what's the point of sending such mail.
On 21.08.20 09:21, John Hardin wrote:
It's an attempt to obstruct spam detection via naïve text matching in the
raw HTML
r to avoid arousing
suspicion.
The other approach (as reported here) is to break up the body text like
so:
spammy words
Scanning for "spammy words" in the raw HTML is defeated, but rendering the
text as the user would see it before doing the scanning yields:
spammy text
...which hi
being scanned.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
On Thu, 20 Aug 2020, John Hardin wrote:
On Thu, 20 Aug 2020, Loren Wilton wrote:
I've started receiving a bunch of spam or more likely phish mails that
contain the following sort of trash in large quantities between almost
every word of the visible text. The invisible font rules don't seem
on it... Thanks.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
assin
--lint" in a loop, oncxe for each plugin.
On Tue, Aug 11, 2020, 00:09 John Hardin wrote:
On Mon, 10 Aug 2020, Kevin A. McGrail wrote:
Yeah, I saw that. It's *possible* that I don't see the problem because
I'm running my sandbox lint tests against trunk, where the
capabilities do
-update or a lint check.
What the heck, then? I wonder why I'm not getting that error...
--
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
On Mon, 10 Aug 2020, Matthias Rieber wrote:
Hello John,
On Fri, 7 Aug 2020, John Hardin wrote:
On Fri, 7 Aug 2020, Matthias Rieber wrote:
I'm wondering if the linter is supposed to respect the ifplugin statement.
I've disabled the Mail::SpamAssassin::Plugin::WLBLEval module and this
leads
that.
Are you sure the plugin is really disabled?
--
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 Wed, 5 Aug 2020, Guido Goluke, MajorLabel wrote:
Sorry, I have no idea what you mean by 'backscatter' or 'making the problem
bigger for the world'.
https://duckduckgo.com/?q=email+backscatter
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.org
On Mon, 3 Aug 2020, John Wilcock wrote:
On 2020-08-01 21:23, bugzilla-dae...@spamassassin.apache.org wrote:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #58 from Kevin A. McGrail ---
(In reply to John Hardin from comment #57) (In reply to Kevin A. McGrail from
ther.
If this project was being written from scratch, "red", "amber" and "green"
*would* be appropriate terminology to use for the concepts.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar
ge
itself?
If not, what is to prevent a spammer from obtaining all the needed
certificates, and then changing the logo image they are hosting to match
the entity they are spoofing?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pg
On Wed, 22 Jul 2020, Charles Sprickman wrote:
Rather than tolerate the tiniest of changes you throw a tantrum.
This is not a tiny change. I had hoped it would be, which is why I
supported it in the initial PMC vote, but it's becoming clear to me I was
overly optimistic.
--
John Hardin
hedge
by saying "(potentially) subject to renaming".
--
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
A 4.0 (i.e. it will not be dropped before the
first release occurring after that year has passed).
--
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
and are currently disabled; they are
included for completeness.)
It would be helpful if we could be informed whether anyone has post-SA
processing that looks for these rulenames in the SA hit results, e.g. for
making message delivery decisions.
Thank you.
--
John Hardin KA7OHZhttp
re working on addressing this, it should be a temporary
condition.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4
--
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 one
* reason for the change, and there are good
technical reasons for *not* making the change (at least, not
precipitously).
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411
1000 BC in chinese culture yin
yang ;)
Oooo, *good* point.
--
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 Sat, 11 Jul 2020, jdow wrote:
I do not demand 50% of my peers be women. I simply demand that 100% of
my peers carry their load. For THAT I am a racist fascist.
Snarf!
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk
. This should help minimize the disruption when
4.0 is released with the new configuration options.
Regards,
KAM
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C
On Fri, 10 Jul 2020, jdow wrote:
And if you REALLY want a hair raising read dig around for a copy of William
Shirer's "The Rise and Fall of the Third Reich." Then tell me there is no
resemblance at all between that and current events.
I *so* do not want to read that book again...
d
Fixing what works is as fine a way to introduce new faults in
the code as I can think of.
I am rethinking my +1 vote for this change.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E
otentially backtrack over.
I suggest the positive match first, then the negative match, as the
positive match will probably occur in only a small percentage of URIs
scanned and will thus generally fail and shortcircuit the evaluation of
the (much more likely to hit) negative lookforward matc
he (?=...)(?!...) construct is better.
--
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 Wed, 1 Jul 2020, Aner Perez wrote:
On 7/1/20 3:52 PM, John Hardin wrote:
On Wed, 1 Jul 2020, Aner Perez wrote:
I opened a bug (7832) about this but was told to report on the SA users
mailing list instead.
The attached email is an example which triggers the HK_SCAM rule. Looks
like
the URL
to it here. (In this case, your description should probably be enough to
figure it out without the sample so you shouldn't need to do that unless
someone explicitly asks you to do so.)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALah
at's *too* generous) for
the TLDs (or if possible the specific domains in those TLDs) that are
causing problems.
I realize this isn't really a welcome solution per the original note but
until the legitimate use of those TLDs grows the rules punishing them do
have value.
--
John Hardin KA
away.
They do, however, apparently care about phishing - they did disable the
sendgrid redirect that some phisher has been spamming at me for the last
three weeks.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar
On Fri, 19 Jun 2020, micah anderson wrote:
John Hardin writes:
On Fri, 19 Jun 2020, micah anderson wrote:
So, what can I do to tweak these rules to score things up more,
specifically the rules that provide a low false positive rate[1]. This
seems something that should be done
in the last 24-48 hours?
Potentially relax it a bit by collecting on /30 or /28 netblocks instead
of individual /32 IP addresses.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79
t
feature isn't fairly common in spam that makes it into the masscheck repos
then the rule might not be performing well enough to be promoted for
publication.
Adjusting the spam threshold is generally only something you do if you
really understand what's going on.
--
John Hardin KA7OHZ
/\s(?!mazon)/i
replace_rules FUZZY_AMAZON
describe FUZZY_AMAZON Obfuscated "Amazon"
endif
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411
too.
Bayes (after training) should help a lot with those if they contain
obfuscated words.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4
Does any list denizen have direct connections into Yahoo?
Their abuse@ and postmaster@ addresses have been undeliverable for a week
or two, apparently due to a misconfiguration. I've tried reporting it via
their web page but haven't gotten any response yet.
--
John Hardin KA7OHZ
On Wed, 27 May 2020, LuKreme wrote:
On May 27, 2020, at 20:08, John Hardin wrote:
On Wed, 27 May 2020, @lbutlr wrote:
On 27 May 2020, at 18:27, RW wrote:
I should have added that if whitelist_from_rcvd *@* server.example.com
(without the colon) is only only failing occasionally on mail
to skip SA entirely for that IP.
--
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
.
You'll need to provide more-specific information about which MTA you're
using before we can provide more-specific advice than that.
Also be aware: "short-circuit" in the SA context doesn't *quite* mean what
you're asking.
--
John Hardin KA7OHZhttp://www.impsec.or
On Thu, 7 May 2020, RW wrote:
On Thu, 7 May 2020 11:39:07 -0700 (PDT)
John Hardin wrote:
100% 4-byte UTF8? That should be trivially easy to detect.
Comments solicited.
body __4BYTE_UTF8_WORD
/(?:\xf0\x9d[\x9a-\x9f][\x80-\xff]){3,10}/ tflags
__4BYTE_UTF8_WORD multiple, maxhits
ting the bitcoin wallet ID.
--
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
phs that render readable
English text.
--
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
a token in Bayes as
causing an automatic 1.000 then that might be a usable approach.
(Granted, it's not encrypted.)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507
On Mon, 4 May 2020, Grant Taylor wrote:
On 5/4/20 2:51 PM, John Hardin wrote:
*if* they are being actively used for authentication, either by the
security system (which is a glaring flaw in the design of the security
system) or as a reference for accessing the secured resource (e.g
~= /\x50\x40\x73\x73\x77\x30\x72\x7c\x29/
...which would at least not have the password trivially visible in plain
text for anyone who can read the config file. (You'd of course, not use a
rule name that indicated it was about a password.)
--
John Hardin KA7OHZhttp://www
t's what I do.
--
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
. {rolleyes}
--
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
nd getting scores for both hits is totally legitimate.
--
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
-types-and-meaning/
I guess the definition of __BITCOIN_ID needs to updated to include this
format. Thanks.
Underway.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4
mail
can be more reliably determined to actually *be* from that domain?
If not, implementing that may be a benefit. Then you can score higher any
mail from that domain that is NOT signed or that fails SPF...
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@
iter lock, just write locks for the toks and seen
files. As scans defer their writes through the journal they are
lockless.
So, auto-training may be problematic w/r/t locking as well. I presume that
window is coded to be as small as possible.
--
John Hardin KA7OHZ
in "EXclusive mode", hence when a
sa takes too long, all other processes have to wait for the lock...
This is my config:
use_bayes 1bayes_path /etc/spamassassin/bayes/bayesbayes_auto_learn
0bayes_auto_expire 0lock_method flock
Turn off Bayes auto-expire and do that in a cron job.
On Fri, 7 Feb 2020, Kenneth Porter wrote:
--On Thursday, February 06, 2020 2:30 PM -0800 John Hardin
wrote:
The RPM is available here, assuming you trust me:
http://www.impsec.org/~jhardin/antispam/centos7/
3.4.4 is now available as well, I've been running it for about a day now
and I
On Thu, 6 Feb 2020, Amir Caspi wrote:
On Jan 11, 2020, at 11:14 AM, John Hardin wrote:
I found one very minor modification was needed: the spec file requires
"perl-interpreter" and that doesn't seem to see the "perl" package
installed under Centos 7.
Ah, now I rec
On Sat, 11 Jan 2020, John Hardin wrote:
On Thu, 9 Jan 2020, Amir Caspi wrote:
On Jan 9, 2020, at 6:59 PM, Rick Gutierrez wrote:
Hi everyone, someone from the list who can share the rpm of the
latest version of spamassassin for centos 7 and 6 of x64, I want to
update to the latest version
e: 4.351
X-Spam-Level:
X-Spam-Status: No, score=4.351 tagged_above=-9 required=6.31
That a given rule hits on some ham does not make the rule a FP. This rule
is working as designed.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaho
get upates"?
are you aware that some distro maintainers prefer to backport security fixes
to former versions to prevent from functional surprises?
Then they would presumably backport the SHA-256 checksum handling, as
it is a security issue...
--
John Hardin KA7OHZhttp:
, is it that hard to provide sha-1 signatures together with sha256?
It's not hard to do that. It's insecure.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C
heir mail client (or bulk mail tool if it's a bulk mail).
--
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
e here, assuming you trust me:
http://www.impsec.org/~jhardin/antispam/centos7/
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76
from those IP
addresses, add them to an IP blacklist in your MTA so they get rejected up
front. Why accept the SA processing overhead?
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79
On Sat, 4 Jan 2020, John Hardin wrote:
On Fri, 3 Jan 2020, RW wrote:
On Fri, 3 Jan 2020 15:29:40 -0700
Philip Prindeville wrote:
On Jan 3, 2020, at 11:34 AM, RW wrote:
On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:
Try this instead, to actually match the header(s
On Fri, 3 Jan 2020, RW wrote:
On Fri, 3 Jan 2020 15:29:40 -0700
Philip Prindeville wrote:
On Jan 3, 2020, at 11:34 AM, RW wrote:
On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:
Try this instead, to actually match the header(s):
header __L_RECEIVED_SPF Received-SPF
On Fri, 3 Jan 2020, Philip Prindeville wrote:
On Jan 3, 2020, at 11:34 AM, RW wrote:
On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:
On Fri, 3 Jan 2020, Pedro David Marco wrote:
header __L_RECEIVED_SPFexists:Received-SPF
tflags __L_RECEIVED_SPFmultiple
SPF 20.0
but it never seems to match.
"exists" is a boolean, it's reasonable that it only returns one hit
regardless of the number of instances present.
Try this instead, to actually match the header(s):
header __L_RECEIVED_SPF Received-SPF =~ /^./
--
John
ge the
hash without noticeably changing it visually.
It might be prohibitive to do that per-message, but sending a batch of a
hundred messages while you're modifying the image for the next batch would
probably work.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@imp
On Wed, 18 Dec 2019, Lindsay Haisley wrote:
I've been getting a lot of spams here with a format similar to:
[snip]
d171f2b7-af04-5a8-5a8-cee259c46b8f
9fc2adda-9160-c56-c56-feadd16b0acc
cec5f152-fd8b-9a9-9a9-c5e5c0e676cb
3aaf4ded-e0ec-31d-31d-efec2dbb3f8a
b4804f85-ac57-2d2-2d2-f1c275fd8a0f
created.
This sounds more like the "does that tuple already exist?" logic is
failing, causing it to think it needs to create a new entry, which the
unique key is (correctly) preventing.
You don't lightly bypass unique keys. They are there for a reason.
--
John Hardin KA7OHZ
I'm open to suggestions. Reverting for 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
of the
attachment?
2) Is the longer scan time of the 'bounce' message due to SpamAssassin
scanning the attachment text lines in a way that it normally would not if it
had recognized that it is an attachment?
Question: was the message attached to the bounce *complete*? Or was it
truncated?
--
John Hardin
201 - 300 of 3243 matches
Mail list logo
