http://bugzilla.spamassassin.org/show_bug.cgi?id=3733
Summary: "mini debug" in message header info
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P4
Component: spamassassin
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
Questions frequently come up on the SA-users list of the general form of "why
(are|aren't) my messages (auto-learned|treated as spam|affected by AWL|etc).
In other words, why did SA make a particulat decision based on the apparent
score.
In many cases without running a specific message through debug, one can only
speculate, because the decisions are based on scoreset variations and vaarious
other permutations that aren't immediately obvious from the normal rule and
score info in the header. In some cases running the message through debug
won't really tell you either, because conditions may have changed (eg: the
baayes score might be different, different net tests might hit, etc.)
Suggest a "mini debug" type of option that will make the header info slightly
noiser by giving small justifications for some of the more important decisions,
most notably those based on scores using scoresets other than the one displayed
in the header, and things like auto-learning that are based on additional
information that the user can only guess.
The idea is just to add a few words to the existing text to give the
justification, for instance
auto-learn: no (already learned)
auto-learn: no (2.1)
where the first might indicate auto-leanring failing because the message has
been learned, and the second shows the score the auto-learn decision was based
on, which might not have been the normal score assigned to the message
elsewhere int he header.
The idea is this is an option that could be turned on with minimal effect on
the mail stream, and will provide justifications for classification decisions
on all mail (that gets added header info) while it is on. Obviously the detail
would not be huge, but it should be enough to make it obvious why decision X
was made. Clearly the code knows why it is making a particular decision, so I
would hope it would not be too hard to leave traces of why those decisions were
made that could later (or maybe at decision time) be placed in the message
headers.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
