Generally, we coordinate the overall flow on the SpamAssassin-Users and SpamAssassin-Dev MailingLists. Then, for specific new functionality or rules, a Bugzilla bug should be created to track progress and provide a forum for discussion; any patches should be stored (as an attachment) on that Bugzilla bug.

By using a Bugzilla bug to track code changes, we have an easy way to find the discussion/timeline of that functionality's development at any point in the future, since we can simply say "see bug 2134 for details/discussion/arguments" etc.

The code itself is maintained in a Subversion repository which can be browsed via the following methods:

General stuff

Patches and Coding

Rule Development


  • InfraNotes: notes on our infrastructure at the ASF and elsewhere, and adminning it
  • InfraNotes2017: notes on our new ASF infrastucture
  • RsyncConfig: How rsync is setup, how to add new accounts, etc.
  • OpenInfraIssues: active bugs/requests we have open with the ASF infrastructure team
  • MassCheckSlave: how to set up a new mass-check slave server

Stuff about scoring

More Stuff

  • BayesStopList: information about the default Bayes "words to skip", and how they were chosen
  • MailManglingInTheField: Information about known ways a mail message can be changed in transit.
  • The SpamAsassin public corpus: an old collection of hand-filtered ham and spam for testing GA work, developing new filter techniques, and benchmarking filters.
  • GTUBE: the Generic Test For Unsolicited Bulk Email.
  • Package Building: RPM's, etc.

Historical information relating to the Incubation process

  • IncubatorToDo: To-do list for moving out of the Apache Incubator
  • ClaVettingProcess: How we tracked down code owners in order to relicense and the resolution of the process