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:
VALEXE
- provides a link
to third party applications, such as anti-virus tools.
MIMEsweeper supports a range of anti-virus tools. For
more details see page
7-75. VALATTR
- validate
attributes validator. Used for attribute analysis,
usually to determine the data type of a component. For
more details see page
7-81. VALLEX
- lexical analysis
validator. Used to search the data content for keywords
or phrases. For more details see page 7-86. VALHTML
- HTML validator.
Used to locate threats in Web pages and
mail messages in HTML format, or with HTML format
attachments. For more details see page 7-90. AUTWNT
- Authenticode
validator. Used to authenticate the signature of
digitally signed information. For
more details see page
7-95. ![]() |
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. |
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).
[Validation] FPROT=VALEXEAVTOOL=VALEXE
HTML=VALHTML
Confidential=VALLEX DetectExecutable=VALATTR ValidateAttributes=VALATTR
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.
[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
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.
[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
ExeName
ApplicationType
WorkDir
CmdLine
CmdLine
directive. See page
7-78 for details. The ExeName
directive specifies the path to the application executable.
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.
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.
WorkDir=C:\MSW\TEMP\
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.
FilePos=0
will replace the first %s token on the command line.
LogPos=1
will replace the second %s token on the command line.
The FilePos
directive specifies the position of the %s token that is to be
replaced with the name of the file being validated.
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.
LogPos=1
The WorkDirPos
directive specifies the position of the %s token that is to be
replaced with the value of the WorkDir
directive.
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.
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.
ContainerNamePos=4
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.
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 name of the directive is the return code of the application and the value is the <Response>.
[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
[Disposal] DefaultDisposal=Clean ...SUCCESS=Clean
...SCANFAILED=Failure
...VIRUSPRESENT=Virus
... LOADFAILURE-FailedLoad
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. |
For example: | ![]() |
[ValidateAttributes]
UNKNOWN=ContainerName==Binary
For example: | ![]() |
[PICS]
...
HaveAge=WSW_AGE>2
If the value of the attribute expression is a string then it must always be enclosed in double quotes.
[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
For example: | ![]() |
Using the configuration example on page 7-81:
ContainerName
with the value Binary
and there is no
attribute called BadData
, Encryption
or CDAPackageType
, the <Response>
generated will be UNKNOWN
. Encryption
with any value (*) an attribute called ContainerName
with the value Binary
and there is no
attribute called BadData
or CDAPackageType
,
the <Response> generated will be ENCRYPTED
. CDAPackageType
with the value Command
, the <Response>
generated will be CDACMD
, regardless of any
other attribute value.For example: | ![]() |
Using the configuration example on page 7-81:
WSW_AGE
with a value of greater than 2 and no other attribute
that evaluates to True
, the <Response>
generated will be HaveAge
. WSW_LANGUAGE
with a value of greater than 2, an attribute called WSW_VIOLENCE
with a value of 1 and no other attribute that evaluates
to True
, the <Response>
generated will be HaveLanguage
. WSW_Sex
with a value of greater than 2, the <Response>
generated will be HaveSex
, regardless of any
other attribute value.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:
1 The value of this attribute indicates an address and uses the generic MIMEsweeper address format user@location. |
*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. |
![]() |
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.
[Validation] FPROT=VALEXEConfidential=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>.
[Confidential]
...
20=ConfidentialModerate
50=Confidential
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:
0
and 19
the <Response>
generated is the empty string. This equates to DefaultDisposal
.
20
and 49
the <Response>
generated is ConfidentialModerate
. 50
the <Response>
generated is Confidential
.![]() |
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.
[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 . |
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
.
[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.
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 | |||
Script | Shortcut | |||
|
X | |||
|
X | |||
Shortcut |
X | |||
|
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. |
![]() |
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. |
[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.
[Disposal]
...
;Script=BlockScript
[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.
[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.
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.
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.
[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
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.
[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. |
Success
- the data was
signed, the signature was valid and the publisher was
trusted. ScanFailed
- the data was
signed incorrectly. NoCertificate
- no
certificate was present. CertificateExpired
- the
certificate has expired. NotTrusted
- the data has
been tampered with or WEBsweeper has not been instructed
to trust the software publisher. 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.
[Validation]Authenticode=AUTWNT
[Authenticode] 0=Success
... 720900=NotTrusted... 721152=NoCertificate 721153=CertificateExpired 721154=CertificateExpired ... 721161=NotTrusted ... 614435=NoCertificate
[Disposal]
DefaultDisposal=Clean
Success=Clean
...
ScanFailed=NotSure
...
;NoCertificate=BlockedNoCertificate
CertificateExpired=BlockCertificateExpired
NotTrusted=BlockNotTrusted
VIRUSPRESENT=VIRUS
![]() |
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@locationTO
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 (*).
FROM
*@locationTO
*@location.* <Response>
This wildcard character matches anything and is used to make the rule matches more general.
FROM
*@*
TO
*@* <Response>
This rule will match with any address.
The FROM
and TO
parts of the rule can each have multiple entries.
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
.
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.
FROM
user@locationTO
user@location.* <Response>
FROM
*@*TO
*@location.* <Response>
So, in the above example, the first rule will provide the <Response>.
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.
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.
[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.
[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. |
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.
[HTTP] Cookies=Ignore ;Cookies=Remove ;Cookies=Block,Blocked because of associated cookie
![]() |
The common
validator directives, If , SkipIf
and PerformIf cannot be
used in the [HTTP] configuration section.
|
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=
<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
For example: | ![]() |
[AMU]
Authfile=C:\MSW\CONFIG\AUTHFILE.TXT
If=allow_in,direction=in,allow
If=allow_out,direction=out,allow
allow_in
, for
example, to indicate that the message is incoming, then
an attribute called direction
is set, with
the value in
. The <Response>
is then reset to allow
. allow_out
, for
example, to indicate that the message is outgoing, then
an attribute called direction
is set, with
the value out
. The <Response>
is then reset to allow
. The direction
attribute can then be checked during subsequent processing, to
determine the direction of the message.
[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 VIRUSPRESENT
3
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.
[F-PROT]
SkipIf=VIRUS==FOUND
ExeName=C:\MSW\F-PROT\F-PROT.EXE
...
0=SUCCESS
1=SCANFAILED
...
If=VIRUSPRESENT,VIRUS=FOUND
![]() |
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 |
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.
If the attribute expression evaluates to TRUE then validation is skipped.
[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.
[Confidential]
SkipIf=ContainerClass==Container
SkipIf=ContainerClass==Image
SkipIf=ContainerClass==Executable
SkipIf=ContainerClass==Binary
ExpressionList=c:\MSW\CONFIG\CONFID.LST
20=ConfidentialModerate
50=Confidential
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 |
![]() |
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.
PerformIf=
<Attribute_Expression>
If the attribute
expression evaluates to TRUE
then validation is
performed. If it evaluates to FALSE
then validation
is not performed.
[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
[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
.
[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
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 |
![]() |
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.
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.
Copyright © 1998, Content Technologies Limited. All rights reserved.