 please feel free to forward this message to other possibly interested parties some caveats in decending order of concern NUMBER these messages could end up being falsely or incorrectly reported to razor dcc pyzor etc certain rbls too i don t think the results for these distributed tests can be trusted in any way shape or form when running over a public corpus NUMBER these messages could also be submitted more than once to projects like spamassassin that rely on filtering results submission for ga tuning and development NUMBER spammers could adopt elements of the good messages to throw off filters and of course there s always progression in technology by both spammers and non spammers the second problem could be alleviated somewhat by adding a nilsimsa signature or similar to the mass check file the results format used by spamassassin and giving the message files unique names mdNUMBER or sha NUMBER of each file the third problem doesn t really worry me these problems and perhaps others i have not identified are unique to spam filtering compression corpuses and other performance related corpuses have their own set of problems of course in other words i don t think there s any replacement for having multiple independent corpuses finding better ways to distribute testing and collate results seems like a more viable long term solution and i m glad we re working on exactly that for spamassassin if you re going to seriously work on filter development building a corpus of NUMBER NUMBER messages half spam half non spam is not really that much work if you don t get enough spam creating multi technique spamtraps web usenet replying to spam is pretty easy and who doesn t get thousands of non spam every week dan 