This page is intended for SpamAssassin users who are not actively involved in SpamAssassin development. For advice on how project contributors should work on bug reports using Bugzilla, see: Using Bugzilla  

Reporting Bugs As A SpamAssassin User

Anyone can create an account in our Bugzilla instance to create, watch, and respond to bug reports and narrowly defined enhancement requests. Bugzilla is not a general SpamAssassin tech support channel. Many problems users have are more readily addressed to the SpamAssassin Users MailingList, where a broad spectrum of users (including many of the active SpamAssassin developers) actively assist each other on a daily basis. Examples of problems which DO NOT merit a bug report:

1. I need help installing or configuring SpamAssassin.
2. I don't understand how SpamAssassin works.
3. A SpamAssassin deployment that I don't manage misclassified my mail.
4. I believe that SpamAssassin is the cause of a mail classification error that cannot be independently reproduced. 
5. I want SpamAssassin to do more than analyze mail messages to produce a simple "spaminess" score.
6. A SpamAssassin rule matches messages which it is intended to match, despite them being ham.
7. I have a great idea for a new rule.
8. My outdated SpamAssassin package doesn't include a fix for a resolved bug. 

Bug reports like those will probably be swiftly closed as "INVALID" with a recommendation to take your issue to the mailing list. This is not saying that your issue is not real and valid, only that it is not actionable as a bug in SpamAssassin.  

How to make your bug report actionable 

• For code bugs, demonstrate the bug in SpamAssassin in a reproducible fashion by including one or more sample messages with all RFC822 headers intact. Incorrectly classified messages or messages that hang or crash SA programs when scored by the current release of SpamAssassin using the default rules, scores, and threshold.are generally required . 
• For functional enhancement requests, define the enhancement clearly and defend with real-world evidence the proposition that it will improve the accuracy of SpamAssassin's scoring of existing mail. 
• If you cannot provide unaltered sample messages as evidence, provide minimally redacted versions. In general, the only things that should be potentially subject to redaction are the local parts (i.e. user names) of email addresses, real names of parties other than yourself,  and actually sensitive message content. 
• Proposed code and/or documentation fixes are very welcome. Contributions beyond trivial changes (as judged by a "lazy consensus" of active contributors) can only be accepted subject to the Apache ICLA (and for some contributors, the CCLA as well.) 
• If asked for more information, provide it if you can or explain why you cannot. 

What to expect after you submit a new bug report

• You will be mailed about updates to the bug report unless you specifically opt out.
• You should get some response within a few days. Please be patient, as SpamAssassin is maintained by a team of volunteers who work on it in our free time. 
• You may be asked for more details.
• You may be challenged to confirm factual details.
• If you have included a non-trivial contribution in code or documentation, you will be asked to submit an ICLA if one is not already on file for you. 
• If you abandon a bug report that you opened, it is likely to be abandoned by anyone who might have fixed it with your cooperation. 
• A fixed bug will be closed by setting its status to "RESOLVED FIXED" after the code fix is committed to the trunk of the ASF Subversion repository. This does not mean that the fix is deployed on production systems, only that it is available for users to deploy. Typically, only rule changes get deployed to most systems using SpamAssassin automatically between releases, and even rule changes can take up to a week to appear in the current feed due to the process of Rule QA.