Santronics Software, Inc.,
Wildcat! Anti-Spam/Anti-Virus Software Integration

Introduction:

Wildcat! is an advanced client/server database system which offers a files and mail database/exchange sub-system.  Based on the type of Wildcat! operation,  it may be important the files database is protected with Anti-Virus (AV) technlogy and the mail database is protected with both Anti-Virus and Anti-Spam (AS) technology.

It is important to note Wildcat! does not directly offer AS or AV technology or products to help protect your system.   Instead,  Wildcat! provides "On-Demand" features, hooks and advanced optionss to allow the integration with established vendor software specializing in AV/AS protection.

Since Wildcat! has a files database and mail database,  there are two distinct or set of methods used to handle each database subsystem:


Files Database Virus Checking Methods

Wildcat! offers four different means for a remote user to upload a file;  via direct dialup/telnet,  via ftp, via the web or via the free GUI frontend wcNavigator.   After a file is uploaded and before the file is added to the Wildcat! Files Database,   Wildcat! will check for a wcBASIC  "scanfile" hook which will allow the opportunity to run additional external file processing operation.     So depending on how the user is connected, the following hooks listed in Table1 are used:

Table 1:
File Upload Hosting Service ScanFile hooks

scanfile.wcx Called for files uploaded via direct dialup/telnet connection.
ftpscanfile.wcx Called for files uploaded via FTP connection.
httpscanfile.wcx Called for files uploaded via the WEB connection.
navscanfile.wcx Called for files uploaded via wcNavigator connection.

The following figure 1 illustrates the steps involved in uploading a file and how a "scanfile" hook can be used to prepare an anti-virus file check:

Figure1-ScanFile.jpg (24764 bytes)

The following describes the steps involved in figure 1:

Step 1:   A user connects to the Wildcat! Host Service which can be a text/console host such as direct dial up or telnet,  a FTP host,  a WEB host or the wcNavigator GUI host server.  The user starts the uploads process and sends a file to the Wildcat! Host Service. 
Step 2:  The Wildcat! Host Service receives the file into a temporary storage holding folder.
Step 3:  The Wildcat! Host Service will then check for the existence of the xxxScanFile.wcx program.  If the program does not exist, then the host service goes directly to Step 8 to complete the process of adding the file information into the database and moving the file into the file area physical file storage folder.   No post processing is performed in this case.  However, if the program does exist, then the Wildcat Host Service will call the program.
Step 4:  The xxxScanFile.wcx program can be written to call the anti-virus software installed on your system passing the name of the temporary storage file.
Step 5: 

The anti-virus software performs the virus checking on the temporary file.

Step 6:  Depending on how the anti-virus software is designed to work and how the sysop wishes to handle the scan,  one possibility is that it can delete the file,  rename it or leave the file as is.  This is important because when the anti-software has completed the file scan and returns back to xxxScanFile.wcx,  it needs to somehow inform the hook the result of the scan.  Some Anti-virus software will return errorlevels, so for the sake of illustration we will assume an errorlevel will be used.  An errorlevel of 0 means the file is good and a non-zero errorlevel means the file has failed the scanner, it has a virus.
Step 7:  From a Wildcat! standpoint, all xxxScanFile.wcx wants to know is whether the file is good or bad,  TRUE or FALSE, respectively.   This TRUE or FALSE indicator is returned to the Wildcat! Host Service.  If the errorlevel returned in step 6 is zero, a TRUE value is returned to the host. If the errorlevel in step 6 is non-zero, then a FALSE value is returned to the host.
Step 8:  If xxxScanFile.wcx returns TRUE,  the host will begin the process of sending the file to the Wildcat! Files Database as a successful, clean file upload.    If xxxScanFile.wcx returns FALSE,  the host will still continue the process of adding the file to the database, however, the file is marked as a "Failed Scan."   A file marked "Failed Scan" will locked out by the system. No users are allowed access to the file.  Only the Administrator or the original uploader has access to the file..  If the file was deleted by the Anti-Virus software back in step 5, then only the file entry in the datbase is added with no physical file associated with it.
Step 9:  The Wildcat! Server receives the file and saves it in the database.

Please note the scanfile hooks can be used for other file processing concepts , not necessarily just for anti-virus operations.


Mail Spam and Virus Checking Methods

For the mail system,   Wildcat! offers the following "Out of the box" hosting methods allowing for a remote user to post a message:

By "Out of the box" we mean, the installed package offers the above methods as available mail clients.  There are other ways mail can be posted, such as 3rd party Fidonet Netmail and Echo Mail Systems which may be a viable candidate for spam and virus checking as well.  However, we will concentrate on the built-in methods that are available with the base installation.

Important Considerations

When we are dealing with the mail system and the idea of   pre-scanning messages for spam or viruses, there exist a few major and even complex design or operational issues which must be considered.  

First, for large or heavy email systems,  it would not be very efficient to run a "on-demand" mail scanner for each message as they arrive.   This may put a heavy load on the system and also slow down the mail import rate.   It may be necessary to have use a scheduling concept where a collected number of messages are scanned.

Second, currently the Anti-Spam market is still at its infancy.   Newer technology is being invented which handles spam mail more accurately.

and third, the complexity of a mail scanner is much higher than for file uploads.

As such because of these major considerations,  as of  Wildcat! v5.6.450.6, much  of what is outlined in this discussion has not been completed or finalized.     However, the SMTP method is finalized and we will used the SMTP method for the basis of adding AV and AS consideration into Wildcat!

If we consider the method of using wcBASIC xxxScanFile.wcx hooks to preprocess uploaded files for mail using xxxScanMail.wcx hooks,  ....

MailFlow.jpg (48904 bytes)

Figure 1 illustrates the Wildcat! Mail Processing client/server operations with a focus on showing the possible methods external mail can be received and import into the Wildcat! Mail database and within these methods, show the possible AV/AS mail scanning interface points.  

The possible mail importing or  processes are:

There are  four possible (4) AV/AS scanner interface points for pre-processing new mail before it is importing into Wildcat!:

AV/AS Scanner (1) This interface point is a design consideration and is not currently implemented.

Server-side AV/AS mail scanner hooked into the Wildcat! SDK function AddMessage().  This backend approach will allow Wildcat! to offer AV/AS mail scanning processing across the board for all possible Wildcat! client connections attempting to add mail into the Wildcat! mail database.

AV/AS Scanner (2) This interface point is a design consideration and is not currently implemented.

Hosting Client AV/AS mail scanner hooked into the wcBASIC "xxxScanMail.wcx" hooks,  one hook for each possible Hosting Service.

AV/AS Scanner (3) This interface point is a design consideration and is not currently implemented.

NEWS clients AV/AS news scanner.

AV/AS Scanner (4) SMTP receiver AV/AS email scanner using the SMTPFILTER.WCX wcBASIC hook.

AV/AS Scanner (1)

Starting with the interface AV/AS Scanner (1), the goal is to provide a server-side mail scanning operation which applys to all possible Wildcat! mail clients accepting mail for import.   This interface point is currenly only a design consideration and is not currently implemented.  It is discussed here for possible future designs. 

The Wildcat! SDK function "AddMessage()" is used to add a message into the mail database.  All mail clients must use the SDK to add new mail.    Using this server-side interface point makes any other interface points unnecessary and redundant.   However,  this server-side interface point would be a high-overhead item if each message was scanned by the server when the AddMessage() function is called.   All automated mail processes import rates would be degradated with a slower server performance.   Hence,  it is important to have AV/AS scanner interface points which are client driven.

AV/AS Scanner (2)

This interface point is designed to handle mail checking for human or user interactive mail posting such as creating mail via the Web, Console Mode, wcNavigator, NNTP News clients or any other hosting services provided by Wildcat! which allows users to import mail.   This interface point is a design consideration and is not currently implemented.  However, this interface point is scheduled to be implemented once the AS/AV methods are finalized.

The common design for a Wildcat! Host Services to programmatically process user data is to use the wcBASIC run time engine to create programming hooks as such xxxScanMail.wcx applications. This interface point design is similar to the Wildcat! File Upload "ScanFile" interface points, however, in this case, we are scanning mail, not files.

AV/AS Scanner (3)

This interface point is designed to handle NNTP news articles importing from a news server using the wcNEWS utility.  This interface point is a design consideration and is not currently implemented.  However, this interface point is scheduled to be implemented once the AS/AV methods are finalized.

The News client AV/AS mail scanner can use a similar wcBASIC xxxScanMail.wcx concept however, a batch processing design needs to be considered since the news client imports mail in batches..

AV/AS Scanner (4)

This interface point is designed to handle incoming email via the Wildcat! SMTP server.  Currently, Wildcat! offers a method to implement a AV/AS scanner using the SMTPFILTER.WCX feature along with the  EnableReceiverBin SMTP option which enables the storage of incoming mail in a different prespool directory before the wcSMTP router can process the mail.

Since this interface point is currently available, we will focus the discussion using this method.  In figure 1,  the following steps describe how email is received by the wcSMTP receiver and processed for importation.

Step 1: A remote SMTP sendmail client connects to the Wildcat! SMTP receiver to begin the process of sending a email message.
Step 2: When the email is accepted, it will be stored in either the receiver queue or prespool queue depending the "EnableReceiverBin" option.  If disabled,  the email is stored in the prespool queue and and a signal is sent to the Wildcat! SMTP router to begin processing the mail.  If the option "EnableReceiverBin" is enabled, the email is stored in the receiver queue which is not checked by the Router.  When this is the case,  the SMTPFILTER.WCX can be used to call the AV/AS mail scanner installed on the system.  If the SMTPFILTER.WCX application does not exist, then the email is held in the receiver queue.   In this case, it is possible to setup a scheduled event to run a AV/AS mail scanner.  This is recommended for high-volume mail systems.
Step 3: When the mail is stored in the receiver queue,   the AV/AS mail scanner is started and it begins to scan the queued email.    The AV/AS mail scanner will move "good" email into the prespool directory and delete or discard bad mail.   Once the good email is moved to the prespool directory,   it should signal the Wildcat! Router to begin processing the mail.
Step 4: The Wildcat! Router checks the prespool queue for new email and decides if the email is local or to be relayed to a different domain.