Re: Two types of new spam
> 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
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
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
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
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
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
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
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
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
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
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
> 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
> 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
> 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
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
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
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
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|