svn commit: r417910 - in /spamassassin/trunk: lib/Mail/SpamAssassin/EvalTests.pm rules/20_body_tests.cf

[fe...@apache.org]

Author: felicity
Date: Wed Jun 28 17:38:26 2006
New Revision: 417910

URL: http://svn.apache.org/viewvc?rev=417910&view=rev
Log:
move a test rule into EvalTests

Modified:
    spamassassin/trunk/lib/Mail/SpamAssassin/EvalTests.pm
    spamassassin/trunk/rules/20_body_tests.cf

Modified: spamassassin/trunk/lib/Mail/SpamAssassin/EvalTests.pm
URL: http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/EvalTests.pm?rev=417910&r1=417909&r2=417910&view=diff
==============================================================================
--- spamassassin/trunk/lib/Mail/SpamAssassin/EvalTests.pm (original)
+++ spamassassin/trunk/lib/Mail/SpamAssassin/EvalTests.pm Wed Jun 28 17:38:26 2006
@@ -3081,4 +3081,18 @@
   return 1 if ($self->{tvd_vertical_words} >= $min && $self->{tvd_vertical_words} < $max);
 }
 
+# came up on the users@ list, look for multipart/alternative parts which
+# include non-text parts -- skip multipart/related parts which occurs in ham
+sub check_ma_non_text {
+  my $self = shift;
+
+  foreach my $map ($self->{msg}->find_parts(qr@^multipart/alternative$@i)) {
+    foreach my $p ($map->find_parts(qr/./, 1, 0)) {
+      return 1 if ($p->{'type'} !~ m@^text/@i && $p->{'type'} !~ m@^multipart/related$@i);
+    }
+  }
+  
+  return 0;
+}
+
 1;

Modified: spamassassin/trunk/rules/20_body_tests.cf
URL: http://svn.apache.org/viewvc/spamassassin/trunk/rules/20_body_tests.cf?rev=417910&r1=417909&r2=417910&view=diff
==============================================================================
--- spamassassin/trunk/rules/20_body_tests.cf (original)
+++ spamassassin/trunk/rules/20_body_tests.cf Wed Jun 28 17:38:26 2006
@@ -28,3 +28,7 @@
 # messages where generally there are lots of spaces mean the message is spam.
 # 8.532  10.6051   0.1897    0.982   0.75    0.01  T_VERTICAL_WORDS_TVD_1
 body TVD_SPACE_RATIO	eval:tvd_vertical_words('0','10')
+
+# 0.767   0.9097   0.0000    1.000   0.84    1.00  MULTIPART_ALT_NON_TEXT
+body MULTIPART_ALT_NON_TEXT	eval:check_ma_non_text()
+

Re: new eval rules vs sa-update

[Theo Van Dinter <fe...@apache.org>]

On Thu, Jun 29, 2006 at 10:57:18AM +0100, Justin Mason wrote:
> - (1) it breaks people running "sa-update" on an svn trunk build, since
>   now the svn trunk update set includes references to an EvalTests.pm
>   function that won't exist in older revs.   

Irrelevent IMO.  If one is running a dev version, there will be issues
like this that have to be accepted.  sa-update is meant to work for
released versions, not dev versions.

> - (2) I think we wanted to reduce the ongoing use of EvalTests.pm in
>   general, as a goal, iirc.

That depends who you ask apparently (more below).

On Thu, Jun 29, 2006 at 04:21:54AM -0700, Loren Wilton wrote:
> How hard would it be to make an evaltests plugin that literally contains
> whatever rules are currently in evaltests.pm?

So ...  Last year at ApacheCon US a bunch of us had a discussion about this,
and generally decided it would be best to get rid of EvalTests and move the
functionality into plugins.  So I then spent 2 or 3 days worth of time going
through and doing that, ending up with:

http://svn.apache.org/repos/asf/spamassassin/branches/tvd-evaltoplugin/

(now horribly out of date, btw.)

Everything looked good, except that certain people started complaining about
the idea, the implementation, and generally were against getting rid of
EvalTests.  It didn't really move forward from there, so that was the end of
that.

> Yes, this is a kludge.  But if it can be done in 10 minutes vs 10 months or
> even 10 days to split evaltests into 150 silly separate plugins, one for
> each rule, then it might be the right thing to do.  It could be broken up
> more later once it was out of the main project body.

I thought a plugin per rule would be really annoying, so I split it up
into (iirc) 5 or 6 loosely related plugins (whitelist/blacklist, header
rules, body rules, etc.)

On Thu, Jun 29, 2006 at 12:26:01PM +0100, Justin Mason wrote:
> well, I'm not suggesting that we kill off the *current* contents of
> EvalTests.  instead we can leave those there -- but future additions
> should be kept out of that file if possible.

I'm +1 to killing off EvalTests, btw.  I argued about this before,
so I don't want to fully rehash it again -- see the thread:

http://www.nabble.com/forum/ViewPost.jtp?post=2124116

I'd be willing to expend some effort doing this process again (only if we all
agree (again?) ahead of time to do it).  The main time suck now is to merge
the changes in trunk since the branch, which will likely be a few hours worth
of work.

> As to the ease of moving the current contents into a new plugin .pm.
> Actually this wouldn't be so easy, since people using a pre-move
> copy of EvalTests.pm would then wind up with duplicated code; one
> function in EvalTests.pm, and another one colliding with it from
> the plugin .pm.

Again, irrelevent IMO.  If people are using the development version,
they need to accept that sometimes things will blow up and that they will
need to keep up with changes.  It's a development version for a reason.

-- 
Randomly Generated Tagline:
"The cardinal rule at our school is simple. No shooting at teachers. If
 you have to shoot a gun, shoot it at a student or an administrator."
                 - "Word Smart II", from Princeton Review Pub.