Hello Richard, Friday, January 11, 2008, 11:19:54 AM, you wrote:
> Greetings all, > We run a small email server for the company. Basically, for the > longest its been install and run, and have all messages that are above > a certain weight marked with **SPAM** in the subject line, and sorted > to a junk folder by the user's client. The users could then skim this > folder at their convenience and deal with the email. However, the > amount of spam has kept increasing, and we are coming to the point > where we will need to start deleting some email above a certain (very > high) weight. GBUdb produces a number of special result codes that might be useful for this purpose. These are in addition to the codes you are used to from SNF. One of these that will help in your situation is result code 20 which indicates that the message scan was truncated due to the source IPs statistics. If you are using conservative tuning for the truncate range in GBUdb then it should be reasonable to delete messages that were truncated. Depending upon your system's configuration this can result in safely deleting between 10% and 40% of traffic on average. > It looks like the beta of Sniffer is dramatically different than the > FAQ I've found out at the Wiki, so I have a couple of questions > 1) There doesn't seem to be a .state file - how can I see how well > Sniffer is working? The SNFServer program produces .status.log file's per second, per minute, and per hour. These can be appended to create ready trend analysis data, or they can be replaced each minute, second, etc to provide a single real-time snapshot. During your initial testing you can run SNFServer from the command line and observe real-time status info in the command window. > 2) How do I tie a specific message to the corresponding log file > entries? The same way as usual -- you can match the message file ID to the SNF log entry and usually the message headers (depending upon the platform). You have the option to produce classic SNF logs from the new version. By default the new XML based logs are used because they provide additional information. The <s../> element contains the scan information. The attributes include the scan result code, rule ID, message file name, timestamp... Contained within the <s../> element you can optionally include elements for scanner peformance, gbudb information, pattern matches... The configuration file contains comments that describe how the log files can be interpreted along with the configuration switches that select the logging configuration. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
