crm failing on a specific email
Jason Lewis <[email protected]> Fri, 09 Sep 2011 17:23:54 +1000
| Newsgroups | gmane.mail.spam.crm114 |
|---|---|
| Message-ID | <[email protected]> |
Hi Guys,
I received a spam that seems to cause CRM some grief.
When i tried to train it it as spam it crashes crm
I am using:
jason@debian:~$ crm -v
This is CRM114, version 20070810-BlameTheSegfault (TRE 0.7.5 (LGPL))
Copyright 2001-2006 William S. Yerazunis
Trace follows. Is this a problem with my CRM or with the email?
It could be the email as it's an email with an attachment. I seem to
recall though that crm is suppose to truncate the attachment before
processing or something?
I run it like this:
crm -t mailreaver.crm --spam <
../1315543615.M799816P25984V000000000000FD00I0000000000020F4B_19.debian\,S\=4324304\:2\,S
this is the (end of the) trace.
Executing line 341 :
Statement 341 is non-executable, continuing.
Parsing line 342 :
--> call /:reavercache_init:/
Executing line 342 :
Executing a user CALL statement
surgery on the var >:_cd:<
new value is ***>1<***
Parsing line 1112 :
--> {
Executing line 1112 :
Statement 1112 is an openbracket. depth now 1.
Parsing line 1113 :
--> match [:text_cache:] /./
Executing line 1113 :
Performing variable restriction.
Variable before expansion ':text_cache:' len 12
Variable after expansion: ':text_cache:' len 12
Using variable ':text_cache:' for source.
Found that variable
Checking restriction at start 12 len 0 (subscr=0)
Nothing more to do in the var-restrict.
match pattern expands to =.= len 1 flags 1 0
Regex matched.
Parsing line 1114 :
--> {
Executing line 1114 :
Statement 1114 is an openbracket. depth now 2.
Parsing line 1115 :
--> ### If the text_cache dir isn't there, create it
Executing line 1115 :
Statement 1115 is non-executable, continuing.
Parsing line 1116 :
--> # and it's subdirectories.
Executing line 1116 :
Statement 1116 is non-executable, continuing.
Parsing line 1117 :
--> #
Executing line 1117 :
Statement 1117 is non-executable, continuing.
Parsing line 1118 :
--> isolate (:tmp:) //
Executing line 1118 :
executing an ISOLATE statement
Parsing line 1119 :
--> syscall () (:tmp:) /ls :*:text_cache: 2>&1 /
Executing line 1119 :
executing an SYSCALL statement command's input wil be: ******
command output will overwrite var ***:tmp:***
command status kept in var ******
command will be ***ls reaver_cache 2>&1 ***
Must start a new minion.
Systemcalling on shell command ls reaver_cache 2>&1
SYSCALL output: 54 chars ---empty
known_good
known_spam
prob_good
prob_spam
texts
---.
surgery on the var >:tmp:<
new value is ***>empty
known_good
known_spam
prob_good
prob_spam
texts
<***
Parsing line 1120 :
--> match [:tmp:] <absent> /texts/
Mode #6, 'absent' turned on.
Executing line 1120 :
absent flag turned on...
Performing variable restriction.
Variable before expansion ':tmp:' len 5
Variable after expansion: ':tmp:' len 5
Using variable ':tmp:' for source.
Found that variable
Checking restriction at start 5 len 0 (subscr=0)
Nothing more to do in the var-restrict.
match pattern expands to =texts= len 5 flags 1 0
Regex matched but with absent flag, failing.
Parsing line 1128 :
--> }
Executing line 1128 :
Statement 1128 is a closebracket. depth now 1.
Parsing line 1129 :
--> }
Executing line 1129 :
Statement 1129 is a closebracket. depth now 0.
Parsing line 1130 :
--> return
Executing line 1130 :
Returning to caller at statement 1130
surgery on the var >:_cd:<
new value is ***>0<***
Parsing line 343 :
--> call /:reavercache_store:/ [:*:_dw:]
Executing line 343 :
Executing a user CALL statement
surgery on the var >:_cd:<
new value is ***>1<***
Catching FAULT generated on line 1138
FAULT reason:
crm: *ERROR*
This program has overflowed the ISOLATEd data area with a variable
that's just too big. The bad variable was named: :text:
Sorry, but this program is very sick and probably should be killed off.
This happened at line 1138 of file mailreaver.crm
Trying trap at line 1153:
trap (:broken_program_message:) /.*/
This TRAP will trap anything matching =.*= .
TRAP matched.
Next statement will be 1153
------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/