THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- In general, "false positive" spam filtering incidents by one or more specific sites are not actionable as bugs in SpamAssassin. These issues are best addressed on the SpamAssassin Users MailingList where a broad audience of SpamAssassin users can analyze the root causes and advise on solutions (which may include opening a valid bug, but likely will not.)
- It is extremely unlikely that a problem with any major mailbox provider (Gmail, Microsoft, GMX, Yahoo, etc.) delivering legitimate mail to a "Spam Folder" is in any way related to SpamAssassin. It is absolutely certain that such issues cannot be addressed by a SpamAssassin bug report. Large mail service providers generally use their own proprietary spam filters, NOT SpamAssassin.
- If you do not have a basically working SpamAssassin installation with which you can reproduce the issue and include evidence in your bug report of a bug in SpamAssassin, your bug report is likely to be closed as WORKSFORME or INVALID. Someone else's SpamAssassin installation accessible only through a web page that lets you "check your mail with SpamAssassin" is very likely to not suffice, as such sites frequently run outdated rulesets or even outdated SpamAssassin core code.
- Bugzilla is not a general SpamAssassin tech support channel. When in doubt about whether your issue belongs in Bugzilla, use the SpamAssassin Users MailingList. More eyes see messages there and the general user community is familiar with more diverse use cases than the SpamAssassin developers who see bug reports. The overwhelming majority of problems with SpamAssassin are not bugs per se, but rather errors in adapting SpamAssassin to special local circumstances.
- For enhancement requests, code contributions are usually helpful but are not strictly necessary. It is necessary to understand that SpamAssassin has a consciously constrained scope as a scoring tool for mail messages. It is not a mail handling agent of any sort and so does not deliver, block, or discard mail. It does not analyze any data format that is not at least approximately conformant to RFCs 822, 2822, and 5322 and their MIME extensions, e.g. individual mail messages and parseable mailbox formats.
- If you believe that you have an issue which is closely related to an existing bug which is not in RESOLVED or CLOSED status, you can add a relevant comment to the ticket or just add yourself to the CC list to be informed of progress.
- If you believe that you have an issue which is closely related to an existing bug which is in RESOLVED or CLOSED status, you should read the whole bug report including all comments carefully to make sure that you understand why it was closed before adding a comment, especially if the bug is marked as INVALID. If you still believe that you must comment on an INVALID bug report, you are almost certainly wrong and should seek an explanation on the SpamAssassin Users or Developers MailingLists before adding to what the development team has deemed to be NOT A VALID BUG.
- Bug reports are set to RESOLVED - FIXED status when code, rule, or documentation changes that fix the bug have been committed to the ASF code repository. If you do not use the "bleeding edge" code from the repository and update your rules regularly, you will not see the fix until your packager and/or sysadmin deploys the update. Slow packaging and/or deployment of current code or rules is not a SpamAssassin bug, so please do not re-open bugs which have been fixed in the current code.
Opening Bugs For Development
...