[Top] [Prev] [Next] [Bottom]




Validation


The validation configuration details provide MIMEsweeper with the information it needs on how to perform validation of the raw data found in a mail message or Web data, as a result of recursive disassembly.

MIMEsweeper uses configured instances of `plug-in' validators to perform the validation task. A plug-in validator is a dynamic link library (.DLL) that accepts a data component, validates it and then generates a result, known as a <Response>, indicating the results of the validation.

The open architecture of MIMEsweeper allows different plug-in validator instances to be configured, as required.

Third party vendors also provide plug-in validators for MIMEsweeper.

MIMEsweeper currently supplies the following plug-in validators:

MAILsweeper also uses the `built-in' validator AMUcheck. This validator is built in to the main body of the MAILsweeper system and provides user and location authorisation. For more details see page 7-97.

During validation, each configured validator instance checks each data component generated during recursive disassembly, for the presence of security threats. Every check generates a <Response> indicating the results of the validation.

Lotus Notes and Exchange systems only. MAILsweeper cannot perform validation on encrypted messages.

When validation is complete, MIMEsweeper examines the collection of <Response> values generated by the configured validator instances and uses them to determine a final disposition for the message or Web data. It is this disposition that controls the actions performed to dispose of the message or Web data.

The final disposition is determined by the <Response> found to have the highest priority.1 During disposal, appropriate action is taken on the message or Web data, depending on the final disposition selected.

Details on the configured validator instances MIMEsweeper uses are found in the [Validation] configuration section. For MAILsweeper this section is found in the validation configuration file, VALIDATE.CFG. For WEBsweeper this section is found in the http and ftp configuration files, HTTP.CFG and FTP.CFG.

AMUcheck uses its own configuration section, called [AMU]. See page 7-100 for details.

[Validation] section

The[Validation]configuration section defines instances of the plug-in validators.

There is a directive listed in this section for each configured validator instance. The name of the directive is the name of the instance and the value is the name of the dynamic link library (.DLL).

For example:

[Validation]
FPROT=VALEXE
AVTOOL=VALEXE
HTML=VALHTML
Confidential=VALLEX
DetectExecutable=VALATTR
ValidateAttributes=VALATTR
Validator instances are executed in the order that they are listed in the [Validation] section. It is important to take this into account when adding a new instance, as it may set an attribute that another instance may subsequently need to use.

Each defined instance must have its own configuration section in the same file as the [Validation]configuration section. The name of the section must be the same as the name of the validator instance.

For example:

[AVTOOL]
ExeName=C:\MSW\PROGRAM\AVTOOL.EXE
CmdLine=%s
FilePos=0
0=Success
1=VirusFound
7=ScanFailed

Each validator uses its own set of directives. There is also a small set of directives that are common to all validators. See the Common validator directives section on page 7-102 for more details.

VALEXE

The plug-in validator, VALEXE, provides a link to a standalone application, such as an anti-virus tool, to perform the validation task. This facilitates the inclusion of third party applications into the MIMEsweeper framework.

VALEXE writes the data being validated to a temporary file. It then runs the standalone application, providing it with the necessary command line arguments, as specified by one of the VALEXE directives.

The return code from the application is mapped to a <Response>, using the information in the configuration section for the VALEXE validator instance.

Instances of VALEXE are defined in the [Validation] configuration section. Each instance must have its own configuration section in the same file as the [Validation] section. The name of the configuration section must be the same as the name of the validator instance.

For example:

[Validation]
FPROT=VALEXE
ValidateAttributes=VALATTR

[FPROT]
ExeName=C:\F-PROT\F-PROT.EXE
ApplicationType=DOS
WorkDir=C:\MSW\TEMP\
CmdLine=%s /ALL /NOBOOT /NOMEM /PACKED /REPORT=%s 
/SILENT
FilePos=0
LogPos=1
0=SUCCESS
1=SCANFAILED
2=SCANFAILED
3=VIRUSPRESENT
4=VIRUSPRESENT
5=SCANFAILED
6=VIRUSPRESENT
7=SCANFAILED
8=VIRUSPRESENT
...
255=UNKNOWN

VALEXE uses several directives to control execution of the application and generate a <Response> from the return code. These are:

The ExeName directive specifies the path to the application executable.

For example:

ExeName=C:\F-PROT\F-PROT.EXE

In this example the application executable is F-PROT.EXE.

The ApplicationType directive specifies whether the executable named by the ExeName directive is a 16 bit DOS application or a 32 bit Windows 95 or Windows NT application. It can have the values DOS or WIN32 respectively.

For example:

ApplicationType=DOS

The default value is WIN32. For performance reasons it is recommended that you use 32 bit virus scanners.

It is important to ensure that the ApplicationType directive specifies the correct value for the executable named by the ExeName directive.

The WorkDir directive specifies the path to a working directory where the temporary file that is passed to the application is created. This directive is usually used when the application validates all files in a given directory as opposed to a given file.

For example:

WorkDir=C:\MSW\TEMP\

The CmdLine directive specifies the text string that is used as the command line when the application is executed.

For example:

CmdLine=%s /ALL /NOBOOT /NOMEM /PACKED /REPORT=%s 
/SILENT

(this directive should appear on one line).

The text string can be parameterised with one or more %s tokens. These tokens are used to indicate where substitute parameters, such as filenames and attribute values are to be placed. The %s tokens in the text string are numbered from left to right, starting at 0.

The information replacing each %s token is determined by one of the `argument position' directives.

The value of the argument position directive indicates which token on the command line it will replace.

For example:

FilePos=0

will replace the first %s token on the command line.

LogPos=1

will replace the second %s token on the command line.

Argument position directives

There are several argument position directives that can be used in conjunction with the CmdLine directive. These directives are used to determine the information replacing each %s token on the command line text string.

The FilePos directive specifies the position of the %s token that is to be replaced with the name of the file being validated.

For example:

FilePos=0

The LogPos directive specifies the position of the %s token that is to be replaced with the name of the logfile generated by the application.

For example:

LogPos=1

The WorkDirPos directive specifies the position of the %s token that is to be replaced with the value of the WorkDir directive.

For example:

WorkDirPos=2

The SubjectPos directive specifies the position of the %s token that is to be replaced with the subject text of the message being processed.

For example:

SubjectPos=3

The ContainerNamePos directive specifies the position of the %s token that is to be replaced with the value of the ContainerName attribute attached to the component being validated.

For example:

ContainerNamePos=4

The ContentTitlePos directive specifies the position of the %s token that is to be replaced with the value of the ContentTitle attribute attached to the component being validated.

For example:

ContentTitlePos=5

The ContentPathPos directive specifies the position of the %s token that is to be replaced with the value of the ContentPath attribute attached to the component being validated.

For example:

ContentPathPos=6

It is important to ensure that each %s token on the command line text string has a corresponding argument position directive specified in the configuration section.

The remaining directives in the configuration section for the validator instance map the return codes of the application to <Response> values.

The name of the directive is the return code of the application and the value is the <Response>.

For example:

[FPROT]
ExeName=C:\F-PROT\F-PROT.EXE
...
0=SUCCESS
1=SCANFAILED
2=SCANFAILED
3=VIRUSPRESENT
4=VIRUSPRESENT
5=SCANFAILED
6=VIRUSPRESENT
7=SCANFAILED
8=VIRUSPRESENT
...
255=UNKNOWN

Each <Response> defined in this way must have a corresponding entry in the [Disposal]configuration section.

For example:

[Disposal]
DefaultDisposal=Clean
...
SUCCESS=Clean
...
SCANFAILED=Failure
...
VIRUSPRESENT=Virus
...
LOADFAILURE-FailedLoad

If the <Response> does not have an entry, such as UNKNOWN in this example, then the <Response> used is DefaultDisposal.



VALATTR

The validate attributes validator, VALATTR, is used for attribute analysis, usually to determine the data type of a component. It performs validation by checking the value of attributes attached to each component generated during recursive disassembly. VALATTR is also used to check the PICS rating of Web pages. See page 5-55 for more details.

Instances of the VALATTR validator are defined in the [Validation] section. Each instance must have its own configuration section in the same file as the [Validation] section. The name of the configuration section must be the same as the name of the validator instance.

For example:

[Validation]
ValidateAttributes=VALATTR

[ValidateAttributes]
UNKNOWN=ContainerName==Binary
BADDATA=BadData==*
ENCRYPTED=Encryption==*
CDACMD=CDAPackageType==Command
For example:

[Validation]
PICS=VALATTR

[PICS]
;NoRating=WSW_LABEL==FALSE
HaveOther=WSW_AGE>2
HaveAge=WSW_SEX>2
HaveLanguage=WSW_LANGUAGE>2
HaveViolence=WSW_VIOLENCE>2
HaveSex=WSW_OTHER>2
VALATTR instances often makes use of attributes set by other validator instances. For this reason it is usual to place the VALATTR instances at the end of the [Validation] configuration section.

Each VALATTR configuration section lists a number of directives. The name of the directive is a <Response> and the value is an attribute expression.

For example:

[ValidateAttributes]
UNKNOWN=ContainerName==Binary 

This directive has:

For example:
[PICS]
...
HaveAge=WSW_AGE>2

This directive has:

If the value of the attribute expression is a string then it must always be enclosed in double quotes.

For example:

[ValidateAttributes]
...
BADUUEDATA=BadData=="Insufficient data in 
UUEencoding"

(this will appear all on one line)

If this example is written without the quotes then the test is equivalent to:

BADUUEDATA=BadData==Insufficient

The <Response> generated by the VALATTR instance corresponds to the last directive listed in the configuration section whose attribute expression evaluates to TRUE.

For example:

Using the configuration example on page 7-81:

For example:

Using the configuration example on page 7-81:

Each <Response> defined by the VALATTR instance must have an entry in the [Disposal] configuration section. These entries control the disposal actions taken.

For example:

[Disposal]
DEFAULTDISPOSAL=Clean
...
ENCRYPTED=Encrypted
BADDATA=Bad
...
CDACMD=CDACommand
...
LOADFAILURE=FailedLoad
For example:
[Disposal]
DefaultDisposal=Clean
...
NoRating=BlockNoRating
HaveOther=BlockOther
HaveAge=BlockAge
HaveLanguage=BlockLanguage
HaveViolence=BlockViolence
HaveSex=BlockSex
...
VIRUSPRESENT=Virus

If the <Response> does not have an entry, such as UNKNOWN in the MAILsweeper example on page 7-81, or it is the empty string, then the <Response> used is DefaultDisposal.

Some attributes that can be used by configured VALATTR instances are shown on the next page. For a more detailed list see Appendix B.

Some attributes that can be used by configured VALATTR instances are:

TO1 SENTCC1 CC1
BCC1 SENTBCC1 SENTTO1
FROM1 ContentTitle ContentPath
ContainerName* BadData Encryption
CDAStructured Storage CDAClassId CDAPackageType
CDAClassAppName ContainerClass WSW_AGE2
WSW_LABEL2 WSW_LANGUAGE2 WSW_SEX2
WSW_VIOLENCE2 HttpMethod UniqueId

1 The value of this attribute indicates an address and uses the generic MIMEsweeper address format user@location.

2 This attribute name is defined in the file PICSMAP.CFG.

*Valid ContainerName values are:

Win32Unknown Win32Exe Win32Dll
Win31 DosExe SfxZipArchive
MIME_Text MIME_Multipart MIME_Message
MIME_Image MIME_Application MIME_Audio
MIME_Video Cabinet Package
TIFF JPEG BMP
GIF LoggingStream UUE
 
The names of some of the container handlers defined in the [Packaging] configuration section can also be used as valid ContainerNames values, see page 7-57.

VALLEX

The plug-in validator, VALLEX, performs validation by searching data components for occurrences of user-defined expressions. This process is known as lexical analysis.

By default, VALLEX scans the mail body and attachments, but not the subject line. VALLEX instances can be configured to scan just the subject line if required. See page 7-89 for details.

Typically, lexical analysis can be used to search a message or Web page for occurrences of expressions that:

Each user-defined expression is listed in a special file, known as an ExpressionList file. The expression can be a single word or it can be a phrase, consisting of up to a maximum of 20 words. It can also contain one or more wildcard characters. These wildcard characters match with certain characters during the search and are used to make the search more general.

The expression is listed with a numeric value, indicating its considered importance in the search. Whenever the expression is encountered in the data being validated, it's numeric value is added to a running total, representing a score for the expressions found in the data so far.

When validation is complete, the final score2 obtained is checked against a list of numeric values, listed in the VALLEX configuration section, to determine the <Response> that is generated as a result of the analysis.

The ExpressionList file holds the majority of configuration information VALLEX needs to perform lexical analysis. For more details on this file and how VALLEX performs lexical analysis see page 7-133.

Instances of VALLEX are defined in the [Validation] configuration section. Each instance must have its own configuration section in the same file as the [Validation] section. The name of the configuration section must be the same as the name of the validator instance.

For example:

[Validation]
FPROT=VALEXE
Confidential=VALLEX
ValidateAttributes=VALATTR

[Confidential]
ExpressionList=C:\MSW\CONFIG\CONFID.LST
20=ConfidentialModerate
50=Confidential

VALLEX uses two types of directive to perform lexical analysis.

The ExpressionList directive specifies the path to the ExpressionList file. In the above example the ExpressionList file is called CONFID.LST.

The second directive maps numeric values that may be obtained as a result of the search to <Response> values. There can be any number of these directives listed in the configuration section.

The name of the directive is a numeric value and its value the <Response>.

For example:

[Confidential]
...
20=ConfidentialModerate
50=Confidential 

This directive has:

The directive providing the <Response> is the largest one whose numeric value is equalled or exceeded by the final score obtained for the analysis.

Using the example on the previous page:

See the section on the ExpressionList file, page 7-133, for more details on how the final lexical analysis score is obtained.

Each <Response> used by the VALLEX instance must have a corresponding entry in the [Disposal] configuration section. These entries control the disposal actions taken.

For example:

[Disposal]
DEFAULTDISPOSAL=Clean
...
ConfidentialModerate=Clean
...
Confidential=BlockConfidential
...
LOADFAILURE=FailedLoad
If the <Response> does not have a corresponding entry in the [Disposal] section, or it is the empty string, then the <Response> used is DefaultDisposal.

Validating the message subject line

If required, VALLEX instances can be configured to validate the message subject line only.

This is achieved by adding the ValSubject directive to the configured VALLEX instance, with a value of TRUE.

For example:

[Confidential]
ValSubject=TRUE
ExpressionList=C:\MSW\CONFIG\CONFID.LST
20=ConfidentialModerate
50=Confidential

This particular VALLEX instance will ignore the message contents and validate the message subject line only, according to the configured rules.

VALHTML

The HTML validator, VALHTML, validates Web pages and HTML in mail messages by searching for threats that can arise from the use of scripts, automatic mailings and Internet Shortcuts.

The <Response> is automatically generated, depending on the results of the validation. It is built up, in alphabetical order, from the words Mail, Script and Shortcut, depending on the threats found.

The possible <Response> strings that may be generated are shown on the following table:

Response Threat
Mail Script Shortcut
Mail
X
Script
X
Shortcut
X
MailScript
X X
MailShortcut
X X
ScriptShortcut
X X
MailScriptShortcut
X X X

MIMEsweeper can also be configured to detect and block Java applets. See page 5-52 for details.

Each <Response> string combination that may be generated must have a corresponding entry in the [Disposal]configuration section.

The [Disposal]section can be found in the mail configuration file, MIMESWP.CFG, for MAILsweeper, or the http and ftp configuration files, HTTP.CFG and FTP.CFG, for WEBsweeper.

For example:

[Disposal]
DefaultDisposal=Clean
...
;Script=BlockScript
MailScript=BlockMailScript
Mail=BlockMail
ScriptShortcut=BlockScriptShortcut
MailScriptShortcut=BlockMailScriptShortcut
MailShortcut=BlockMailShortcut
Shortcut=BlockShortcut
...
VIRUSPRESENT=Virus

The default MIMEsweeper configuration blocks automatic mailings and Internet shortcuts. It does not block scripts.

If you wish to block scripts then edit the [Disposal] section to ensure that the Script directive is no longer commented out.

That is, change:

[Disposal]
...
;Script=BlockScript

to

[Disposal]
...
Script=BlockScript

Instances of the VALHTML validator are defined in the [Validation] configuration section. Each instance must have its own configuration section in the same file as the [Validation] section. The name of the configuration section must be the same as the name of the validator instance.

For example:

[Validation]
FPROT=VALEXE
Confidential=VALLEX
HTML=VALHTML
PICS=VALATTR

[HTML]
PerformIf=ContainerClass==Text
PicsMap=c:\MSW\CONFIG\PICSMAP.CFG

In contrast to the other plug-in validator instances, the configuration section does not list any <Response> values. This is because the <Response> is automatically generated by the VALHTML validator, as explained on page 7-90.

All HTML is detected as plain text. For this reason a PerformIf directive is included in the configuration section, to ensure that only plain text is validated, thus saving on processing time. For more details on the PerformIf directive see page 7-107.

PICS ratings

The VALHTML validator is also responsible for checking the PICS ratings of the HTML page and setting one or more attributes, based on the ratings found. These attributes can be used to detect pages with unsuitable content or confidential information, see page 5-55 for more details.

Due to the difficulty of having to configure multiple PICS rating schemes, MIMEsweeper maps the PICS ratings into a single MIMEsweeper rating scheme. See Appendix A for more details on this rating scheme.

The VALHTML validator stores the category and value of each mapped rating as an attribute.

For example:

WSW_AGE,3
WSW_LANGUAGE,3
WSW_OTHER,1
If a rating has been supplied by more than one PICS rating scheme, for example, both SafeSurf and RSACI then the value of the highest mapped rating is stored.

The stored attributes can subsequently be validated by a configured VALATTR instance. This instance can be used to block any HTML page with a PICS rating that maps to a value greater than a specified limit.

For example:

[Validation]
PICS=VALATTR

[PICS]
;NoRating=WSW_LABEL==FALSE
HaveOther=WSW_OTHER>2
HaveAge=WSW_AGE>2
HaveLanguage=WSW_LANGUAGE>2
HaveViolence=WSW_VIOLENCE>2
HaveSex=WSW_Sex>2
If no rating is found in the HTML page, or no mapping exists for a rating, VALHTML will set the attribute WSW_LABEL to FALSE. The value of this attribute can be checked like all other values. By default, this functionality is disabled.

The value of each category listed in the configuration section is checked against the mapped rating(s) that have been stored by the VALHTML validator. An appropriate <Response> is then generated, according to the VALATTR validator rules. See page 7-81 for more details.

Using the example on the previous page, assume that the VALHTML validator instance provides the following three attributes, WSW_AGE,3, WSW_LANGUAGE,3 and WSW_OTHER,1.

According to the VALATTR rules, the <Response> generated corresponds to the last directive listed in the configuration section whose attribute expression evaluates to TRUE. In this example, it is WSW_LANGUAGE>2. The <Response> generated will therefore be HaveLanguage.

If no attribute expression evaluates to TRUE the page is considered safe for download and <Response> generated is the empty string. This equates to the <Response> DefaultDisposal.

Each <Response> defined by the VALATTR instance must have an entry in the [Disposal] configuration section.

For example:

[Disposal]
DefaultDisposal=Clean
...
NoRating=BlockNoRating
HaveOther=BlockOther
HaveAge=BlockAge
HaveLanguage=BlockLanguage
HaveViolence=BlockViolence
HaveSex=BlockSex
...
VIRUSPRESENT=Virus

If the <Response> does not have an entry in the [Disposal] section, such as NoRating in this example, or it is the empty string, then the <Response> used is DefaultDisposal.

See Appendix A for a description of the PICS rating scheme. Also a full list of PICS categories and values contained in the file PICSMAP.CFG.

AUTWNT

The authenticode validator, AUTWNT, looks for the presence of digital signatures on the data being downloaded. It checks the signature against the data that it supposedly signs, to determine if it is valid, and returns one of the following <Response> values:

Instances of AUTWNT are defined in the [Validation] configuration section. This section is found in the http and ftp configuration files, HTTP.CFG and FTP.CFG.

Each instance must have its own configuration section in the same file as the [Validation] section. The name of the configuration section must be the same as the name of the validator instance.

For example:

[Validation]
Authenticode=AUTWNT

[Authenticode]
0=Success
...
720900=NotTrusted
...
721152=NoCertificate
721153=CertificateExpired
721154=CertificateExpired
...
721161=NotTrusted
...
614435=NoCertificate

Each <Response> must have a corresponding entry in the [Disposal] configuration section. These entries control the disposal actions taken.

For example:

[Disposal]
DefaultDisposal=Clean
Success=Clean
...
ScanFailed=NotSure
...
;NoCertificate=BlockedNoCertificate
CertificateExpired=BlockCertificateExpired
NotTrusted=BlockNotTrusted
VIRUSPRESENT=VIRUS

AMUcheck

The built-in validator, AMUcheck, performs validation by comparing the source and destination addresses of a message against a set of access rules. These rules specify different FROM and TO address combinations that may match with the source and destination addresses of the message.

All addresses specified in the AMUcheck rules use the generic address format, user@location. This is regardless of the underlying mail system. See page 7-5 for details.

Each rule has one or more associated <Response> values. AMUcheck may generate one of these <Response> values as a result of the validation, when a rule match is found. A <Response> can have an optional priority assigned to it. This priority is used to determine which <Response> is used when the address has more than one recipient and each recipient address matches a different rule. See page 7-99 for more details.

The format of an AMUcheck rule is:

FROM  user@location
   TO user@location <Response>

(the rule can appear all on one line).

Any part of the user and location elements of the rule can be substituted with the wildcard character (*).

For example:

FROM *@location 
   TO *@location.* <Response>

This wildcard character matches anything and is used to make the rule matches more general.

Another example is:

FROM *@* 
   TO *@* <Response>

This rule will match with any address.

The FROM and TO parts of the rule can each have multiple entries.

For example:

FROM 	user@location
	user@location
   TO *@location <Response>
	*@location.* <Response>

The message can match with any combination of these entries.

If the TO part of the rule has multiple entries each entry must have its own <Response>. This applies even if all entries use the same <Response>.

As each message is processed, the source and destination addresses are compared against all of the AMUcheck rules. If a rule match is found then this rule provides the <Response> AMUcheck will generate as a result of the validation. If no rule match is found, AMUcheck generates the <Response> NoRule.

AMUcheck generates the <Response> NoFrom for any message that doesn't have a source address. By default this is mapped to the Clean disposition in the [Disposal] configuration section but this can be altered if required.

More than one matching rule may be found. In this case, the rule with the highest priority provides the <Response>. Priorities are determined according to the number and location of wildcards found in the rule. Generally speaking, the rule with the fewest address elements containing wildcard characters is considered to have the highest priority.

For example:

FROM user@location 
  TO user@location.* <Response>

has a higher priority than

FROM *@* 
   TO *@location.* <Response>

So, in the above example, the first rule will provide the <Response>.

It doesn't matter if a wildcard is used to represent the whole of the address element, or just part of the address element. Furthermore, it doesn't matter if more than one wildcard appears in the address element. For example, user@*, user@location.* and user@location.*.* will all be treated equally, for the purpose of calculating priorities.

If a message is destined for more than one recipient then each recipient address is compared with the rules in its own right. This means the message is effectively checked several times, that is, once for every source and destination address combination the message has.

For example:

A message sent from mary@sales to fred@sales and joe@sales will be compared against the rules twice:

Every comparison against the AMUcheck rules is made in the usual way, that is, by finding all the matching rules and using the number of wildcards to determine the highest priority rule when more than one match is found.

As a result, each address combination will have its own highest priority rule and these rules may differ. In this situation, the priority assigned to each rule <Response> is taken into account and the <Response> with the highest priority is used. If more than one <Response> shares the highest priority then the number of wildcards in each associated rule is used to decided which <Response> is used.

AMUcheck rules and associated <Responses> are defined in a file known as an authorisation file. This file is normally called AUTHFILE.TXT. For more details on this file, and how AMUcheck performs validation, see page 7-119.

There are some example authorisation files provided for each of the mail systems. These can be found in the EXAMPLES directory of the MAILsweeper installation.

[AMU] section

AMUcheck has its own configuration section. This section is found in the same file as the [Validation] configuration section, usually the validator configuration file, VALIDATE.CFG.

For example:

[AMU]
AuthFile=C:\MSW\CONFIG\AUTHFILE.TXT

The configuration section for AMUcheck must always be called[AMU].

If the [AMU] section is present in VALIDATE.CFG, and is not commented out, then AMUcheck is enabled. If there is no [AMU] section present, or it is commented out, then AMUcheck is disabled.

The [AMU] section must always list at least one directive, this is the AuthFile directive which specifies the path to the authorisation file. In the above example the authorisation file is called AUTHFILE.TXT.

The [AMU] configuration section may also list one or more If directives.

For example:

[AMU]
AuthFile=C:\MSW\CONFIG\AUTHFILE.TXT
If=allow_in,direction=in,allow
If=allow_out,direction=out,allow

The If directive is usually used to set attributes that can be used by other validator instances, or during disposal. In this example, it is used to set an attribute called direction with the value in or out and resets the <Response> to allow for processing during disposal. The direction attribute can be used during subsequent processing to give the message some sense of direction. For example, during lexical analysis validation (see page 7-133) or as a part of automated message editing (see page 7-34).

See page 7-102 for more details on the If directive.

For more details on the authorisation file and how AMUcheck performs validation, see page 7-119.

Cookies

WEBsweeper can be configured to deal with cookies in one of the following ways:

Configuration details are found in the http configuration file, HTTP.CFG. The default WEBsweeper installation is configured to ignore cookies.

That is:

[HTTP]
Cookies=Ignore
;Cookies=Remove
;Cookies=Block,Blocked because of associated 
cookie

The directives required to perform the other options are listed in the configuration section as comments.

The common validator directives, If, SkipIf and PerformIf cannot be used in the [HTTP] configuration section.

For more details on cookie configuration see page 5-62.

Common validator directives

There are three directives that can be used by all validator instances, these are:

The SkipIf and PerformIf directives can also be used within Inform configuration sections, during MAILsweeper disposal. See page 7-33 for details.

If

The If directive is used to set an attribute on the message or Web data, based on the <Response> generated by a plug-in validator instance or, in the case of MAILsweeper, AMUcheck. This <Response> can optionally be reset to a different value.

The format is:

If=<Response>,<Attribute_Assignment>[,<Response>]

[Brackets indicate that this value is optional]

The If directive is usually used to set attributes that can be used by other validator instances, or during disposal. This technique allows you to combine validator results and control the flow of the validation and disposal phases. There can be more than one If directive listed

An attribute could be set by:

For example:
[AMU]
Authfile=C:\MSW\CONFIG\AUTHFILE.TXT
If=allow_in,direction=in,allow
If=allow_out,direction=out,allow

In this example:

In both cases, the actual <Response> AMUcheck generates is allow. It allows the message to be delivered normally, assuming no higher priority <Response> is generated by one of the plug-in validator instances.

The direction attribute can then be checked during subsequent processing, to determine the direction of the message.

Another example is:

[DrSolomons]
SkipIf=VIRUS==FOUND
ExeName=C:\MSW\DRSOL\FINDVIRU.EXE
CmdLine=%s /DOALLFILES /NOBOOT /NOPART /SILENT /
...
2=VIRUSPRESENT
255=SCANFAILED
If=VIRUSPRESENT,VIRUS=FOUND

In this example, if the <Response> generated by the validator instance is VIRUSPRESENT3 then an attribute called VIRUS is created, with the value FOUND. The value of the <Response> remains unchanged.

Using the SkipIf directive, the value of the VIRUS attribute can subsequently be checked by other validator instances that perform virus scanning.

For example:

[F-PROT]
SkipIf=VIRUS==FOUND
ExeName=C:\MSW\F-PROT\F-PROT.EXE
...
0=SUCCESS
1=SCANFAILED
...
If=VIRUSPRESENT,VIRUS=FOUND

If the value of the VIRUS attribute is FOUND this indicates that a virus has already been detected by another validator instance. Validation by this validator instance can therefore be skipped, thus saving on processing time.

For plug-in validator instances, if the attribute name is one of the following the attribute is set on the message component rather than the message itself.

ContainerName
ContainerClass
ContainerTitle
ContentPath
AttachmentSize

SkipIf

The SkipIf directive is used to conditionally skip validation by a validator instance.

It can also be used within Infom sections, during MAILsweeper disposal. See page 7-33 for details.

For example, if a virus has already been found in the message or Web data it may make sense to skip searching for any more viruses, thus saving on processing time.

The format is:

SkipIf=<Attribute_Expression>

If the attribute expression evaluates to TRUE then validation is skipped.

For example:

[DrSolomons]
SkipIf=VIRUS==FOUND
ExeName=C:\MSW\DRSOL\FINDVIRU.EXE
CmdLine=%s /DOALLFILES /NOBOOT /NOPART /SILENT /
REPORT=%s
WorkDir=C:\MSW\DRSOLWRK\
WorkDirPos=0
LogPos=1
0=SUCCESS
1=SCANFAILED
2=VIRUSPRESENT
255=SCANFAILED
If=VIRUSPRESENT,VIRUS=FOUND

In this example, if the value of the VIRUS attribute is FOUND then validation by this validator instance is skipped.4

If there are no SkipIf directives listed in the configuration section then validation by the validator instance is never skipped.5

There can be more than one SkipIf directive listed. If there is then, if any one of the attribute expressions evaluate to TRUE, validation is skipped by the validator instance.

For example:

[Confidential]
SkipIf=ContainerClass==Container
SkipIf=ContainerClass==Image
SkipIf=ContainerClass==Executable
SkipIf=ContainerClass==Binary
ExpressionList=c:\MSW\CONFIG\CONFID.LST
20=ConfidentialModerate
50=Confidential

This example will skip validation if the value of the ContainerClass attribute is Container, Image, Executable or Binary.

For more details on the ContainerClass directive see page 7-59.

The SkipIf directive cannot be used with the built-in validator AMUcheck.

A validator instance cannot be configured with a SkipIf and a PerformIf directive at the same time.



PerformIf

The PerformIf directive is used to conditionally perform validation by a validator instance.

It can also be used within Infom sections, during MAILsweeper disposal. See page 7-33 for details.

For example, if a validator instance only checks certain types of data, it makes sense to limit validation to those data types. This could apply to VALLEX validator instances for example, which you may only want to perform validation on components holding plain text.

The format is:

PerformIf=<Attribute_Expression>

If the attribute expression evaluates to TRUE then validation is performed. If it evaluates to FALSE then validation is not performed.

For example:

[Confidential]
PerformIf=ContainerName==PlainText
ExpressionList=c:\MSW\CONFIG\CONFID.LST
10=ConfidentialModerate
100=Confidential

In this example, validation will only be performed if the value of the ContainerName attribute is PlainText.

For a full list of ContainerName attribute values that can be checked using PerformIf see page 7-85.

If there are no PerformIf directives listed in the configuration section then validation by the validator instance is always performed.6

There can be more than one PerformIf directive listed in a configuration section. If there is then if any one of the attribute expressions evaluate to TRUE, validation is performed by the validator instance.

For example:

[Confidential]
PerformIf=ContainerClass==Text
PerformIf=ContainerClass==Document
ExpressionList=c:\MSW\CONFIG\CONFID.TXT
20=ConfidentialModerate
50=Confidential

In this example, validation will only be performed if the value of the ContainerClass attribute is Text or Document.

Another example is:

[DrSolomons]
PerformIf=ContainerClass==Executable
PerformIf=ContainerClass==Document
PerformIf=ContainerClass==Text
PerformIf=ContainerClass==Binary
ExeName=C:\MSW\DRSOL\FINDVIRU.EXE
CmdLine=%s /DOALLFILES /NOBOOT /NOPART /SILENT /
REPORT=%s
...
255=SCANFAILED

This example will perform validation if the ContainerClass attribute has the value Executable, Document, Text or Binary.

For more details on the ContainerClass attribute see page 7-59.

The PerformIf directive cannot be used with the built-in validator AMUcheck.

A validator instance cannot be configured with a SkipIf and a PerformIf directive at the same time.



[Top] [Prev] [Next] [Bottom]



1 Priorities are determined by the ordering of disposal entries in the [Disposal] section, see page 7-22 for details.

2 A loading value may also be applied, usually to indicate the direction of the message. If it is, this value is multiplied to the final score.

3 The VIRUSPRESENT <Response> is used to indicate that a virus has been detected in the message or Web data.

4 The VIRUS attribute will have been previously set using the If directive. See page 7-102 for details.

5 An exception may be when a PerformIf directive is listed, to control when validation is performed. See page 7-107.

6 An exception may be when a SkipIf directive is listed, to control when validation is skipped. See page 7-105.

msw.support@mimesweeper.com

Copyright © 1998, Content Technologies Limited. All rights reserved.