SNFMDaemon/Distribution_20101124/SNFClient_readme.txt

SNFClient Readme

Command line client for SNF. This utility formats and processes SNF_XCI
requests through the SNF Engine working on the local machine. In general
this utility can be used as a replacement for the earlier SNF command
line scanner. It is also useful for other uses such as debugging and
communicating with GBUdb.

Note: Unlike prior versions of SNF, this command line utility does not
need to be "branded" (renamed for the SNF license id).

_________
Help Mode

SNFClient.exe

  When called with no command line parameters the utility produces
  help and version information.

__________
Debug Mode

SNFDebugClient.exe

  When "debug" or "Debug" appears in the path to the program name
  or if the program's name is altered to include the word "debug" or
  "Debug" then the program will produce additional information about
  it's operation to aid in debugging problems. This includes the
  entire raw SNF_XCI request and response.

__________________
Message Scan Modes

  These modes are used to scan email message files (the data part of
  smtp). This utility can be used as a drop-in replacement for previous
  verions of SNF (Message Sniffer) for scanning messages. However, this
  new version does not need to be "branded" (renamed for the license id)
  and will ignore the authentication string if it is provided. Also,
  since the newer version of SNF uses a client-server model and not a
  peer-server model, there is no need for a "persistent" mode.

  If "persistent" is passed to this utility on the command line as it
  would be used in prior versions of SNF then it will be treated like
  a file name and the scan will normally fail since a file named
  "persistent" is not likely to exist.

SNFClient.exe <FileNameToScan>

  Scan Mode: Scans <FileNameToScan> and returns a result code.

SNFClient.exe <authenticationxx> <FileNameToScan>

  Compatibility Mode: Ignores <authenticationxx> then scans the
  <FileNameToScan> and returns a result code. This mode provides
  drop-in compatibility with previous versions of SNF.

SNFClient.exe -xhdr <FileNameToScan>

  XHeader Mode: Scans <FileNameToScan> and returns the result. Also
  outputs the contents of the X-Headers created by the SNF engine. If
  the SNF engine is configured to inject these headers then they will
  also have been injected into the <FileNameToScan>.

  The SNF Engine can be configured to provide the X-Headers only to
  the API without injecting them. In this case the XHeader Mode will
  display the X-Headers that would be injected, but they will not
  have been injected into the <FileNameToScan>.

  If the SNF Engine is configured not to produce X-Headers (none) then
  the XHeader Mode will not produce X-Headers because they will not
  have been generated by the engine.

  (note: -xhdr and -source options can be combined)


SNFClient.exe -source=<IP4Address> <FileNameToScan>

  Source-IP Mode: Scans <FileNameToScan> and returns the result. The
  provided source IP is injected into the scan as the first Received
  header so that the scanning engine will presume the IP is the source
  of the message. This allows you to pre-define the source IP for the
  message when there is no other received header or when the received
  headers may be incorrect or may not present the actual source of
  the message.

  (note: -xhdr and -source options can be combined)

_____________________________
SNFServer Status Report Modes

SNFClient.exe -status.second
SNFClient.exe -status.minute
SNFClient.exe -status.hour

  This mode returns the latest posted status report as indicated.
  Normally these status reports are also posted to files in the
  SNFServer workspace.

  In this mode the SNFClient will return a result code (error level)
  of 0 when the request is successful and 99 (or some nonzero value)
  when the request is not successful. This allows the SNFClient to
  be used to verify that the SNFServer is running.

  Note: In most other modes the SNFClient returns a fail-safe 0
  result code to avoid tagging messages as spam when there are errors.

________________________
XCI Server Command Modes 

These features will expand as needed in later versions.

SNFClient.exe -shutdown

  If the SNF Engine is running in an application that accepts SNF_XCI
  server commands then this mode will send that command. The shutdown
  command may have no effect if the application does not use the SNF_XCI
  server commnand interface or does not recognize the command.

___________
GBUdb Modes

  These modes are used to communicate with the GBUdb system on the
  local node. It is possible to test (read out) an IP record or make
  any of a number of changes to IP data in the GBUdb.

SNFClient.exe -test <IP4Address>

  Returns the current GBUdb statistics for the <IP4Address>

  SNFClient also returns a result code that matches the GBUdb range
  for the tested IP. These ranges are defined in the SNFServer
  configuration file. By default they are:

  20 - Truncate
  63 - Black
  40 - Caution
   0 - Normal

SNFClient.exe -set <IP4Address> <flag> <bad> <good>

  Creates or updates the data for <IP4Address> as provided. The
  <IP4Address> must be provided as well as at least one of
  <flag>, <bad>, and <good>. If <flag>, <bad>, or <good> are
  to be left unchanged then they should be entered as a dash "-".

  Examples:

  Set all data for an IP. The flag will be "ugly", the bad count
  will be 0 and the good count will be 1000.

  SNFClient.exe -set 12.34.56.78 Ugly 0 1000

  Set the flag to "ignore" and do not change the counts.

  SNFClient.exe -set 12.34.56.78 ignore - -

  Set the good count to 400 and do not change anything else.

  SNFClient.exe -set 12.34.56.78 - - 400

SNFClient.exe -good <IP4Address>

  Creates or updates statistics for the <IP4Address>. Increases the
  good count by one. (Record a good event)

SNFClient.exe -bad <IP4Address>

  Creates or updates statistics for the <IP4Address>. Increases the
  bad count by one. (Record a bad event)

SNFClient.exe -drop <IP4Address>

  Removes all local data for the <IP4Address>. Anything the local
  system "knows" about the IP is forgotten. Next time the IP is
  encountered it will be treated as new.

____________________
For More Information

See www.armresearch.com
Copyright (C) 2007-2008 Arm Research Labs, LLC.