On Fri, 16 Apr 2021 23:49:04 -0400
Bill Cole wrote:
> On 16 Apr 2021, at 11:25, Greg Troxel wrote:
>
> > Probably not for normals, score up MPART_ALT_DIFF because nobody
> > should be sending mail with a text/plain part that is not
> > semantically equivalent to the html.
>
> It seem like
On 16 Apr 2021, at 11:25, Greg Troxel wrote:
> Probably not for normals, score up MPART_ALT_DIFF because nobody
> should be sending mail with a text/plain part that is not semantically
> equivalent to the html.
It seem like a bug that this message didn't match MPART_ALT_DIFF.
--
Bill
On 16 Apr 2021, at 16:16, RW wrote:
> On Fri, 16 Apr 2021 11:25:19 -0400 Greg Troxel wrote:
>
>> Probably not for normals, score up MPART_ALT_DIFF because nobody
>> should be sending mail with a text/plain part that is not
>> semantically equivalent to the html.
>
> Unfortunately it's quite
On Fri, 16 Apr 2021, RW wrote:
On Fri, 16 Apr 2021 11:25:19 -0400
Greg Troxel wrote:
Probably not for normals, score up MPART_ALT_DIFF because nobody
should be sending mail with a text/plain part that is not
semantically equivalent to the html.
Unfortunately it's quite common.
+1
On 16 Apr 2021, at 16:03, John Hardin wrote:
> header __FROM_NAME_AMAZONCOM From:name =~ /\bamazon\.com\b/i
> meta POSSIBLE_AMAZON_PHISH_01 (__FROM_NAME_AMAZONCOM && NAME_EMAIL_DIFF)
> meta POSSIBLE_AMAZON_PHISH_02 (__FROM_NAME_AMAZONCOM &&
> !__HDR_RCVD_AMAZON)
It seems
While I haven't received a forged Amazon order email in this exact form,
there is all kinds of stuff here that could be caught with appropriate
rules.
"In-case you require any
change in order or like to cancel we recommend giving us call
immediately at "
"In-case" is unlikely in
On Fri, 16 Apr 2021 11:25:19 -0400
Greg Troxel wrote:
> Probably not for normals, score up MPART_ALT_DIFF because nobody
> should be sending mail with a text/plain part that is not
> semantically equivalent to the html.
Unfortunately it's quite common.
On Fri, 16 Apr 2021, Steve Dondley wrote:
First, thanks to everyone on the list how has given me a hand over the past
couple of weeks as I get my "sea legs" with spamassassin. It's working well
for me now but I obviously still have more to learn.
For one, I'm still uncertain on the best way
On 2021-04-16 17:10, Steve Dondley wrote:
From: "or...@amazon.com"
X-Google-Original-From: "or...@amazon.com"
wow, google accept it
header LOCAL_AMAZON From:Name ~= /^@amazon.com$/
header LOCAL_GMAIL From:Addr ~= /^@gmail.com$/
meta LOCAL_SPOFFED (LocAL_AMAZON && LOCAL_GMAIL)
untested
On Friday 16 April 2021 at 17:26:40, Dave Wreski wrote:
> > And how the hell is google letting this crap flow out of its email
> > service, anyway?
>
> Because they're in the email business, not the email security business.
I would add that Google do spam filtering on *inbound* mail, because
Hi Steve,
As Antony just reported, post these spamples to something like
pastebin.com then provide a link so we can view the raw email.
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
This is the first issue I see - you're likely missing a lot of
additional features of later
My advice
realize that you can't block everything
set up TXREP, including outgoing processing
wait until after you have a week of TXREP data because that will
improve scores of legit mail enough, for the most part, that the
tweaks below and the more aggressive scores from KAM will
On Friday 16 April 2021 at 17:10:14, Steve Dondley wrote:
> First, thanks to everyone on the list how has given me a hand over the
> past couple of weeks as I get my "sea legs" with spamassassin. It's
> working well for me now but I obviously still have more to learn.
>
> For one, I'm still
First, thanks to everyone on the list how has given me a hand over the
past couple of weeks as I get my "sea legs" with spamassassin. It's
working well for me now but I obviously still have more to learn.
For one, I'm still uncertain on the best way to fine tune SA to beat
back some tricky
14 matches
Mail list logo
