Bug 147464 - spamassassin no longer allows disabling subject rewriting
Summary: spamassassin no longer allows disabling subject rewriting
Alias: None
Product: Fedora
Classification: Fedora
Component: spamassassin   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Warren Togami
QA Contact:
Depends On:
Blocks: spamassassin_RHEL4
TreeView+ depends on / blocked
Reported: 2005-02-08 10:00 UTC by Oskari Saarenmaa
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version: RHSA-2005-498
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-23 19:19:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:498 normal SHIPPED_LIVE Moderate: spamassassin security update 2005-06-23 04:00:00 UTC

Description Oskari Saarenmaa 2005-02-08 10:00:43 UTC
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):

How reproducible:

Steps to Reproduce:
1. spamc < spam-mail | grep Subject

Actual Results:
Subject: [SPAM] ....
X-Spam-Prev-Subject: ....

Expected Results:
Subject: ....

Comment 1 Warren Togami 2005-03-31 11:22:43 UTC
Upstream authors, any suggestion on this one?

Comment 2 Sitsofe Wheeler 2005-03-31 20:02:15 UTC
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.

Comment 3 Oskari Saarenmaa 2005-04-05 11:27:35 UTC
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

Comment 4 Warren Togami 2005-04-05 12:37:16 UTC
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.

Comment 5 Oskari Saarenmaa 2005-04-05 12:47:27 UTC
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.

Comment 6 Warren Togami 2005-05-16 07:30:40 UTC
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?

Comment 7 Sidney Markowitz 2005-05-16 13:29:20 UTC
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};

Comment 8 Warren Togami 2005-05-17 21:46:07 UTC
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;

Comment 9 Warren Togami 2005-05-24 21:35:41 UTC
Confirmed working, and it is heading toward upstream 3.0.4 target too.

Comment 10 Warren Togami 2005-06-06 06:19:31 UTC
FC3 and RHEL4 packages available for testing.

Comment 12 Josh Bressers 2005-06-23 19:19:24 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.