> I'm using sa-3.2.5 on Linux with perl-5.6 and seem to be having a problem with
> the sought fraud rules and "Can't use \x{} without 'use utf8' declaration".
> 
> Am I doing something wrong or is this a bug?

It's been fixed with perl 5.8.0 (maybe even with 5.6.1).

> Please let me know how I can go about troubleshooting this or if there is
> further information I can provide.

Either change the rule causing the problem to avoid \x{}, or upgrade your
perl, or change SpamAssassin to add 'use utf8' into code generated from rules
when it sees it is being run with a pre-5.8 version of perl.

The 5.8 series has been around for more than 7 years now, the current stable
version is 5.10.1.

Tempted to close this bug report, cause the SOUGHT rule-set is third-party and not SA. Keeping open for now, since 3.2 still officially supports Perl 5.6.

From my posting to the SA mailing list:

On Monday September 28 2009 04:58:42 MySQL Student wrote:
> Mark suggested in the bugzilla update that I "change SpamAssassin to
> add 'use utf8' into code generated from rules when it sees it is being
> run with a pre-5.8 version of perl." How do I do this for the time
> being?

Try the following (for SA 3.2.5). I haven't tested it, but according
to the perl docs this is what is missing:


--- lib/Mail/SpamAssassin/Plugin/Check.pm	(revision 819489)
+++ lib/Mail/SpamAssassin/Plugin/Check.pm	(working copy)
@@ -271,10 +271,14 @@
 
   my $evalstr = $self->{evalstr};
 
+  my $needed_utf8_pragma = '';
+  $needed_utf8_pragma = 'use utf8;'  if $] >= 5.006 && $] < 5.008;
+
   # generate the loop that goes through each line...
   $evalstr = <<"EOT";
   {
     package $package_name;
+    $needed_utf8_pragma;
 
     $self->{evalstr2}

Close.

Problem is fixed in version of perl required by 3.3.

(In reply to comment #2)
> Tempted to close this bug report, cause the SOUGHT rule-set is third-party and
> not SA. Keeping open for now, since 3.2 still officially supports Perl 5.6.

"Perl 5.8.1 or a later version is required." - 3.3.2rc2 INSTALL

(In reply to comment #4)
> Close.
> 
> Problem is fixed in version of perl required by 3.3.

Roger.  Will bring up getting an official release policy that says we aren't supporting 3.2 anymore.

NOe:  If 3.2 (and earlier) is no longer supported, there are many open bug reports that should be closed as "wontfix."  Listing all 696 open bugs shows several of them: e.g. 5719, 5885, 5949, 6015, ... and that's just going by version numbers cited in the bug report titles.

(In reply to comment #6)
> NOe:  If 3.2 (and earlier) is no longer supported, there are many open bug
> reports that should be closed as "wontfix."  Listing all 696 open bugs shows
> several of them: e.g. 5719, 5885, 5949, 6015, ... and that's just going by
> version numbers cited in the bug report titles.

Yes and no.  I have a feeling some of those bugs will be retargeted but if they are resolved in 3.3.X, I agree completely.

It will be 100% up to the PMC but I've proposed the following schedules for Release and Support.  I am purposefully keeping them short & simple.  I feel the project will benefit from scheduled releases and this schedule is realistic and allows for volunteers to avoid major holidays and summertime.

Release Schedule:

The Apache SpamAssassin project goal is to produce three major or minor releases per year with release candidates proposed on or close to January 30th, April 30th & September 30th of each year.

Release Support:

A major release is supported for no less than 6 months after the release of the next major release.  This means that as of July 27, 2010, all versions prior to 3.3.0 are considered unsupported.  If and when 3.4.0 is released, version prior will then be consider unsupported approximately 6 months later.

Closing this as 'wontfix', the issue is resolved in perl 5.8.0 or later.