Bug 7204 - Added headers ("X-Spam-*") should be customizable to enable user to be able to keep different versions of them
Summary: Added headers ("X-Spam-*") should be customizable to enable user to be able t...
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P2 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-02 20:42 UTC by Yuri
Modified: 2018-09-03 04:47 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri 2015-06-02 20:42:36 UTC 
I have my mail checked by spam assassin twice. One time my provider runs it without some CPU intense checks enabled (as they explained), because they just can't afford to run CPU intense checks for everybody. I run it the second time on the same messages with all CPU intense checks.

My spam assassin overwrites the original X-Spam-* headers on the messages. As a result, the first checker's status gets lost.

I think, the string "X-Spam" should be customizable in the user config file. Currently it is hard-coded (ex. in SpamAssassin/PerMsgStatus.pm).

Most people probably don't run this way, or don't care to lose such info, so this isn't the major feature. But this is offset by it being very easy to implement (new config option).
Comment 1 Kevin A. McGrail 2015-06-02 21:37:58 UTC 
Feature requests are one of the harder things to make time to address.  Can you take a pass at coding what you want for consideration?

Regards,
KAM
Comment 2 Mark Martinec 2015-06-03 00:44:30 UTC 
> My spam assassin overwrites the original X-Spam-* headers on the messages.
> As a result, the first checker's status gets lost. 
> I think, the string "X-Spam" should be customizable in the user config file.
> Currently it is hard-coded (ex. in SpamAssassin/PerMsgStatus.pm).

Alternatively, make removal of existing markup configurable
(and making sure that new X-Spam-* header fields are always
added at the top of a header section).
Comment 3 Yuri 2015-06-03 01:05:33 UTC 
One easy alternative solution is to add the "Rewrite with regexp" feature, that will be run on all old headers before modification.
So the older X-Spam headers can be put out of the way of the new ones.

I am still deliberating which of these three solutions is the best.