Our false positives handling process is interactive, so it's important to have the correct format, and it's also important that false positive submissions come from the system operator - since we may need to collaborate on an appropriate solution. False positives submitted by the end user or through some automated detection should be first reviewed by the system operator before they are submitted to us --- for example, if you have software that generates a false positive report each time a user pulls a message from their quarantine you will likely find that many of those messages are not what you would consider false positives globally on your system... they may even consist of messages that are dangerous or even against your TOS, perhaps selected by error or for curiosity's sake. ;-)

The important concept about false positives is that each case opens a dialogue between you (the subscriber, presumably a system operator) and our rule coding staff.  We should not receive spam or false positive reports directly from your customers (in general) because they are not directly authorized to make changes to your filtering system (among other things).

Similarly, particularly where false positives are concerned, we do not respond to third party requests for filtering changes --- this would open the door to security problems. This is why our false processing software validates the incoming message against our subscriber base and may even delete messages that are not submitted by registered users or authorized aliases.