bug in mailfilter.crm learnfile text output

Looks like maybe nobody ever used the learnfile option, or never looked at
what the resulting *text.txt actually contains when learnfile is used.

The text written is the text with *rewrites* applied *and* truncated to
decision_length.  So I assume that after the :learntofilehere: label, the
line

   output [:*:fileprefix::*:learnfile:text.txt] <append> /:*:text:/

should be changed to at least

   output [:*:fileprefix::*:learnfile:text.txt] <append> /:*:cmd_txt:/

and probably to

   output [:*:fileprefix::*:learnfile:text.txt] <append> /\n\n:*:cmd_txt:\n/

which would make it consistent with 4 similar lines above that in
mailfilter.crm:

   output [:*:fileprefix:nonspamtext.txt] \
                        <append> /\n\n:*:cmd_txt:\n/

   output [:*:fileprefix:nonspamtext.txt] <append> /\n\n:*:cmd_txt:\n/

   output [:*:fileprefix:spamtext.txt] <append> /\n\n:*:cmd_txt: \n/

   output [:*:fileprefix:spamtext.txt] <append> /\n\n:*:cmd_txt: \n/

There's also probably no reason why spamtext should have an extra blank
added that nonspamtext does not have, so those last two lines above should
probably have the blank before the final \n removed.

So tentatively that calls for 3 changes (so far), one substantive and two
minor.

I found this problem in 20060704-BlameRobert which is what I have been
using, and it appears to be unchanged in "Newest Slightly Unstable
Mainline".

There are two more output statements further down in mailfilter.crm which
are similarly questionable:

    output [:*:fileprefix:nonspamtext.txt] <append> /:*:text:/

and 

    output [:*:fileprefix:spamtext.txt] <append> /:*:text:/

But these are in the "---- should we consider automatic training?" section
so I don't what other considerations might apply, since I don't use
automatic training.


It seems I tend to use a lot of the advertised features, even the less
popular ones, which of course can be a drag.  But the only reason I was
using --learnfile (which implies --force) was not really a good one.  It is
just because --spamcss and --nonspamcss only permit the css file names to be
overridden, not the text.txt file names as needed.  I always want the .txt
file to be a record of what into the .css file.  When testing a lot of
experimental tweaks in a semi-live scenario this just keeps things sane.

I would propose to add commands --spamfile and --nonspamfile which might
perhaps ultimately replace --spamcss and --nonspamcss.  Or do people think
--spamcss should just be changed to imply both files (css and text) if the
file suffix is not given in the argument?  That should not involve a
significant amount of processing.  I would also proposed to remove the
redundant "text" before the ".txt" suffix, perhaps only in the new scenario.
I'm thinking would move things in a simplifying and useful direction while
retaining the most compatibility, but I'm a little less than confident that
I could anticipate other people's needs.  If we can agree on something
useful maybe I can code it up.

-Kurt



------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d