Documentation Home
Help! Errors
Help! False Positives
Help! Spam Leakage
Installation Guides
Features
Procedures
SNF Community
Software
Technology
Tools
Direct Support
Glossary
Q&A
Features
Reliability
We Own It
Every piece of code in Message Sniffer was built in our own labs, heavily tested, and thoroughly reviewed. More than 80% of the critical code in SNF has been in reliable service for years. There are no third party libraries for critical functions such as pattern matching, networking, threading, database operations, or critical timing. This means that we know exactly what all of the code is doing and how it interacts. It also means that if any of it misbehaves we can fix it.
Fail-Safe By Design
When we set out to build Message Sniffer, we realized that we were building a critical piece of infrastructure so we designed safety into the heart of it. Wherever possible errors and exceptions are handled so that there is no negative effect; and if a failure must occur we do our best to fail safely so that there is as little disruption as possible.
Here are just a few examples:
- If SNFClient can't connect to its server then it reports the error and returns a zero result so that the message it was scanning will go through. The result of a failure in this case is more spam and NOT more false positives!
- Whenever SNF is rewriting a message in order to inject headers, the new message is first written to a temporary file and then only swapped into place after the operation is complete. This ensures that if a problem occurs the original messag file remains intact or at the very least the new version is recoverable for delivery.
- If the GBUdb component of SNF cannot contact our systems for an extended period of time then it will simply continue to operate on its own by responding to and learning from its local environment.
Built For High Availability
SNFServer has been designed to run on systems that remain active for years without a break. There is no need to restart SNFServer for configuration changes and no need to notify it when a new rulebase file is available. Any kind of configuration change is detected automatically and put into place without distrupting normal operations.
In fact, changes like new configuration options and new rulebase files don't even slow down scanning operations.
When a new rulebase file is detected, that file is loaded and validated in a separate thread. Only when the new rulebase is ready is it made available to the scanning engine. Any scans that are in progress continue to use the old rulebase file (and configuration) until they are complete. Any new scans that begin will use the new rulebase file (and configuration). When all of the scanners using the old information have finished then the old information is discarded.