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: |
|
| 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:
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, ....
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. |