Support

Error Codes

The errors shown with error codes are 'Fail Safe' in the production version. The error code shown is for information and log analysis purposes only. Fail Safe command line scan results are ALWAYS 0 to ensure messages are not trapped by errors. All Fail Safe errors are reported to the log file with their actual result code.

ERROR_CMDLINE (65)

Command line error. Sniffer was called improperly.

ERROR_LOGFILE (66)

Cannot open log File.

ERROR_RULE_FILE (67)

Cannot open rules file. (Fail Safe)

ERROR_RULE_DATA (68)

Cannot create pattern matrix. Either an error occurred while reading the rule file or the system could not allocate sufficient memory to contain the pattern matrix. (Fail Safe)

ERROR_MSG_FILE (69)

Cannot open message file, or an error occurred while reading the file. (Fail Safe)
If it does seem that the message file was passed with a complete path, then there must be some other reason that SNF could not open the file.

1. Either the message file was gone when it got there. Something (IMail/Virus scanner/etc) may have moved the file. OR

2. There might be a permissions problem preventing SNF from opening the file. The new spool directory may have been set up with permission restrictions not originally present on the first spool directory.

If all messages are failing in SNF with ERROR_MSG_FILE then case 2 is more likely. If only some messages are failing SNF with ERROR_MSG_FILE then case 1 is more likely.

ERROR_ALLOCATION (70)

Allocation error during processing. (Fail Safe)

ERROR_BAD_MATRIX (71)

Cannot create pattern matrix. Either an error occurred while reading the rule file or the system could not allocate sufficient memory to contain the pattern matrix. (Fail Safe)

ERROR_MAX_EVALS (72)

The maximum number of evaluation paths was exceeded. This is generally harmless and should be considered informational unless it occurs frequently. (Fails Safe)

ERROR_RULE_AUTH (73)

The rulebase file was located and read but did not authenticate properly. This may indicate a corrupted or incomplete rulebase file or (more often) a typo in the authentication string or license ID. In snf2check.exe, be sure that the rulebase file being tested has a correct name such as abcd1234.snf, abcd1234.new or abcd1234.tst and that the corresponding authentication string is being used and that it has been typed properly. It is best to cut and paste license ids and authentication strings when possible.

ERROR_UNKNOWN (99)

An unhandled exception occurred. This is usually something that happened with the operating system. Please report these immediately to [email protected] (Fails Safe)

Bad File Descriptor Retrying

The getRulebase.cmd is having trouble downloading your rulebase. The problem is usually local. Start by downloading the file with a browser (http://www.sortmonster.net/Sniffer/Updates/.snf). At the very least this might tell you something new about what is happening -- either it will work, or it will give you some additional error information to help.

Also, you might also try clearing out any temporary files from previous downloads -- perhaps the script is complaining that it can't remove an old temp file or something like that. And you might want to check your firewall settings. For one customer, it was a fixed IP address that allowed getRulebase.cmd to download. He updated the rule to work off the DNS name to allow for the change in IP address for the rulebase update server.

ERROR_MSG_XHDRi

This error indicates that SNF was unable to inject the header data into the message. The process is to write a temp file containing the x-header information starting with a copy (in RAM) of the original. If the temp file can be written to disc without error then the old file is removed and the new file is put into its place.If something goes wrong with any of those operations then the MSG_XHDRi error is the result.

These errors usually indicate either a problem with the file system (failing basic operations such as writing, renaming, and deleting files) or a conflict with another program - for example, if something moves or locks the message file while this operation is in progress.

ERROR_SYNC_FAILED

Normally SNF will connect with our SYNC servers about once per minute. If there is network congestion or some other problem then the SYNC session might fail. It will be logged and a new session will be retried automatically. The only way to correct this (or at least minimize it) is to reduce network congestion. You may not be able to do that. If this message appears only occasionally then there is no cause for concern.

Error!: FileError snf_EngineHandler::scanMessageFile() Open/Seek

This indicates that the file name passed to SNF to be scanned could not be opened. Either the path was incorrect (might be due to the spaces in the file name) or the file did not exist when SNF tried to open it.

Error from SNFServer: cannot connect to socket (Connection refused)

This error occurs when SNF4SA is not able to connect to SNFServer. You must have SNFServer installed and running for a SNF4SA plugin to work. The SNF4SA plugin connects SpamAssassin to SNFServer. SNFServer performs the message scan and returns a result. The result is then interpreted by the plugin and provided to SpamAssassin. If you don't already have it you can get the Message Sniffer distribution for Windows or *nix on the Downloads page.

error:libpthread is required to build snf-server

Most likely you need to install the gnu development environment to get all the parts for building pthread apps. yum groupinstall 'Development Tools'

EvaluationMatrix::OutOfRange!

The SNF engine does an internal check on the rulebase file before it will use it. Therefore you should never see this error from a version 3 (or greater) SNF system unless something has corrupted the rulebase data in memory which is extremely unlikley.

[FAILURE]- MessageSniffer abcd1234.snf rule does NOT match with AuthenticationCode=abcdefghijkl123

(Where abcd1234 is your license id and abcdefghijkl123 is your authentiation code.) You have entered your rulebase name (abcd1234.snf) instead of your license id (abcd1234 - WITHOUT the .snf).

SNFClient.exe.err only state: Could Not Connect!

This error occurs when SNFClient cannot connect the SNFServer is either not accepting new connections or it is down. If it is down then restarting it helps by starting it again. If it is not down then restarting helps by abandoning all of the existing connections -- many of them will re-try and succeed when the SNFServer is active again.

This "stalling" effect is seen only when you rename the folder that contains the message files. It is probably not a good idea to rename the folder while there is any possibility of active scans in progress. Instead, create a new folder with the correct name for new scans (perhaps by date) and then abandon the older folder in place. New scans would be done in the new folder and old or existing scans would continue in the old folder until they were complete. By the time you do anything with the old folder it will be several generations behind and safe.

OR You could use a single directory for scans and have them always performed there. Then, depending upon the scan result, move them into the appropriate directory. This way you could always be assured that the scanner is finished with a file before it is ever moved. This is an efficient process on ext3 and most other modern *nix file systems since it only requires the adjustment of a node and that operation will itself be journalized first.

Unhandled Exception: snf_LoadNewRulebase()

That exception means that SNF was unable to open the rulebase file. This is either a permissions problem, or the .snf file does not exist where SNF is looking for it. Check your _snf_engine_cfg.log file and verify that the RuleFilePath: is what you expect. If it is then verify that the rulebase file at that location is accessible to the user running SNFServer. Most likely (from experience) the rulebase file is not yet present and needs to be downloaded.

Unhandled Exception: _snf_LoadNewRulebase() readIgnoreList()

Your SNFServer was unable to find the ignore list. This is considered to be part of the configuration so it will refuse to start without it. Presumably the install process would have created/copied a default ignore list into place. SNFServer is looking for the GBUdbIgnoreList.txt file in its workspace path. Check to see that the file exists and is readable by the user that runs SNFServer.