|Summary:||"mini debug" in message header info|
|Product:||Spamassassin||Reporter:||Loren Wilton <lwilton>|
|Component:||spamassassin||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Version:||SVN Trunk (Latest Devel Version)|
Description Loren Wilton 2004-08-28 01:43:37 UTC
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.