Re: crm failing on a specific email

Jason Lewis <[email protected]> writes:

> 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's a really-huge-email that overflowed the isolation window.

The fix(es) possible are to train just the first megabyte or so, or
to use the -w nnnnnnnnn command to set a bigger window.  
Usually people route incoming email through procmail or somesuch, and
just send the first 4 to 16K or so to CRM114, as that's the 
most likely payload (and actually __improves__ accuracy because
word salad is usually appended rather than prepended)

Here's why I think so:  [...]

> 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/