Description of problem: Spamassassin 3.0.1 in FC3 no longer allows you to disable subject rewriting on a per-user basis. It used to be possible to specify "rewrite_subject 0" in your user_prefs, but SA 3.0 has removed this option, instead there's the option "rewrite_header Subject", but you can't disable that in user specific config. You can try to set subject-rewrite to an empty string, but that still adds the X-Spam-Prev-Subject header and prepends a space in the original subject. Version-Release number of selected component (if applicable): spamassassin-3.0.1-0.FC3 How reproducible: Always Steps to Reproduce: 1. spamc < spam-mail | grep Subject Actual Results: Subject: [SPAM] .... X-Spam-Prev-Subject: .... Expected Results: Subject: ....
Upstream authors, any suggestion on this one?
From the man page Mail::SpamAssassin::Conf : " rewrite_header { subject â from â to } STRING [...] A null value for "STRING" will remove any existing rewrite for the specified header. [...] remove_header { spam â ham â all } header_name Headers can be removed from the specified type of messages (spam, ham, or "all" to remove from either). All headers begin with "X-Spam-" (so "header_name" will be appended to "X-Spam-"). " It's not 100% clear what "A null value is" (I'm guessing complete abscence rather than the empty string) and I have not tested the above myself.
The manual page does not mention any way to set things to nulls. Using just "rewrite_header subject" in the configuration file causes the extra space to be prepended.
Hmm, the manual may say one thing, but my mail server behaves differently. My personal /etc/mail/spamassassin/local.cf contains: rewrite_subject 0 My spam has no rewritten subject and no X-Spam-Prev-Subject header.
Hmm.. you probably don't have a "rewrite_header Subject [SPAM]" there in that case. One solution would be to remove it from the local.cf, and only enable it in user_prefs for the users who want it, but it requires the bulk of the users (well, bulk of my users) to configure spamassassin to tag messages, rather than requiring the few people (myself) to configure spamassassin to not tag messages reversing previous behaviour. It'd probably be best if there was just a way to unset a value in the configuration. Or even a way to clear all of the previous configuration for those who don't want to use the system's spam-filtering settings.
I was wrong, "rewrite_subject 0" is ignored by spamassassin-3.0.x. So it does appear there is no way for the user to override the system's setting?
Upstream author here. This was treated as an enhancement that was added to the 3.1 trunk and was not backported to the 3.0 branch. I think nobody brought up the issue of what happens when a sysadmin installs a global rewrite_header subject and users want to override it, so it was never treated as a bug fix to backport. See http://bugzilla.spamassassin.org/show_bug.cgi?id=3866 It is implemented in 3.1 by adding these four lines in Mail::SpamAssassin::Conf.pm in the rewrite_header code. This would work in 3.0. They delete the old rewrite header if the string value is empty or all whitespace. unless (defined $string && $string =~ /\S/) { delete $self->{rewrite_header}->{$hdr}; return; }
Can anyone confirm that this is the desired patch for 3.0.3? --- Mail-SpamAssassin-3.0.3.orig/lib/Mail/SpamAssassin/Conf.pm 2005-04-26 16:42:18.000000000 -0400 +++ Mail-SpamAssassin-3.0.3/lib/Mail/SpamAssassin/Conf.pm 2005-05-17 06:33:34.000000000 -0400 @@ -575,6 +575,10 @@ if ($hdr ne 'Subject') { $string =~ tr/()/[]/; } + unless (defined $string && $string =~ /\S/) { + delete $self->{rewrite_header}->{$hdr}; + return; + } $self->{rewrite_header}->{$hdr} = $string; return; }
Confirmed working, and it is heading toward upstream 3.0.4 target too.
http://people.redhat.com/wtogami/temp/spamassassin/ FC3 and RHEL4 packages available for testing.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-498.html