Re: Two types of new spam

2020-01-02 Thread Lindsay Haisley 
On Thu, 2020-01-02 at 16:08 -0700, Philip Prindeville wrote:
> I’m getting the following Spam.
> 
> http://www.redfish-solutions.com/misc/bluechew.eml
> 
> And this is notable for having:
> 
> 
> 
> GUID1
> GUID2
> GUID3
> GUID4
> …
> 

I've also been getting a number of these, and someone else on this list
reported the same format. I haven't seen a SA rules solution to
blocking these.

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson

Two types of new spam

2020-01-02 Thread Philip Prindeville 
I’m getting the following Spam.

http://www.redfish-solutions.com/misc/bluechew.eml

And this is notable for having:



GUID1
GUID2
GUID3
GUID4
…


so it should be easy enough to detect.

A GUID looks like:

[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{3}-[0-9a-f]{3}-[0-9a-f]{12}

The 2nd type of Spam I’m seeing looks like:

http://www.redfish-solutions.com/misc/received-spf.eml

which contains:

Received: from mta.amapspa.it ([127.0.0.1])
by localhost (mta.amapspa.it [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id U5M-E2lVwWem; Sat,  2 Nov 2019 00:19:36 +0100 (CET)
Received-SPF: none (amapspa.it: No applicable sender policy available) 
receiver=mta.amapspa.it; identity=mailfrom; 
envelope-from="dario.scarpu...@amapspa.it"; helo="[91.134.159.128]"; 
client-ip=91.134.159.128
Received-SPF: none (amapspa.it: No applicable sender policy available) 
receiver=mta.amapspa.it; identity=mailfrom; 
envelope-from="dario.scarpu...@amapspa.it"; helo="[91.134.159.128]"; 
client-ip=91.134.159.128
Received-SPF: none (amapspa.it: No applicable sender policy available) 
receiver=mta.amapspa.it; identity=mailfrom; 
envelope-from="dario.scarpu...@amapspa.it"; helo="[91.134.159.128]"; 
client-ip=91.134.159.128
…

with that line being repeated some 40 times, each line being identical.

I tried a rule like:

header __L_RECEIVED_SPF exists:Received-SPF
tflags __L_RECEIVED_SPF multiple maxhits=20

meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
describe L_RECEIVED_SPF Crazy numbers of Received-SFP headers
score L_RECEIVED_SPF20.0


but it never seems to match.  I’ve not tried to debug this, but it seems that 
duplicated headers might not be saved as a list into the headers?  (Is there an 
easy way to see what exists:Received-SPF is evaluating as?)

If that’s the case, it would seem to be a shortcoming.

Can anyone confirm that’s indeed what’s happening?

Thanks,

-Philip