You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Andy Balholm <an...@balholm.com> on 2014/08/05 19:08:18 UTC
rule for repeated tracking numbers
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.
Re: unsubscribe
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
Wrong address. To unsubscribe, send a mail to the appropriate
list-command address, not the mailing list itself.
See the headers of each and every post on this list:
list-help: <ma...@spamassassin.apache.org>
list-unsubscribe: <ma...@spamassassin.apache.org>
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
unsubscribe
Posted by Rob Brandt <br...@csd-bes.net>.
Re: rule for repeated tracking numbers
Posted by John Hardin <jh...@impsec.org>.
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 <jh...@impsec.org> 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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 <jh...@impsec.org> 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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
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
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Wednesday, August 06, 2014 7:32 PM +0100 Paul Stead
<pa...@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
>
> 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
Posted by Bowie Bailey <Bo...@BUC.com>.
On 8/6/2014 2:39 PM, Alex wrote:
>
> On Wed, Aug 6, 2014 at 1:32 PM, Paul Stead
> <paul.stead@zeninternet.co.uk <ma...@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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
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
Posted by Alex <my...@gmail.com>.
On Wed, Aug 6, 2014 at 1:32 PM, Paul Stead <pa...@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:
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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
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
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Wednesday, August 06, 2014 4:37 PM +0100 Paul Stead
<pa...@zeninternet.co.uk> 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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
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 <jh...@impsec.org> 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
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On Aug 7, 2014, at 11:13 AM, emailitis.com <in...@emailitis.com> wrote:
>> -----Original Message-----
>> From: Philip Prindeville [mailto:philipp_subx@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 <pa...@zeninternet.co.uk>
> 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
Posted by "emailitis.com" <in...@emailitis.com>.
> -----Original Message-----
> From: Philip Prindeville [mailto:philipp_subx@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 <pa...@zeninternet.co.uk>
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
Posted by Axb <ax...@gmail.com>.
On 08/07/2014 07:28 PM, Philip Prindeville wrote:
>
> On Aug 7, 2014, at 11:14 AM, Axb <ax...@gmail.com> wrote:
>
>> On 08/07/2014 07:06 PM, Philip Prindeville wrote:
>>>
>>> On Aug 7, 2014, at 11:00 AM, Axb <ax...@gmail.com> wrote:
>>>
>>>> On 08/07/2014 06:55 PM, Philip Prindeville wrote:
>>>>>
>>>>> On Aug 6, 2014, at 11:20 PM, Axb <ax...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>>>>>>>
>>>>>>> On Aug 6, 2014, at 1:23 PM, Paul Stead
>>>>>>> <pa...@zeninternet.co.uk> 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
Posted by Andy Balholm <an...@balholm.com>.
On Aug 7, 2014, at 10:28 AM, Philip Prindeville <ph...@redfish-solutions.com> 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
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On Aug 7, 2014, at 11:28 AM, Philip Prindeville <ph...@redfish-solutions.com> 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
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On Aug 7, 2014, at 11:14 AM, Axb <ax...@gmail.com> wrote:
> On 08/07/2014 07:06 PM, Philip Prindeville wrote:
>>
>> On Aug 7, 2014, at 11:00 AM, Axb <ax...@gmail.com> wrote:
>>
>>> On 08/07/2014 06:55 PM, Philip Prindeville wrote:
>>>>
>>>> On Aug 6, 2014, at 11:20 PM, Axb <ax...@gmail.com> wrote:
>>>>
>>>>> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>>>>>>
>>>>>> On Aug 6, 2014, at 1:23 PM, Paul Stead <pa...@zeninternet.co.uk> 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
Posted by Axb <ax...@gmail.com>.
On 08/07/2014 07:06 PM, Philip Prindeville wrote:
>
> On Aug 7, 2014, at 11:00 AM, Axb <ax...@gmail.com> wrote:
>
>> On 08/07/2014 06:55 PM, Philip Prindeville wrote:
>>>
>>> On Aug 6, 2014, at 11:20 PM, Axb <ax...@gmail.com> wrote:
>>>
>>>> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>>>>>
>>>>> On Aug 6, 2014, at 1:23 PM, Paul Stead <pa...@zeninternet.co.uk> 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
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On Aug 7, 2014, at 11:00 AM, Axb <ax...@gmail.com> wrote:
> On 08/07/2014 06:55 PM, Philip Prindeville wrote:
>>
>> On Aug 6, 2014, at 11:20 PM, Axb <ax...@gmail.com> wrote:
>>
>>> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>>>>
>>>> On Aug 6, 2014, at 1:23 PM, Paul Stead <pa...@zeninternet.co.uk> 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
Posted by Axb <ax...@gmail.com>.
On 08/07/2014 06:55 PM, Philip Prindeville wrote:
>
> On Aug 6, 2014, at 11:20 PM, Axb <ax...@gmail.com> wrote:
>
>> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>>>
>>> On Aug 6, 2014, at 1:23 PM, Paul Stead <pa...@zeninternet.co.uk> 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
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On Aug 6, 2014, at 11:20 PM, Axb <ax...@gmail.com> wrote:
> On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>>
>> On Aug 6, 2014, at 1:23 PM, Paul Stead <pa...@zeninternet.co.uk> 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
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
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 <an...@balholm.com> 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
Posted by Andy Balholm <an...@balholm.com>.
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
Posted by Axb <ax...@gmail.com>.
On 08/07/2014 07:01 AM, Philip Prindeville wrote:
>
> On Aug 6, 2014, at 1:23 PM, Paul Stead <pa...@zeninternet.co.uk> 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
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On Aug 6, 2014, at 1:23 PM, Paul Stead <pa...@zeninternet.co.uk> 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
Posted by Axb <ax...@gmail.com>.
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
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by Axb <ax...@gmail.com>.
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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
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
Posted by Axb <ax...@gmail.com>.
On 08/06/2014 10:17 PM, Paul Stead wrote:
> Assuming I didn't change those too :)
>
> Guess what the MD5 of redacted@example.com<ma...@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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
Assuming I didn't change those too :)
Guess what the MD5 of redacted@example.com<ma...@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
Posted by Axb <ax...@gmail.com>.
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
Posted by Paul Stead <pa...@zeninternet.co.uk>.
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
Posted by Andy Balholm <an...@balholm.com>.
On Aug 6, 2014, at 2:00 PM, Axb <ax...@gmail.com> 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
Posted by Axb <ax...@gmail.com>.
On 08/06/2014 10:32 PM, Andy Balholm wrote:
>
> On Aug 6, 2014, at 12:00 PM, John Hardin <jh...@impsec.org> 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
Posted by Andy Balholm <an...@balholm.com>.
On Aug 6, 2014, at 12:00 PM, John Hardin <jh...@impsec.org> 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
Posted by John Hardin <jh...@impsec.org>.
On Tue, 5 Aug 2014, Andy Balholm wrote:
>
> On Aug 5, 2014, at 11:16 AM, John Hardin <jh...@impsec.org> 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 xxxx-xxxx-xxxxx-xxxx-xxxx 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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by Andy Balholm <an...@balholm.com>.
On Aug 5, 2014, at 11:16 AM, John Hardin <jh...@impsec.org> 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
Posted by John Hardin <jh...@impsec.org>.
On Tue, 5 Aug 2014, Andy Balholm wrote:
>
> On Aug 5, 2014, at 10:48 AM, John Hardin <jh...@impsec.org> 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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by Andy Balholm <an...@balholm.com>.
On Aug 5, 2014, at 10:48 AM, John Hardin <jh...@impsec.org> 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/' *
<http://indexfuturesgroup.us7.list-manage1.com/track/click?u=53ac11179f83318d2d210aa37&id=de05704f86&e=b5bf0a74b8>Click Here for the Full Report. <http://gallery.mailchimp.com/53ac11179f83318d2d210aa37/images/28930e15-84a1-4582-b8a3-db32c598a633.png>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!<http://indexfuturesgroup.us7.list-manage1.com/track/click?u=53ac11179f83318d2d210aa37&id=32048285b8&e=b5bf0a74b8>Courtesy of John McLane <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=6307433132&e=b5bf0a74b8>Facebook<http://indexfuturesgroup.us7.list-manage1.com/track/click?u=53ac11179f83318d2d210aa37&id=f7ccd12c7f&e=b5bf0a74b8> <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=d0a49bed7d&e=b5bf0a74b8>Twitter<http://indexfuturesgroup.us7.list-manage1.com/track/click?u=53ac11179f83318d2d210aa37&id=f96b8fc80a&e=b5bf0a74b8> <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=f361d4f730&e=b5bf0a74b8>LinkedIn<http://indexfuturesgroup.us7.list-manage1.com/track/click?u=53ac11179f83318d2d210aa37&id=09ff80e4b1&e=b5bf0a74b8>Nicholas 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 <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=d8bb283954&e=b5bf0a74b8>(click here for full-size image)<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=129e8f2b64&e=b5bf0a74b8>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<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=a778936d97&e=b5bf0a74b8> ) Traders should look for ways tomanage risk and/or position themselves for a possible volatile autumn forbeans.Jack on TV <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=8690871fda&e=b5bf0a74b8>June 18 <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=6d198f9133&e=b5bf0a74b8> Fed DayJune 14 <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=a3106809ff&e=b5bf0a74b8> Global Growth StoryJune 4T<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=139462335c&e=b5bf0a74b8> he Stars Align<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=e37d228896&e=b5bf0a74b8>Featured Program <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=4bfc8df671&e=b5bf0a74b8>Methodology: Capital Management ArbitrageDuration: 28.97 MonthsMinimum: $24,000Net Return: 191.5%Max Draw Down: -36.1%Click Here for More Info<http://indexfuturesgroup.us7.list-manage2.com/track/click?u=53ac11179f83318d2d210aa37&id=399f556553&e=b5bf0a74b8>What Are Managed Futures?Click here to find out of Managed Futures are a good fit for your portfolio.<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=60cf2896b8&e=b5bf0a74b8>25 Options Strategies <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=be93e19b3b&e=b5bf0a74b8>Download Your Handbook<http://indexfuturesgroup.us7.list-manage2.com/track/click?u=53ac11179f83318d2d210aa37&id=f052783e60&e=b5bf0a74b8> >>Risk Disclaimer and Disclosure StatementTrading futures and options involves the risk of loss. You should considercarefully whether futures or options are appropriate to your financialsituation. You must review the customer account agreement and riskdisclosure prior to establishing an account. Only risk capital should beused when trading futures or options. Investors could lose more than theirinitial investment. Past results are not necessarily indicative of futuresresults. The risk of loss in trading futures or options can be substantial,carefully consider the inherent risks of such an investment in light of yourfinancial condition. Information contained, viewed, sent or attached isconsidered a solicitation for business.Copyright © 2014 Index Futures Group, All rights reserved.You are receiving this email because you signed up to receive special newsfrom Index Futures Group.Our mailing address is:Index Futures Group233 South Wacker Drive#8625Chicago, IL 60606Add us to your address book<http://indexfuturesgroup.us7.list-manage.com/vcard?u=53ac11179f83318d2d210aa37&id=32646d7000>unsubscribe from this list<http://indexfuturesgroup.us7.list-manage.com/unsubscribe?u=53ac11179f83318d2d210aa37&id=32646d7000&e=b5bf0a74b8&c=6ad52d952b> update subscriptionpreferences<http://indexfuturesgroup.us7.list-manage.com/profile?u=53ac11179f83318d2d210aa37&id=32646d7000&e=b5bf0a74b8> <http://indexfuturesgroup.us7.list-manage.com/track/open.php?u=53ac11179f83318d2d210aa37&id=6ad52d952b&e=b5bf0a74b8>
struggle break back over resistance at 10675-10700 basis the August =
<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=38aba9a783&e=b5bf0a74b8>Click Here for the Full Report. <http://gallery.mailchimp.com/53ac11179f83318d2d210aa37/images/28930e15-84a1-4582-b8a3-db32c598a633.png>Futures Six-PackTuesday, June 3rd 2014Crude OilTraders have been keying off tightness of supplies in the Cushing, OKdelivery terminal versus plentiful overall crude supplies especially therecord amount sitting in the Gulf. Slack global economic data coupled withprospects for increased supplies coming from places like Iraq should keep alid on prices for now. The WTI/Brent spread has narrow toward $6 withEuropean refineries seeing cutbacks in demand...S&P 500This market for the most part has gone nowhere the last few trading sessiondespite the CNBC cheerleaders calling out each and every new all-time hightick. Traders will be waiting to hear from the ECB’s interest rate decisionon Thursday and then Friday’s monthly employment report...EuroThe Euro is trading higher this morning as the market continues to findsupport just below the 13600 level ahead of Thursday’s ECB meeting. Giventhe buildup in expectations, one would think we’ll see a sharp movedirection move once Draghi delivers the news. But for today, support staysat 13580-13600 and resistance at 13660-13680...Get the Futures Six-Pack delivered to your inbox daily!<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=a5006985a5&e=b5bf0a74b8>Courtesy of John McLaneBull Marketin CottonNicholas HouleMay 30, 2014We have had quite a sell off and looks like we may be finding asupport/bottom here. RSI has also reached oversold levels. <http://indexfuturesgroup.us7.list-manage1.com/track/click?u=53ac11179f83318d2d210aa37&id=d18ff3cdf1&e=b5bf0a74b8>(click here for full-size image)<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=ad77773504&e=b5bf0a74b8>Jack on TV <http://indexfuturesgroup.us7.list-manage1.com/track/click?u=53ac11179f83318d2d210aa37&id=8dc4d2fc1c&e=b5bf0a74b8>June 2N<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=9d4e3d64ac&e=b5bf0a74b8> ew Month, New Indicators<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=1e752cba8d&e=b5bf0a74b8>May 28T<http://indexfuturesgroup.us7.list-manage2.com/track/click?u=53ac11179f83318d2d210aa37&id=17b4a43080&e=b5bf0a74b8> he Bond Conundrum<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=fbe2b3f14e&e=b5bf0a74b8>April 30Twitter, an Expected Disappointment<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=36d27b8f5e&e=b5bf0a74b8>Featured Program <http://indexfuturesgroup.us7.list-manage2.com/track/click?u=53ac11179f83318d2d210aa37&id=30957e9462&e=b5bf0a74b8>Methodology: Capital Management ArbitrageDuration: 28.4 MonthsMinimum: $24,000Net Return: 202.5%Max Draw Down: -36.1%Click Here for More Info<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=ad5c5c6540&e=b5bf0a74b8>What Are Managed Futures?Click here to find out of Managed Futures are a good fit for your portfolio.<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=013af9959c&e=b5bf0a74b8>25 Options Strategies <http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=6a4c14f798&e=b5bf0a74b8>Download Your Handbook<http://indexfuturesgroup.us7.list-manage.com/track/click?u=53ac11179f83318d2d210aa37&id=72bc48ffdc&e=b5bf0a74b8> >>Risk Disclaimer and Disclosure StatementTrading futures and options involves the risk of loss. You should considercarefully whether futures or options are appropriate to your financialsituation. You must review the customer account agreement and riskdisclosure prior to establishing an account. Only risk capital should beused when trading futures or options. Investors could lose more than theirinitial investment. Past results are not necessarily indicative of futuresresults. The risk of loss in trading futures or options can be substantial,carefully consider the inherent risks of such an investment in light of yourfinancial condition. Information contained, viewed, sent or attached isconsidered a solicitation for business.Copyright © 2014 Index Futures Group, All rights reserved.You are receiving this email because you signed up to receive special newsfrom Index Futures Group.Our mailing address is:Index Futures Group233 South Wacker Drive#8625Chicago, IL 60606Add us to your address book<http://indexfuturesgroup.us7.list-manage.com/vcard?u=53ac11179f83318d2d210aa37&id=32646d7000>unsubscribe from this list<http://indexfuturesgroup.us7.list-manage.com/unsubscribe?u=53ac11179f83318d2d210aa37&id=32646d7000&e=b5bf0a74b8&c=91fbeb765e> update subscriptionpreferences<http://indexfuturesgroup.us7.list-manage.com/profile?u=53ac11179f83318d2d210aa37&id=32646d7000&e=b5bf0a74b8> <http://indexfuturesgroup.us7.list-manage.com/track/open.php?u=53ac11179f83318d2d210aa37&id=91fbeb765e&e=b5bf0a74b8>
news. But for today, support stays at 13580-13600 and resistance at =
rallies toward 13750-13780 until the June ECB meeting given they are =
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
type=3D"cite"><div><Screen Shot 2014-02-14 at 3.16.08 =
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
type=3D"cite"><div><Screen Shot 2014-02-14 at 3.16.08 =
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
Helgason.pdf></span><span><Screen Shot 2014-02-14 at 3.16.08 =
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
type=3D"cite"><div><Screen Shot 2014-02-14 at 3.16.08 =
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
Helgason.pdf></span><span><Screen Shot 2014-02-14 at 3.16.08 =
name="Screen shot 2014-04-09 at 9.10.23 PM.png"
filename="Screen shot 2014-04-09 at 9.10.23 PM.png"
name="Screen Shot 2014-02-13 at 11.58.27 AM.png"
filename="Screen Shot 2014-02-13 at 11.58.27 AM.png"
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
type=3D"cite"><div><Screen Shot 2014-02-14 at 3.16.08 =
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
type=3D"cite"><div><Screen Shot 2014-02-14 at 3.16.08 =
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
type=3D"cite"><div><Screen Shot 2014-02-14 at 3.16.08 =
<Screen Shot 2014-02-14 at 3.16.08 PM.png>
type=3D"cite"><div><Screen Shot 2014-02-14 at 3.16.08 =
<Tiffany Helgason.pdf><Screen Shot 2014-02-14 at 3.16.08 PM.png>
Helgason.pdf></span><span><Screen Shot 2014-02-14 at 3.16.08 =
name="Screen shot 2014-04-09 at 11.19.46 AM.png"
filename="Screen shot 2014-04-09 at 11.19.46 AM.png"
name="Screen shot 2014-04-09 at 11.36.44 AM.png"
filename="Screen shot 2014-04-09 at 11.36.44 AM.png"
name="Screen Shot 2014-02-19 at 12.07.50 PM.png"
filename="Screen Shot 2014-02-19 at 12.07.50 PM.png"
name="Screen Shot 2014-02-18 at 9.33.13 AM.png"
filename="Screen Shot 2014-02-18 at 9.33.13 AM.png"
name="Screen Shot 2014-02-18 at 9.33.23 AM.png"
filename="Screen Shot 2014-02-18 at 9.33.23 AM.png"
name="Screen Shot 2014-02-14 at 3.16.08 PM.png"
filename="Screen Shot 2014-02-14 at 3.16.08 PM.png"
name="Screen Shot 2014-02-13 at 3.44.24 PM.png"
filename="Screen Shot 2014-02-13 at 3.44.24 PM.png"
name="Screen Shot 2014-02-13 at 3.45.07 PM.png"
filename="Screen Shot 2014-02-13 at 3.45.07 PM.png"
name="Screen Shot 2014-02-13 at 3.24.01 PM.png"
filename="Screen Shot 2014-02-13 at 3.24.01 PM.png"
name="Screen Shot 2014-02-13 at 11.58.27 AM.png"
filename="Screen Shot 2014-02-13 at 11.58.27 AM.png"
name="Screen Shot 2014-02-13 at 9.11.39 AM.png"
filename="Screen Shot 2014-02-13 at 9.11.39 AM.png"
name="Screen Shot 2014-02-13 at 9.11.22 AM.png"
filename="Screen Shot 2014-02-13 at 9.11.22 AM.png"
name="Screen Shot 2014-02-12 at 4.50.46 PM.png"
filename="Screen Shot 2014-02-12 at 4.50.46 PM.png"
name="Screen Shot 2014-01-29 at 10.55.13 AM.png"
filename="Screen Shot 2014-01-29 at 10.55.13 AM.png"
mail8-db3.bigfish.com (Postfix) with ESMTP id 56101220067 for
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
Re: rule for repeated tracking numbers
Posted by John Hardin <jh...@impsec.org>.
On Tue, 5 Aug 2014, Andy Balholm wrote:
> On Aug 5, 2014, at 10:31 AM, John Hardin <jh...@impsec.org> 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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by Andy Balholm <an...@balholm.com>.
On Aug 5, 2014, at 10:31 AM, John Hardin <jh...@impsec.org> 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
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by Joe Quinn <jq...@pccc.com>.
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).