Re: Two types of new spam

2020-01-11 Thread Philip Prindeville 



> On Jan 4, 2020, at 11:57 AM, Bill Cole 
>  wrote:
> 
> On 3 Jan 2020, at 17:45, Philip Prindeville wrote:
> [...]
> 
>> One other question that occurs to me: why would we even need > http-equiv=“Content-Type” …> if we already have a Content-Type: header?
> 
> There should be no need.
> 
> With that said, it could be *helpful* if a MUA were to save out the text/html 
> part as a standalone file without including any definitive indication of the 
> file being HTML.


Well, it turns out that a lot of MUA’s (including Apple’s Mail.app) generates 
this.


> 
>> Isn’t that the sign of a broken MUA doing the composition?
> 
> Not broken (except for the fact of generating HTML for email at all, a 
> disease analogous to HSV-1.) It is valid HTML and can be useful in rare 
> circumstances.
> 
>> Is that on its own Spamsign (with all respect to Frank Herbert)?
> 
> Do you consider all mail from Facebook to be spam?


Is that a trick question?

-Philip

Re: Two types of new spam

2020-01-08 Thread Kris Deugau 

Lyle Evans wrote:

Expect to see a lot more of these due to
https://github.com/0x4447/0x4447_product_s3_email/blob/master/README.md


That looks more like Doing It Right(TM), by way of using Amazon's 
outbound relay hosts.


Doing It Wrong(TM) is sending direct-to-MX from your VPS without 
overriding the default .compute.amazon.com rDNS.


-kgd

Re: Two types of new spam

2020-01-07 Thread Lyle Evans 

On 1/3/2020 11:02 AM, Kris Deugau wrote:

Philip Prindeville wrote:

I’m getting the following Spam.

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


Received: from phylobago.mysecuritycamera.org 
(ec2-34-210-5-63.us-west-2.compute.amazonaws.com [34.210.5.63])


I have a local rule adding a couple of points for anything coming 
direct-to-MX from any Amazon compute node, period.


I added this on the basis of Amazon's abuse-reporting web form insisting 
that activity from any given IP may be from many AWS customers over a 
span of a few minutes.  Legitimate mail servers do not randomly change 
sending or receiving domains over this timespan, so therefore, Amazon 
compute nodes should not be sending direct-to-MX, at all, ever.


Reality has intruded and there are in fact static IP assignments in the 
.compute.amazonaws.com tree (as well as ISP customers of ours who have 
websites with webforms on AWS, which send mail to their ISP mailbox - or 
sometimes their domain mailbox that's hosted with us) - otherwise I'd 
have scored the rule a lot higher.


Expect to see a lot more of these due to
https://github.com/0x4447/0x4447_product_s3_email/blob/master/README.md



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Two types of new spam

2020-01-05 Thread Luis E. Muñoz 

On 3 Jan 2020, at 8:02, Kris Deugau wrote:

I have a local rule adding a couple of points for anything coming 
direct-to-MX from any Amazon compute node, period.

⋮
Reality has intruded and there are in fact static IP assignments in 
the .compute.amazonaws.com tree (as well as ISP customers of ours who 
have websites with webforms on AWS, which send mail to their ISP 
mailbox - or sometimes their domain mailbox that's hosted with us) - 
otherwise I'd have scored the rule a lot higher.


AWS offers the option to customize the PTR for elastic IPs. I very 
rarely see spam coming in from AWS ranges, having non-default PTRs. I 
use this to dial back my scoring a bit.


Best regards

-lem

Re: Two types of new spam

2020-01-04 Thread RW 
On Sat, 4 Jan 2020 11:06:41 -0800 (PST)
John Hardin wrote:


> >>> Seems to work either way!  
> >> 
> >> Either should match, but without the /m it should only match once.
> >> 
> >> I just tried it and
> >> 
> >> meta   L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
> >> 
> >> doesn't work without the /m in  __L_RECEIVED_SPF  
> >
> > Odd. I'll have to check that out. Perhaps SA is collapsing multiple
> > headers into a single line internally.  

It a single string rather than a single line, but that is how header
rules work. 

> No, the /m shouldn't be needed. 

As I said, I tested it  (just in case "tflags multiple" changed
anything). It worked as I expected, the debug shows many hits with /m
and only one without it.

> There's a rule counting Apparently-To 
> headers in my sandbox, without the /m, and the meta with the
> threshold does fire.

I presume you mean:

header  __APPARENTLY_TO   Apparently-To =~ /<.*>/

This isn't anchored, so /m is not relevant.

Re: Two types of new spam

2020-01-04 Thread John Hardin 

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):

  header __L_RECEIVED_SPF   Received-SPF =~ /^./


That should be:

header __L_RECEIVED_SPF   Received-SPF =~ /^./m



Seems to work either way!


Either should match, but without the /m it should only match once.

I just tried it and

meta   L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)

doesn't work without the /m in  __L_RECEIVED_SPF


Odd. I'll have to check that out. Perhaps SA is collapsing multiple headers 
into a single line internally.


No, the /m shouldn't be needed. There's a rule counting Apparently-To 
headers in my sandbox, without the /m, and the meta with the threshold 
does fire.


--
 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 most glaring example of the cognitive dissonance on the left
  is the concept that human beings are inherently good, yet at the
  same time cannot be trusted with any kind of weapon, unless the
  magic fairy dust of government authority gets sprinkled upon them.
   -- Moshe Ben-David
---
 305 days until the Presidential Election

Re: Two types of new spam

2020-01-04 Thread John Hardin 

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 =~ /^./


That should be:

header __L_RECEIVED_SPF   Received-SPF =~ /^./m



Seems to work either way!


Either should match, but without the /m it should only match once.

I just tried it and

meta   L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)

doesn't work without the /m in  __L_RECEIVED_SPF


Odd. I'll have to check that out. Perhaps SA is collapsing multiple 
headers into a single line internally.


--
 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
---
  Anyone who uses the word "profit" as a dirty word should be
  watched very, very carefully. If they hate the idea of gain
  through free trade it can only mean that they’re looking to
  get it through robbery. -- Lyle@Ultimak
---
 305 days until the Presidential Election

Re: Two types of new spam

2020-01-04 Thread Bill Cole 

On 3 Jan 2020, at 17:45, Philip Prindeville wrote:
[...]

One other question that occurs to me: why would we even need http-equiv=“Content-Type” …> if we already have a Content-Type: 
header?


There should be no need.

With that said, it could be *helpful* if a MUA were to save out the 
text/html part as a standalone file without including any definitive 
indication of the file being HTML.



Isn’t that the sign of a broken MUA doing the composition?


Not broken (except for the fact of generating HTML for email at all, a 
disease analogous to HSV-1.) It is valid HTML and can be useful in rare 
circumstances.



Is that on its own Spamsign (with all respect to Frank Herbert)?


Do you consider all mail from Facebook to be spam?

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Re: Two types of new spam

2020-01-04 Thread John Hardin 

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 maxhits=20

meta L_RECEIVED_SPF(__L_RECEIVED_SPF >= 10)
describe L_RECEIVED_SPFCrazy numbers of Received-SFP headers
score L_RECEIVED_SPF20.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 =~ /^./


That should be:

header __L_RECEIVED_SPF   Received-SPF =~ /^./m



Seems to work either way!


The /m shouldn't be needed given the "tflags multiple". It would be needed 
if you were doing it in a plain "headers ALL =~ /.../" rule that wanted to 
look at multiple headers without "tflags multiple" (which is a valid 
different way to do it, but the "tflags multiple" approach is easier).


--
 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
---
  Anyone who uses the word "profit" as a dirty word should be
  watched very, very carefully. If they hate the idea of gain
  through free trade it can only mean that they’re looking to
  get it through robbery. -- Lyle@Ultimak
---
 305 days until the Presidential Election

Re: Two types of new spam

2020-01-03 Thread RW 
On Fri, 3 Jan 2020 16:21:21 -0700
Philip Prindeville wrote:

> rawbody __L_UNNEEDED_META_CT  /^ /m
> 
> meta T_BLOCK_MISC47   __L_UNNEEDED_META_CT
> describe T_BLOCK_MISC47   Why do this when a
> Content-Type: header works? score T_BLOCK_MISC47  20.0
> 
> And that seems to work.

I found that 9.5% of my ham matches that regex.

Re: Two types of new spam

2020-01-03 Thread RW 
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 =~ /^./  
> > 
> > That should be: 
> > 
> > header __L_RECEIVED_SPF   Received-SPF =~ /^./m  
> 
> 
> Seems to work either way!

Either should match, but without the /m it should only match once.

I just tried it and 

meta   L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)

doesn't work without the /m in  __L_RECEIVED_SPF

Re: Two types of new spam

2020-01-03 Thread Philip Prindeville 



> On Jan 3, 2020, at 3:45 PM, Philip Prindeville 
>  wrote:
> 
> 
> 
>> On Jan 2, 2020, at 4:08 PM, 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
>> …
>> 
> 
> One other question that occurs to me: why would we even need  http-equiv=“Content-Type” …> if we already have a Content-Type: header?
> 
> Isn’t that the sign of a broken MUA doing the composition?  Is that on its 
> own Spamsign (with all respect to Frank Herbert)?
> 
> -Philip
> 


With that in mind, I’m trying out:

rawbody __L_UNNEEDED_META_CT/^\n\n([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{3}-[0-9a-f]{3}-[0-9a-f]{12}\n){10,1000}<\/style>\n/s

and couldn’t get that to match… not sure why.  A way to enable dumping what’s 
matched the pattern buf would be handy.

But this does match:

rawbody __L_STYLE_W_GUIDS

Re: Two types of new spam

2020-01-03 Thread Philip Prindeville 



> On Jan 2, 2020, at 4:08 PM, 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
> …
> 

One other question that occurs to me: why would we even need  if we already have a Content-Type: header?

Isn’t that the sign of a broken MUA doing the composition?  Is that on its own 
Spamsign (with all respect to Frank Herbert)?

-Philip

Re: Two types of new spam

2020-01-03 Thread Philip Prindeville 



> 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 maxhits=20
>>> 
>>> meta L_RECEIVED_SPF(__L_RECEIVED_SPF >= 10)
>>> describe L_RECEIVED_SPFCrazy numbers of Received-SFP headers
>>> score L_RECEIVED_SPF20.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 =~ /^./
> 
> That should be: 
> 
> header __L_RECEIVED_SPF   Received-SPF =~ /^./m


Seems to work either way!

Thanks, everyone.

-Philip

Re: Two types of new spam

2020-01-03 Thread RW 
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_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_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 =~ /^./

That should be: 

header __L_RECEIVED_SPF       Received-SPF =~ /^./m

Re: Two types of new spam

2020-01-03 Thread John Hardin 

On Fri, 3 Jan 2020, Pedro David Marco wrote:


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_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 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
---
  USMC Rules of Gunfighting #20: The faster you finish the fight,
  the less shot you will get.
---
 306 days until the Presidential Election

Re: Two types of new spam

2020-01-03 Thread Pedro David Marco 
 Hi Philipe...
try this:

full __L_RECEIVED_SPF      /^Received-SPF: \w/mtflags  __L_RECEIVED_SPF      
multiple maxhits=11
meta  L_RECEIVED_SPF        (__L_RECEIVED_SPF >= 10)describe  L_RECEIVED_SPF    
    Crazy numbers of Received-SFP headersscore  L_RECEIVED_SPF        4

-Pedro.

On Friday, January 3, 2020, 12:08:21 AM GMT+1, 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
…


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_SPF            20.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

Re: Two types of new spam

2020-01-03 Thread Kris Deugau 

Philip Prindeville wrote:

I’m getting the following Spam.

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


Received: from phylobago.mysecuritycamera.org 
(ec2-34-210-5-63.us-west-2.compute.amazonaws.com [34.210.5.63])


I have a local rule adding a couple of points for anything coming 
direct-to-MX from any Amazon compute node, period.


I added this on the basis of Amazon's abuse-reporting web form insisting 
that activity from any given IP may be from many AWS customers over a 
span of a few minutes.  Legitimate mail servers do not randomly change 
sending or receiving domains over this timespan, so therefore, Amazon 
compute nodes should not be sending direct-to-MX, at all, ever.


Reality has intruded and there are in fact static IP assignments in the 
.compute.amazonaws.com tree (as well as ISP customers of ours who have 
websites with webforms on AWS, which send mail to their ISP mailbox - or 
sometimes their domain mailbox that's hosted with us) - otherwise I'd 
have scored the rule a lot higher.



And this is notable for having:



GUID1
GUID2
GUID3
GUID4
…


so it should be easy enough to detect.


I've posted about other variations on the "invalid  tag" subject 
in the past.  I've settled for these rules:



full EXTRALONG_STYLEm|type="text/css")?>[^<]{1,3}<\/style>|s



This is capped at a round 30K mainly because you have to recompile Perl 
to use quantifiers larger than 32767.



In practice I have historically seen