XML Logs (V3+)
The XML logs produced by the SNFMulti engine are designed to be as efficient as possible, to make good use of XML, and to be easily readable in a plain old text editor -- with a little practice.
Using the logs as XML data
Due to the nature of log files (a string of continuously appended entries), you will need to do a tiny bit of work if you wish to convert SNF's XML logs into "proper" XML for import into databases and other XML systems. Simply add the top level element and document descriptor tags of your choice, close the top element at the bottom, and you should be ready to go. What the SNFMulti engine provides for you are the "guts" of an XML document for a given logging period. By themselves SNF's XML logs are not well formed XML in the strictest sense... but they are not far from it and the modifications required to create well formed XML from them are trivial.
Reading the XML logs in a text editor
The XML logs are formatted so that they will be easy to read in an ordinary text editor with just a little practice. This makes it practical for system administrators to quickly open a log file and find what they are looking for -- or even to tail the log and watch the activity go by (if you can read fast!). Consider these entries (a scan error followed by a normal scan entry):
<s u='20070508012348' m='/spool/msg0123456789.msg' code='69' error='ERROR_MSG_FILE'/>
<s u='20070508012349' m='/spool/msg1123456789.msg' s='48' r='1234567' >
<m s='48' r='1234567' i='2394' e='2409' f='m'/>
<m s='48' r='2234567' i='2501' e='2515' f='m'/>
<m s='48' r='1234567' i='2394' e='2409' f='f'/>
<p s='10' t='8' l='3294' d='84'/>
<g o='1' i='101.201.31.04' t='u' c='0.12345' p='0.3342983' r='Caution'/>
</s>
The first scan of message file /spool/msg0123456789.msg produced a message file error.
The second scan occurred at 2007 05 08, 12:34:49 UTC, produced a scan result code of 48 matching rule ID 1234567. Performance and GBUdb data about the scan were also provided showing that it took 10 ms to setup the scan (open, and read the message file) and 8 ms to perform the scan operation. The scan covered 3294 bytes and used a maximum of 84 evaulators. According to GBUdb the source ip for this message (101.201.31.04) was found in the second Received header (ordinal 1). The flag on the GBUdb record for this IP is "Ugly" (t='u'), the confidence figure is 0.12345 and the spam probability figure is 0.3342983 placing this source in the "Caution" range.