Re: rule for repeated tracking numbers

[Axb]

On 08/07/2014 07:28 PM, Philip Prindeville wrote:


On Aug 7, 2014, at 11:14 AM, Axb  wrote:


On 08/07/2014 07:06 PM, Philip Prindeville wrote:


On Aug 7, 2014, at 11:00 AM, Axb  wrote:


On 08/07/2014 06:55 PM, Philip Prindeville wrote:


On Aug 6, 2014, at 11:20 PM, Axb 
wrote:


On 08/07/2014 07:01 AM, Philip Prindeville wrote:


On Aug 6, 2014, at 1:23 PM, Paul Stead
 wrote:



On 06/08/14 20:00, John Hardin wrote:

Can some fresh samples be posted to pastebin?


http://pastebin.com/yHiT2s3t
http://pastebin.com/DpxpJhtA
http://pastebin.com/DYx1ap31

:)



Uh… the hostname in all of these URL’s always resolves to
98.124.199.1.

I just use:

uri_block_cidr L_BLOCK_CIDR 98.124.199.1 body
L_BLOCK_CIDR   eval:check_uri_local_bl()
describe L_BLOCK_CIDR   Block URI's pointing to
bad CIDR's score L_BLOCK_CIDR  7.5

and this nails it.  See:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060





Suggesting to list any IP in the 98.124.192.0/18 net with a score of 7 
is not very wise advice.



I’m listing a /32.  Where do you get a /18 prefix?


listing *anything* in that /18 will hit a zillion of legit
sites... including your /32

For a man and his dog setup it may be ok, but I wouldn't advise
ppl to do this without a *warning*



What is your basis for saying this?  This example filters a
SINGLE (/32) IP.


that single IP has way more thank 10k domains hosted on it (my
passive DNS query is limited to 10k) and there's a huge number of
legitimate ones.



Okay, I thought you were saying that the posted configuration would
block the entire CIDR range.  It won’t.

So they have a lot of VirtualHost definitions: a couple of comments
on that.

(1) putting that many domains on a single host is just begging for
that host to have a catastrophic failure (as opposed to putting that
many domains on a local (re)director which servers as a proxy, a la
mod_proxy_html mode…)

(2) it further means that if the host is compromised, then all the
domains on that host are compromised.

(3) if that IP is being blocked for whatever reason, then that will
motivate the other users on that same host to either pressure eNom to
flush that bad actor ASAP, or they will move to another host…
possibly with another provider.

This is a reckless practice, and eNom will likely suffer consequences
when their users start to catch on to all of the ill effects of it,
some of which I listed above.

No one wants their business reputation being sullied by association
with phishers, spammers, and hacked websites…


you theories are all nicely idealistic, the real world is not so 
friendly... Follow domain activity on DailyChanges and after many nights 
of playing Sherlock you'll get the feeling of what's going on between 
the real world, snowshoers, domainers and cheap registrars.

Re: rule for repeated tracking numbers

[Philip Prindeville]

On Aug 7, 2014, at 11:28 AM, Philip Prindeville 
 wrote:

> 
> Okay, I thought you were saying that the posted configuration would block the 
> entire CIDR range.  It won’t.
> 
> So they have a lot of VirtualHost definitions: a couple of comments on that.
> 
> (1) putting that many domains on a single host is just begging for that host 
> to have a catastrophic failure (as opposed to putting that many domains on a 
> local (re)director which servers as a proxy, a la mod_proxy_html mode…)
> 
> (2) it further means that if the host is compromised, then all the domains on 
> that host are compromised.
> 
> (3) if that IP is being blocked for whatever reason, then that will motivate 
> the other users on that same host to either pressure eNom to flush that bad 
> actor ASAP, or they will move to another host… possibly with another provider.
> 
> This is a reckless practice, and eNom will likely suffer consequences when 
> their users start to catch on to all of the ill effects of it, some of which 
> I listed above.
> 
> No one wants their business reputation being sullied by association with 
> phishers, spammers, and hacked websites…
> 
> -Philip


And for what it’s worth, a lot of the ARIN contact information for eNom 
netblocks is incorrect and points to addresses which seem to go unread (or at 
least unresponded to).

If that were my provider, I wouldn’t stand for it and I’d be out of there in a 
New York minute.

-Philip

Re: rule for repeated tracking numbers

[Andy Balholm]

On Aug 7, 2014, at 10:28 AM, Philip Prindeville 
 wrote:

> (1) putting that many domains on a single host is just begging for that host 
> to have a catastrophic failure (as opposed to putting that many domains on a 
> local (re)director which servers as a proxy, a la mod_proxy_html mode…)

Judging from the reverse DNS, it is a redirector:

$ host 98.124.199.1
1.199.124.98.in-addr.arpa domain name pointer redirector-sjl.enom.com.

Re: rule for repeated tracking numbers

[Philip Prindeville]

On Aug 7, 2014, at 11:14 AM, Axb  wrote:

> On 08/07/2014 07:06 PM, Philip Prindeville wrote:
>> 
>> On Aug 7, 2014, at 11:00 AM, Axb  wrote:
>> 
>>> On 08/07/2014 06:55 PM, Philip Prindeville wrote:
 
 On Aug 6, 2014, at 11:20 PM, Axb  wrote:
 
> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>> 
>> On Aug 6, 2014, at 1:23 PM, Paul Stead  
>> wrote:
>> 
>>> 
>>> On 06/08/14 20:00, John Hardin wrote:
 Can some fresh samples be posted to pastebin?
 
>>> http://pastebin.com/yHiT2s3t
>>> http://pastebin.com/DpxpJhtA
>>> http://pastebin.com/DYx1ap31
>>> 
>>> :)
>> 
>> 
>> Uh… the hostname in all of these URL’s always resolves to 98.124.199.1.
>> 
>> I just use:
>> 
>> uri_block_cidr L_BLOCK_CIDR 98.124.199.1
>> body L_BLOCK_CIDR   eval:check_uri_local_bl()
>> describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
>> score L_BLOCK_CIDR  7.5
>> 
>> and this nails it.  See:
>> 
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060
> 
> Suggesting to list any IP in the 98.124.192.0/18 net with a score of 7 is 
> not very wise advice.
 
 
 I’m listing a /32.  Where do you get a /18 prefix?
>>> 
>>> listing *anything* in that /18 will hit a zillion of legit sites...
>>> including your /32
>>> 
>>> For a man and his dog setup it may be ok, but I wouldn't advise ppl to do 
>>> this without a *warning*
>> 
>> 
>> What is your basis for saying this?  This example filters a SINGLE (/32) IP.
> 
> that single IP has way more thank 10k domains hosted on it (my passive DNS 
> query is limited to 10k) and there's a huge number of legitimate ones.


Okay, I thought you were saying that the posted configuration would block the 
entire CIDR range.  It won’t.

So they have a lot of VirtualHost definitions: a couple of comments on that.

(1) putting that many domains on a single host is just begging for that host to 
have a catastrophic failure (as opposed to putting that many domains on a local 
(re)director which servers as a proxy, a la mod_proxy_html mode…)

(2) it further means that if the host is compromised, then all the domains on 
that host are compromised.

(3) if that IP is being blocked for whatever reason, then that will motivate 
the other users on that same host to either pressure eNom to flush that bad 
actor ASAP, or they will move to another host… possibly with another provider.

This is a reckless practice, and eNom will likely suffer consequences when 
their users start to catch on to all of the ill effects of it, some of which I 
listed above.

No one wants their business reputation being sullied by association with 
phishers, spammers, and hacked websites…

-Philip


> 
>> Please don’t propagate misinformation.
> 
> I can assure that it is not misinformation...  do your research..
> 
> 
> 

Re: rule for repeated tracking numbers

[Philip Prindeville]

On Aug 7, 2014, at 11:13 AM, emailitis.com  wrote:

>> -Original Message-
>> From: Philip Prindeville [mailto:philipp_s...@redfish-solutions.com]
>> Sent: 07 August 2014 06:01
>> To: Paul Stead
>> Cc: users@spamassassin.apache.org
>> Subject: Re: rule for repeated tracking numbers
>> 
>> 
>> On Aug 6, 2014, at 1:23 PM, Paul Stead 
> wrote:
>> 
>> Uh. the hostname in all of these URL's always resolves to 98.124.199.1.
>> 
>> I just use:
>> 
>> uri_block_cidr L_BLOCK_CIDR 98.124.199.1
>> body L_BLOCK_CIDR   eval:check_uri_local_bl()
>> describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
>> score L_BLOCK_CIDR  7.5
>> 
>> and this nails it.  See:
>> 
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060
>> 
>> -Philip
> 
> Forgive my ignorance, but I have just tried adding Philip's rule as
> suggested and it is failing lint.  There must be something taken for granted
> which I am not getting (I am not the guru that you all are, sorry) but can
> someone advise?  I guess there is a whole local criteria config I have not
> set up?
> 
> uri_block_cidr L_BLOCK_CIDR 98.124.199.1
> body L_BLOCK_CIDR   eval:check_uri_local_bl()
> describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
> score L_BLOCK_CIDR  7.5
> 
> [root@plesk3 ~]# spamassassin --lint
> Aug  7 18:03:33.253 [21633] warn: config: failed to parse line, skipping, in
> "/etc/mail/spamassassin/custom_rules.cf": uri_block_cidr L_BLOCK_CIDR
> 98.124.199.1
> Aug  7 18:03:34.334 [21633] warn: rules: failed to run L_BLOCK_CIDR test,
> skipping:
> Aug  7 18:03:34.334 [21633] warn:  (Can't locate object method
> "check_uri_local_bl" via package "Mail: [...]:SpamAssassin::PerMsgStatus" at
> (eval 1175) line 3269.
> Aug  7 18:03:34.335 [21633] warn: )
> Aug  7 18:03:34.402 [21633] warn: lint: 2 issues detected, please rerun with
> debug enabled for more information
> [root@plesk3 ~]#
> 
> Kind Regards,
> 
> Christoph


Did you go the URL I posted:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060

follow it to the commit:

http://svn.apache.org/viewvc?view=revision&revision=1604881

and download the file called “URILocalBL.pm” into your Plugin/ directory?

-Philip

Re: rule for repeated tracking numbers

[Axb]

On 08/07/2014 07:06 PM, Philip Prindeville wrote:


On Aug 7, 2014, at 11:00 AM, Axb  wrote:


On 08/07/2014 06:55 PM, Philip Prindeville wrote:


On Aug 6, 2014, at 11:20 PM, Axb  wrote:


On 08/07/2014 07:01 AM, Philip Prindeville wrote:


On Aug 6, 2014, at 1:23 PM, Paul Stead  wrote:



On 06/08/14 20:00, John Hardin wrote:

Can some fresh samples be posted to pastebin?


http://pastebin.com/yHiT2s3t
http://pastebin.com/DpxpJhtA
http://pastebin.com/DYx1ap31

:)



Uh… the hostname in all of these URL’s always resolves to 98.124.199.1.

I just use:

uri_block_cidr L_BLOCK_CIDR 98.124.199.1
body L_BLOCK_CIDR   eval:check_uri_local_bl()
describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
score L_BLOCK_CIDR  7.5

and this nails it.  See:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060


Suggesting to list any IP in the 98.124.192.0/18 net with a score of 7 is not 
very wise advice.



I’m listing a /32.  Where do you get a /18 prefix?


listing *anything* in that /18 will hit a zillion of legit sites...
including your /32

For a man and his dog setup it may be ok, but I wouldn't advise ppl to do this 
without a *warning*



What is your basis for saying this?  This example filters a SINGLE (/32) IP.


that single IP has way more thank 10k domains hosted on it (my passive 
DNS query is limited to 10k) and there's a huge number of legitimate ones.



Please don’t propagate misinformation.


I can assure that it is not misinformation...  do your research..

RE: rule for repeated tracking numbers

[emailitis.com]

> -Original Message-
> From: Philip Prindeville [mailto:philipp_s...@redfish-solutions.com]
> Sent: 07 August 2014 06:01
> To: Paul Stead
> Cc: users@spamassassin.apache.org
> Subject: Re: rule for repeated tracking numbers
> 
> 
> On Aug 6, 2014, at 1:23 PM, Paul Stead 
wrote:
> 
> Uh. the hostname in all of these URL's always resolves to 98.124.199.1.
> 
> I just use:
> 
> uri_block_cidr L_BLOCK_CIDR 98.124.199.1
> body L_BLOCK_CIDR   eval:check_uri_local_bl()
> describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
> score L_BLOCK_CIDR  7.5
> 
> and this nails it.  See:
> 
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060
> 
> -Philip

Forgive my ignorance, but I have just tried adding Philip's rule as
suggested and it is failing lint.  There must be something taken for granted
which I am not getting (I am not the guru that you all are, sorry) but can
someone advise?  I guess there is a whole local criteria config I have not
set up?

uri_block_cidr L_BLOCK_CIDR 98.124.199.1
body L_BLOCK_CIDR   eval:check_uri_local_bl()
describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
score L_BLOCK_CIDR  7.5

[root@plesk3 ~]# spamassassin --lint
Aug  7 18:03:33.253 [21633] warn: config: failed to parse line, skipping, in
"/etc/mail/spamassassin/custom_rules.cf": uri_block_cidr L_BLOCK_CIDR
98.124.199.1
Aug  7 18:03:34.334 [21633] warn: rules: failed to run L_BLOCK_CIDR test,
skipping:
Aug  7 18:03:34.334 [21633] warn:  (Can't locate object method
"check_uri_local_bl" via package "Mail: [...]:SpamAssassin::PerMsgStatus" at
(eval 1175) line 3269.
Aug  7 18:03:34.335 [21633] warn: )
Aug  7 18:03:34.402 [21633] warn: lint: 2 issues detected, please rerun with
debug enabled for more information
[root@plesk3 ~]#

Kind Regards,

Christoph

Re: rule for repeated tracking numbers

[Philip Prindeville]

On Aug 7, 2014, at 11:00 AM, Axb  wrote:

> On 08/07/2014 06:55 PM, Philip Prindeville wrote:
>> 
>> On Aug 6, 2014, at 11:20 PM, Axb  wrote:
>> 
>>> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
 
 On Aug 6, 2014, at 1:23 PM, Paul Stead  
 wrote:
 
> 
> On 06/08/14 20:00, John Hardin wrote:
>> Can some fresh samples be posted to pastebin?
>> 
> http://pastebin.com/yHiT2s3t
> http://pastebin.com/DpxpJhtA
> http://pastebin.com/DYx1ap31
> 
> :)
 
 
 Uh… the hostname in all of these URL’s always resolves to 98.124.199.1.
 
 I just use:
 
 uri_block_cidr L_BLOCK_CIDR 98.124.199.1
 body L_BLOCK_CIDR   eval:check_uri_local_bl()
 describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
 score L_BLOCK_CIDR  7.5
 
 and this nails it.  See:
 
 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060
>>> 
>>> Suggesting to list any IP in the 98.124.192.0/18 net with a score of 7 is 
>>> not very wise advice.
>> 
>> 
>> I’m listing a /32.  Where do you get a /18 prefix?
> 
> listing *anything* in that /18 will hit a zillion of legit sites...
> including your /32
> 
> For a man and his dog setup it may be ok, but I wouldn't advise ppl to do 
> this without a *warning*


What is your basis for saying this?  This example filters a SINGLE (/32) IP.

Please don’t propagate misinformation.

-Philip

Re: rule for repeated tracking numbers

[Axb]

On 08/07/2014 06:55 PM, Philip Prindeville wrote:


On Aug 6, 2014, at 11:20 PM, Axb  wrote:


On 08/07/2014 07:01 AM, Philip Prindeville wrote:


On Aug 6, 2014, at 1:23 PM, Paul Stead  wrote:



On 06/08/14 20:00, John Hardin wrote:

Can some fresh samples be posted to pastebin?


http://pastebin.com/yHiT2s3t
http://pastebin.com/DpxpJhtA
http://pastebin.com/DYx1ap31

:)



Uh… the hostname in all of these URL’s always resolves to 98.124.199.1.

I just use:

uri_block_cidr L_BLOCK_CIDR 98.124.199.1
body L_BLOCK_CIDR   eval:check_uri_local_bl()
describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
score L_BLOCK_CIDR  7.5

and this nails it.  See:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060


Suggesting to list any IP in the 98.124.192.0/18 net with a score of 7 is not 
very wise advice.



I’m listing a /32.  Where do you get a /18 prefix?


listing *anything* in that /18 will hit a zillion of legit sites...
including your /32

For a man and his dog setup it may be ok, but I wouldn't advise ppl to 
do this without a *warning*

Re: rule for repeated tracking numbers

[Philip Prindeville]

uri_block_cidr will still defeat this, at least until he’s forced to switch 
hosting providers.


On Aug 7, 2014, at 10:43 AM, Andy Balholm  wrote:

> This particular spammer just re-did the format of their emails, probably to 
> get around the rules that we’re working on. Do they read the 
> spamassassin-users list? (I can tell it’s the same spammer, since the return 
> address in Dundrum, Ireland, is the same as some of the earlier ones, and the 
> styling is similar.)
> 
> Here’s their new format: http://pastebin.com/BpZ4RRJv
> 
> It got a score of -0.7 on my box!

Re: rule for repeated tracking numbers

[Philip Prindeville]

On Aug 6, 2014, at 11:20 PM, Axb  wrote:

> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>> 
>> On Aug 6, 2014, at 1:23 PM, Paul Stead  wrote:
>> 
>>> 
>>> On 06/08/14 20:00, John Hardin wrote:
 Can some fresh samples be posted to pastebin?
 
>>> http://pastebin.com/yHiT2s3t
>>> http://pastebin.com/DpxpJhtA
>>> http://pastebin.com/DYx1ap31
>>> 
>>> :)
>> 
>> 
>> Uh… the hostname in all of these URL’s always resolves to 98.124.199.1.
>> 
>> I just use:
>> 
>> uri_block_cidr L_BLOCK_CIDR 98.124.199.1
>> body L_BLOCK_CIDR   eval:check_uri_local_bl()
>> describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
>> score L_BLOCK_CIDR  7.5
>> 
>> and this nails it.  See:
>> 
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060
> 
> Suggesting to list any IP in the 98.124.192.0/18 net with a score of 7 is not 
> very wise advice.


I’m listing a /32.  Where do you get a /18 prefix?

-Philip


> 
> It will hit many thousand legitimate domains hosted on Enom.
> 

Re: rule for repeated tracking numbers

[Andy Balholm]

This particular spammer just re-did the format of their emails, probably to get 
around the rules that we’re working on. Do they read the spamassassin-users 
list? (I can tell it’s the same spammer, since the return address in Dundrum, 
Ireland, is the same as some of the earlier ones, and the styling is similar.)

Here’s their new format: http://pastebin.com/BpZ4RRJv

It got a score of -0.7 on my box!

Re: rule for repeated tracking numbers

[Axb]

On 08/07/2014 07:01 AM, Philip Prindeville wrote:


On Aug 6, 2014, at 1:23 PM, Paul Stead  wrote:



On 06/08/14 20:00, John Hardin wrote:

Can some fresh samples be posted to pastebin?


http://pastebin.com/yHiT2s3t
http://pastebin.com/DpxpJhtA
http://pastebin.com/DYx1ap31

:)



Uh… the hostname in all of these URL’s always resolves to 98.124.199.1.

I just use:

uri_block_cidr L_BLOCK_CIDR 98.124.199.1
body L_BLOCK_CIDR   eval:check_uri_local_bl()
describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
score L_BLOCK_CIDR  7.5

and this nails it.  See:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060


Suggesting to list any IP in the 98.124.192.0/18 net with a score of 7 
is not very wise advice.


It will hit many thousand legitimate domains hosted on Enom.

Re: rule for repeated tracking numbers

[Philip Prindeville]

On Aug 6, 2014, at 1:23 PM, Paul Stead  wrote:

> 
> On 06/08/14 20:00, John Hardin wrote:
>> Can some fresh samples be posted to pastebin?
>> 
> http://pastebin.com/yHiT2s3t
> http://pastebin.com/DpxpJhtA
> http://pastebin.com/DYx1ap31
> 
> :)


Uh… the hostname in all of these URL’s always resolves to 98.124.199.1.

I just use:

uri_block_cidr L_BLOCK_CIDR 98.124.199.1
body L_BLOCK_CIDR   eval:check_uri_local_bl()
describe L_BLOCK_CIDR   Block URI's pointing to bad CIDR's
score L_BLOCK_CIDR  7.5

and this nails it.  See:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060

-Philip

Re: rule for repeated tracking numbers

[John Hardin]

On Wed, 6 Aug 2014, Paul Stead wrote:



On 06/08/14 20:00, John Hardin wrote:

 Can some fresh samples be posted to pastebin?


http: //pastebin.com/yHiT2s3t
http: //pastebin.com/DpxpJhtA
http: //pastebin.com/DYx1ap31

:)


Thanks.

They've substantially reduced the number of repetitions since first 
starting to use that technique.


--
 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
---
  I'm seriously considering getting one of those bright-orange prison
  overalls and stencilling PASSENGER on the back. Along with the paper
  slippers, I ought to be able to walk right through security.
 -- Brian Kantor in a.s.r
---
 Today: the 69th anniversary of the Hiroshima bombing

Re: rule for repeated tracking numbers

[Andy Balholm]

On Aug 6, 2014, at 2:00 PM, Axb  wrote:

> Suggest you use a local DNS resolver instead of some third party which is 
> getting in your way.

Good idea. I installed unbound, and configured it to not use Google’s 
nameservers (which were the ones that were blocked). Now uribl seems to be 
working.

Re: rule for repeated tracking numbers

[Axb]

On 08/06/2014 10:32 PM, Andy Balholm wrote:


On Aug 6, 2014, at 12:00 PM, John Hardin  wrote:


Can some fresh samples be posted to pastebin?


http://pastebin.com/DWiTYmPN is my complete collection of 24 spams with this 
pattern received this week. Collect them all!




You're getting

X-Spam-Report:
*  0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL 
was blocked.
*   See 
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block

*  for more information.

Suggest you use a local DNS resolver instead of some third party which 
is getting in your way.

Re: rule for repeated tracking numbers

[Axb]

On 08/06/2014 10:34 PM, Paul Stead wrote:


On 06/08/14 21:03, Axb wrote:
the unmunged Msg-ID and the num code in the From: (which is also a nice
trait)   .-)

How would you test for such a trait? Where the same num code appears
throughout the email in specific places? I guess this is plugin territory?
--
Paul Stead
Systems Engineer
Zen Internet



take something like:
From:name =~ /[0-9]{4,20}/

meta with whatever you want to detect in the body
+ uri pattern

Re: rule for repeated tracking numbers

[Paul Stead]

On 06/08/14 21:03, Axb wrote:
the unmunged Msg-ID and the num code in the From: (which is also a nice trait)  
 .-)

How would you test for such a trait? Where the same num code appears throughout 
the email in specific places? I guess this is plugin territory?
--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[Andy Balholm]

On Aug 6, 2014, at 12:00 PM, John Hardin  wrote:

> Can some fresh samples be posted to pastebin?

http://pastebin.com/DWiTYmPN is my complete collection of 24 spams with this 
pattern received this week. Collect them all!

Re: rule for repeated tracking numbers

[Axb]

On 08/06/2014 10:17 PM, Paul Stead wrote:

Assuming I didn't change those too :)

Guess what the MD5 of redac...@example.com is?

On 06/08/14 21:03, Axb wrote:
btw.. you munged rcpt, but the spammer confirmed or listwashed you using
the unmunged Msg-ID and the num code in the From: (which is also a nice
trait)   .-)


LOL!  good one

1:0 you win :)

Re: rule for repeated tracking numbers

[Paul Stead]

Assuming I didn't change those too :)

Guess what the MD5 of redac...@example.com is?

On 06/08/14 21:03, Axb wrote:
btw.. you munged rcpt, but the spammer confirmed or listwashed you using the 
unmunged Msg-ID and the num code in the From: (which is also a nice trait)   .-)


--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[Axb]

On 08/06/2014 09:23 PM, Paul Stead wrote:


On 06/08/14 20:00, John Hardin wrote:

Can some fresh samples be posted to pastebin?


http://pastebin.com/yHiT2s3t
http://pastebin.com/DpxpJhtA
http://pastebin.com/DYx1ap31



btw.. you munged rcpt, but the spammer confirmed or listwashed you using 
the unmunged Msg-ID and the num code in the From: (which is also a nice 
trait)   .-)

Re: rule for repeated tracking numbers

[Axb]

On 08/06/2014 09:23 PM, Paul Stead wrote:


On 06/08/14 20:00, John Hardin wrote:

Can some fresh samples be posted to pastebin?


http://pastebin.com/yHiT2s3t
http://pastebin.com/DpxpJhtA
http://pastebin.com/DYx1ap31



a simple URI rule gets rid of this type without headbanging RE

Re: rule for repeated tracking numbers

[Paul Stead]

On 06/08/14 20:00, John Hardin wrote:

Can some fresh samples be posted to pastebin?


http://pastebin.com/yHiT2s3t
http://pastebin.com/DpxpJhtA
http://pastebin.com/DYx1ap31

:)
--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[John Hardin]

On Tue, 5 Aug 2014, Andy Balholm wrote:



On Aug 5, 2014, at 11:16 AM, John Hardin  wrote:


It can hit on embedded phone numbers, which are, strictly speaking, valid 
hexadecimal strings...
I suspect it's hitting on all those dates as well, and needs some more 
tightening.


In the spams I’m looking at, all the hex strings are 32 characters. How long 
were they in Joe’s samples (no longer on pastebin)?


I have seen examples with hex strings as short as 12-16 characters, as 
well as GUID-esqe --x-- dash-separated sequences. 
That's why the HEXHASH rule is more complex than what's being suggested 
here


Can some fresh samples be posted to pastebin?

--
 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
---
  There is no better measure of the unthinking contempt of the
  environmentalist movement for civilization than their call to
  turn off the lights and sit in the dark.-- Sultan Knish
---
 Today: the 69th anniversary of the Hiroshima bombing

Re: rule for repeated tracking numbers

[Paul Stead]

On 06/08/14 19:50, Paul Stead wrote:

body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32})
.{1,250}[\g1].{1,250}\g2/

Hmmm.. line breakage... \s instead of spaces?

body __LOC_DIGITS_CONFUSER
/\s(\d{7,8})\s.{1,250}\s([0-9a-f]{32})\s.{1,250}\g1.{1,250}\g2/

Note that \g denotes a previous regex match, in this case it's matching
$1 and $2 later in the string.

Paul
--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[Paul Stead]

On 06/08/14 19:39, Alex wrote:


body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32})
.{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/
This doesn't pass lint:

Oops! copy/pasta fail to the max - I noticed this didn't work previously
- the following is correct

body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32})
.{1,250}[\g1].{1,250}\g2/

Paul
--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[Bowie Bailey]

On 8/6/2014 2:39 PM, Alex wrote:


On Wed, Aug 6, 2014 at 1:32 PM, Paul Stead 
mailto:paul.st...@zeninternet.co.uk>> 
wrote:


 06/08/14 16:28, Quanah Gibson-Mount wrote:

Would you be willing to share your full finalized ruleset?  This
spam is really obnoxious.

Sure...

A little adjustment as I noticed the brackets around the first
number match was wrong:

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32})
.{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/

Something like...

meta LOC_DIGITS_SPAM (__LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
score LOC_DIGITS_SPAM 0.001


header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32}) 
.{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/

meta LOC_DIGITS_SPAM ( __LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
score LOC_DIGITS_SPAM 0.001

This doesn't pass lint:


Looks like a couple of issues with the body rule.  Try this:

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32}) 
.{1,250}(?:\1|\2) .{1,250}(?:\1|\2)/

meta LOC_DIGITS_SPAM ( __LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
score LOC_DIGITS_SPAM 0.001

--
Bowie

Re: rule for repeated tracking numbers

[Alex]

On Wed, Aug 6, 2014 at 1:32 PM, Paul Stead 
wrote:

>   06/08/14 16:28, Quanah Gibson-Mount wrote:
>
> Would you be willing to share your full finalized ruleset?  This spam is
> really obnoxious.
>
> Sure...
>
> A little adjustment as I noticed the brackets around the first number
> match was wrong:
>
> header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
> body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32})
> .{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/
>
> Something like...
>
> meta LOC_DIGITS_SPAM ( __LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
> score LOC_DIGITS_SPAM 0.001
>

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32})
.{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/
meta LOC_DIGITS_SPAM ( __LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
score LOC_DIGITS_SPAM 0.001

This doesn't pass lint:

Aug  6 14:37:30.617 [11275] warn: Unrecognized escape \g in character class
passed through in regex; marked by <-- HERE in m/ (\d{7,8}) .{1,250}
([0-9a-f]{32}) .{1,250}[\g <-- HERE 1|\g2] .{1,250}[\g1|\g2]/ at
/etc/mail/spamassassin/70_general.cf, rule __LOC_DIGITS_CONFUSER, line 1.
Aug  6 14:37:30.617 [11275] warn: Unrecognized escape \g in character class
passed through in regex; marked by <-- HERE in m/ (\d{7,8}) .{1,250}
([0-9a-f]{32}) .{1,250}[\g1|\g <-- HERE 2] .{1,250}[\g1|\g2]/ at
/etc/mail/spamassassin/70_general.cf, rule __LOC_DIGITS_CONFUSER, line 1.
Aug  6 14:37:30.617 [11275] warn: Unrecognized escape \g in character class
passed through in regex; marked by <-- HERE in m/ (\d{7,8}) .{1,250}
([0-9a-f]{32}) .{1,250}[\g1|\g2] .{1,250}[\g <-- HERE 1|\g2]/ at
/etc/mail/spamassassin/70_general.cf, rule __LOC_DIGITS_CONFUSER, line 1.
Aug  6 14:37:30.617 [11275] warn: Unrecognized escape \g in character class
passed through in regex; marked by <-- HERE in m/ (\d{7,8}) .{1,250}
([0-9a-f]{32}) .{1,250}[\g1|\g2] .{1,250}[\g1|\g <-- HERE 2]/ at
/etc/mail/spamassassin/70_general.cf, rule __LOC_DIGITS_CONFUSER, line 1.

Thanks,
Alex

Re: rule for repeated tracking numbers

[Quanah Gibson-Mount]

--On Wednesday, August 06, 2014 7:32 PM +0100 Paul Stead 
 wrote:



 06/08/14 16:28, Quanah Gibson-Mount wrote:

Would you be willing to share your full finalized ruleset?  This spam is
really obnoxious.

Sure...

A little adjustment as I noticed the brackets around the first number
match was wrong:

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32})
.{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/

Something like...

meta LOC_DIGITS_SPAM ( __LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
score LOC_DIGITS_SPAM 0.001

should work


Thank you very much!  I'm going to give it a test run on our server.

--Quanah

--

Quanah Gibson-Mount
Server Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: rule for repeated tracking numbers

[Paul Stead]

I must put a disclaimer that this is possibly not the most efficient regex in 
the world either - though I'm not sure what else could be done to refine it so 
it still matches in the way we want. 250 character limit should help though?

Paul

On 06/08/14 18:32, Paul Stead wrote:
06/08/14 16:28, Quanah Gibson-Mount wrote:
Would you be willing to share your full finalized ruleset?  This spam is really 
obnoxious.
Sure...

A little adjustment as I noticed the brackets around the first number match was 
wrong:

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32}) 
.{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/

Something like...

meta LOC_DIGITS_SPAM ( __LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
score LOC_DIGITS_SPAM 0.001

should work
--
Paul Stead
Systems Engineer
Zen Internet

--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[Paul Stead]

06/08/14 16:28, Quanah Gibson-Mount wrote:
Would you be willing to share your full finalized ruleset?  This spam is really 
obnoxious.
Sure...

A little adjustment as I noticed the brackets around the first number match was 
wrong:

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER / (\d{7,8}) .{1,250} ([0-9a-f]{32}) 
.{1,250}[\g1|\g2] .{1,250}[\g1|\g2]/

Something like...

meta LOC_DIGITS_SPAM ( __LOC_DIGITS_FROM && __LOC_DIGITS_CONFUSER)
score LOC_DIGITS_SPAM 0.001

should work
--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[Quanah Gibson-Mount]

--On Wednesday, August 06, 2014 4:37 PM +0100 Paul Stead 
 wrote:



I've been having a play with the two rules mentioned, this seems to work
for me:

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER /  (\d){7,8} .{1,250} ([0-9a-f]{32})
.{1,250}[\g1|\g2].{1,250}[\g1|\g2]/

Joining these together in a meta rule seems to be picking up the emails
I expect them to.


Would you be willing to share your full finalized ruleset?  This spam is 
really obnoxious.


Thanks!

--Quanah

--

Quanah Gibson-Mount
Server Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: rule for repeated tracking numbers

[Paul Stead]

I've been having a play with the two rules mentioned, this seems to work
for me:

header __LOC_DIGITS_FROM From:name =~ /\.\d{7,8}$/
body __LOC_DIGITS_CONFUSER /  (\d){7,8} .{1,250} ([0-9a-f]{32})
.{1,250}[\g1|\g2].{1,250}[\g1|\g2]/

Joining these together in a meta rule seems to be picking up the emails
I expect them to.

On 05/08/14 19:40, Andy Balholm wrote:

On Aug 5, 2014, at 11:16 AM, John Hardin  wrote:


It can hit on embedded phone numbers, which are, strictly speaking, valid 
hexadecimal strings...
I suspect it's hitting on all those dates as well, and needs some more 
tightening.

In the spams I’m looking at, all the hex strings are 32 characters. How long 
were they in Joe’s samples (no longer on pastebin)?

Joe was concerned about the performance of my regex (because of all the .*’s), 
but it can search through my /var/mail in 5 seconds; the __HEXHASHWORD_S2EU 
regex takes over 9.


--
Paul Stead
Systems Engineer
Zen Internet

Re: rule for repeated tracking numbers

[John Hardin]

On Tue, 5 Aug 2014, Kevin A. McGrail wrote:


On 8/5/2014 1:48 PM, John Hardin wrote:

 On Tue, 5 Aug 2014, Andy Balholm wrote:

>  On Aug 5, 2014, at 10:31 AM, John Hardin  wrote:
> 
> >  There's already a rule for this sort of thing in the sandbox.
> > 
> >  http://ruleqa.spamassassin.org/20140804-r1615505-n/HEXHASH_WORD/detail
> 
>  How do I find the actual rule that the page is about?


 Unfortunately the masscheck pages' links to SVN got broken in the recent
 rebuild.


John,

   Can you tell me what doesn't work and what is supposed to work so I can 
investigate this recent rebuild issue?


Example:

http://ruleqa.spamassassin.org/20140804-r1615505-n/FROM_MISSP_MSFT/detail

Has:

  Detailed results for rule FROM_MISSP_MSFT, from source file (not found).
  Source file was last modified on 1970-01-01 00:00:00 UTC.

The "(not found)" is trying to be a viewvc URL:

http://svn.apache.org/viewvc/spamassassin/trunk/(not%20found)?revision=1615505&view=markup

I think that the URL and the date depend on there being a local SVN 
sandbox, but that seems unlikely as the website was running the whole time 
the masscheck host was down. Perhaps it's depending on the SVN sandbox on 
the masscheck host and that access got broken?


--
 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
---
  Where We Want You To Go Today 09/13/07: Microsoft patents in-OS
  adware architecture that incorporates monitoring and analysis of
  user actions and interrupting the user to display apparently
  relevant advertisements (U.S. Patent #20070214042)
---
 Today: the 279th anniversary of John Peter Zenger's acquittal

Re: rule for repeated tracking numbers

[Kevin A. McGrail]

On 8/5/2014 1:48 PM, John Hardin wrote:

On Tue, 5 Aug 2014, Andy Balholm wrote:


On Aug 5, 2014, at 10:31 AM, John Hardin  wrote:


There's already a rule for this sort of thing in the sandbox.

http://ruleqa.spamassassin.org/20140804-r1615505-n/HEXHASH_WORD/detail


How do I find the actual rule that the page is about?


Unfortunately the masscheck pages' links to SVN got broken in the 
recent rebuild.


That rule lives here:

https://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/jhardin/20_misc_testing.cf?view=log 



It should be part of the current base rules update.


John,

Can you tell me what doesn't work and what is supposed to work so I 
can investigate this recent rebuild issue?


Regards,
KAM

Re: rule for repeated tracking numbers

[Andy Balholm]

On Aug 5, 2014, at 11:16 AM, John Hardin  wrote:

> It can hit on embedded phone numbers, which are, strictly speaking, valid 
> hexadecimal strings...
> I suspect it's hitting on all those dates as well, and needs some more 
> tightening.

In the spams I’m looking at, all the hex strings are 32 characters. How long 
were they in Joe’s samples (no longer on pastebin)?

Joe was concerned about the performance of my regex (because of all the .*’s), 
but it can search through my /var/mail in 5 seconds; the __HEXHASHWORD_S2EU 
regex takes over 9.

Re: rule for repeated tracking numbers

[John Hardin]

On Tue, 5 Aug 2014, Andy Balholm wrote:



On Aug 5, 2014, at 10:48 AM, John Hardin  wrote:


Unfortunately the masscheck pages' links to SVN got broken in the recent 
rebuild.

That rule lives here:

https://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/jhardin/20_misc_testing.cf?view=log

It should be part of the current base rules update.


I don't really understand that rule, but I tested the __HEXHASHWORD_S2EU regex 
against my /var/mail directory, and it has 67 matches, most of which don’t have 
much resemblance to what I’m looking to match:


It can hit on embedded phone numbers, which are, strictly speaking, valid 
hexadecimal strings...



Contact me by cell 6047919108 or email to set apt. Thank you
and give me a call at work 6047924667 and i will give you my visa info


I suspect it's hitting on all those dates as well, and needs some more 
tightening.



--
 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
---
   "A well educated Electorate, being necessary to the liberty of a
free State, the Right of the People to Keep and Read Books,
shall not be infringed."
  ...means only registered voters can read books, and only those books
  obtained with State permission from State-controlled bookstores?
---
 Today: the 279th anniversary of John Peter Zenger's acquittal

Re: rule for repeated tracking numbers

[Andy Balholm]

On Aug 5, 2014, at 10:48 AM, John Hardin  wrote:

> Unfortunately the masscheck pages' links to SVN got broken in the recent 
> rebuild.
> 
> That rule lives here:
> 
> https://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/jhardin/20_misc_testing.cf?view=log
> 
> It should be part of the current base rules update.

I don't really understand that rule, but I tested the __HEXHASHWORD_S2EU regex 
against my /var/mail directory, and it has 67 matches, most of which don’t have 
much resemblance to what I’m looking to match:

root@cloud:/var/mail# perl -ne 'print if 
/\s[A-Z]?[a-z]{1,15}\s(?![a-z]{10,20}\s)[a-z]{0,10}(?!\d{1,3}-)(?:(?!--)[-0-9a-f]){10,64}(?:[g-z][a-z]{0,10})?\s[A-Z]?[a-z]{1,15}\b/'
 *
 
Click
 Here for the Full Report.  
Futures
 Six-PackThursday, June 19th 2014Crude OilPrices have turned lower this morning 
as the market continues to strugglebreak back over resistance at 10675-10700 
basis the August contract. Unlesswe see more evidence of violence that spreads 
to the southern oil fieldregions of Iraq we might have already seen the highs 
in this particularcrude rally. But then again Brent Crude continues to surge 
and the Brent/WTIspread is back trading above 900. Until we have a change 
...S&P 500Opening slightly higher after yesterday’s late blitz to the upside 
inspiredby Wall Street’s best new friend, Janet Yellen and her dovish take on 
Fedpolicy going forward. As long as the Fed and the rest of the global 
centralbankers continue to provide the insane liquidity that funnels all 
capital toequities, then the only path one can take is ...SoybeansBeans are 
trading unchanged to slightly lower this morning as the marketcontinues to hold 
onto support in the 1204-1208 range. Weather remains noconcern right now and 
should ultimately drive prices lower...Get the Futures Six-Pack delivered to 
your inbox 
daily!Courtesy
 of John McLane 
Facebook
 
Twitter
 
LinkedInNicholas
 Houle named PrincipalFriday, June 13 2014We are pleased to announce that 
Nicholas Houle has been named a principal ofIndex Futures Group. Nick joined 
the firm 5 years ago and since then, hisrole and responsibilities have evolved 
tremendously. He has beeninstrumental in securing our position as an elite 
brokerage firm in thefutures industry and will continue to help drive us toward 
growth andsuccess.Positioning for Soybeans 
(click
 here for full-size 
image)With
 favorable weather conditions throughout planting season, projectionsfor 
November Soybean are for a high crop yield and lower prices. However,with talks 
of a strong El Nino later this year potentially bringing aboutadverse weather 
conditions, there is potential for beans to move higher.(Click here to read 
full report on El Nino and its 
effects
 ) Traders should look for ways tomanage risk and/or position themselves for a 
possible volatile autumn forbeans.Jack on TV 
June
 18 

 Fed DayJune 14 

 Global Growth StoryJune 
4T
 he Stars 
AlignFeatured
 Program 

Re: rule for repeated tracking numbers

[John Hardin]

On Tue, 5 Aug 2014, Andy Balholm wrote:


On Aug 5, 2014, at 10:31 AM, John Hardin  wrote:


There's already a rule for this sort of thing in the sandbox.

http://ruleqa.spamassassin.org/20140804-r1615505-n/HEXHASH_WORD/detail


How do I find the actual rule that the page is about?


Unfortunately the masscheck pages' links to SVN got broken in the recent 
rebuild.


That rule lives here:

https://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/jhardin/20_misc_testing.cf?view=log

It should be part of the current base rules update.

--
 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
---
  Yet another example of a Mexican doing a job Americans are
  unwilling to do.   -- Reno Sepulveda, on UniVision reporters asking
President Obama some pointed questions about
the BATFE Fast and Furious scandal.
---
 Today: the 279th anniversary of John Peter Zenger's acquittal

Re: rule for repeated tracking numbers

[Andy Balholm]

On Aug 5, 2014, at 10:31 AM, John Hardin  wrote:

> 
> There's already a rule for this sort of thing in the sandbox.
> 
> http://ruleqa.spamassassin.org/20140804-r1615505-n/HEXHASH_WORD/detail

How do I find the actual rule that the page is about?

Re: rule for repeated tracking numbers

[John Hardin]

On Tue, 5 Aug 2014, Andy Balholm wrote:


The last few days, I’ve been getting a lot of spams that have a similar 
pattern. They are plain-text messages, and each one ends with a paragraph from 
a restaurant review (apparently to confuse bayesian filters), with some numbers 
inserted. There is an 8-digit decimal number and a 32-digit hex one. Each 
number appears two or three times. This is a consistent enough pattern that I 
wrote a rule to match it:

body REPEATED_TRACKING_NUMBERS / (\d{8}) .* ([0-9a-f]{32}) .*\g1.*\g2/
score REPEATED_TRACKING_NUBMERS 1
describe REPEATED_TRACKING_NUMBERS A large number and a hex hash, each showing 
up at least twice.

The spaces in the regex are necessary to avoid matching notification emails 
from eBay.


There's already a rule for this sort of thing in the sandbox.

http://ruleqa.spamassassin.org/20140804-r1615505-n/HEXHASH_WORD/detail

Technically speaking, unless they appear in a URI they aren't "tracking" 
information, as there's nothing done with them that a third party can 
observe. They're just there to interfere with known-text pattern matching 
and things like Razor checksums.


--
 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
---
  Yet another example of a Mexican doing a job Americans are
  unwilling to do.   -- Reno Sepulveda, on UniVision reporters asking
President Obama some pointed questions about
the BATFE Fast and Furious scandal.
---
 Today: the 279th anniversary of John Peter Zenger's acquittal

Re: rule for repeated tracking numbers

[Joe Quinn]

On 8/5/2014 1:08 PM, Andy Balholm wrote:

The last few days, I’ve been getting a lot of spams that have a similar 
pattern. They are plain-text messages, and each one ends with a paragraph from 
a restaurant review (apparently to confuse bayesian filters), with some numbers 
inserted. There is an 8-digit decimal number and a 32-digit hex one. Each 
number appears two or three times. This is a consistent enough pattern that I 
wrote a rule to match it:

body REPEATED_TRACKING_NUMBERS / (\d{8}) .* ([0-9a-f]{32}) .*\g1.*\g2/
score REPEATED_TRACKING_NUBMERS 1
describe REPEATED_TRACKING_NUMBERS A large number and a hex hash, each showing 
up at least twice.

The spaces in the regex are necessary to avoid matching notification emails 
from eBay.
The first thing I notice is that you are using .* thrice in a body rule. 
That's probably going to be an issue...


The other thing is that you're going to be matching against legitimate 
emails that have unsubscribe links (such as Facebook updates or bank 
notifications).