The authorisation file can be considered as split into sections:
FINISH
keyword is used
to terminate the file contents.![]() |
Comments can be included in the file. A comment is denoted by placing the semicolon character at the start of the comment. The comment is terminated at the end of the line.
; This is a comment taking up the whole line. FROM *@* TO *@* allow ; This comment is at the end of a line
![]() |
For an example authorisation file, see page 7-131. |
RESPONSE
<Response> [PRIORITY
<Priority>]
[Brackets indicate that this value is optional]
RESPONSE allow RESPONSE isjunkmail PRIORITY 2 RESPONSE copyadministrator PRIORITY 2 RESPONSE deny PRIORITY 3
![]() |
There is no limit to the number of <Response> values that can be defined, as long as they are all unique. |
The RESPONSE
statement may also be used to assign an optional priority value
to the <Response>. These priorities are used when
a message is destined for more than one recipient and each
recipient address matches a different rule which may, in turn,
have a different <Response>. See page 7-127 for more
details.
The priority value assigned to the <Response> should reflect its considered importance.
![]() |
The priority value should always be a positive integer. It is usual to list the values incrementally, in increasing order of importance, as shown in the example above. |
Each <Response> defined in
the authorisation file must have also have a corresponding entry
in the [Disposal]
section.1
This section is found in the mail configuration file, MIMESWP.CFG.
The ordering of <Response> values in the [Disposal]
section should match the ordering of <Response>
values in the RESPONSE
list.
For example, if the ordering of <Response> values in the authorisation file is as follows:
RESPONSE allow
RESPONSE isjunkmail PRIORITY 2
RESPONSE copyadministrator PRIORITY 2
RESPONSE deny PRIORITY 3
Then the ordering of entries in the [Disposal]
configuration section should be as follows:
[Disposal] DEFAULTDISPOSAL=Clean ...allow=Clean
NoFrom=Cleanisjunkmail=Warning copyadministrator=Warning
...deny=Block
... LOADFAILURE=FailedLoad
For example, assume
you want to add a new rule to the authorisation file and this
rule uses a new <Response>, called No_Exectables
.
The new <Response>
should be defined in the appropriate place in the list of RESPONSE
statements, depending on to its assigned priority.
RESPONSE allow
RESPONSE isjunkmail PRIORITY 2
RESPONSE copyadministrator PRIORITY 2
RESPONSE No_Executables PRIORITY 3
RESPONSE deny PRIORITY 4
The new <Response>
must also be added into the most appropriate position in the [Disposal]
section.
[Disposal]
DEFAULTDISPOSAL=Clean
...
allow=Clean
...
No_Executables=Block
deny=Block
...
LOADFAILURE=FailedLoad
![]() |
It is usual for the ordering of entries to be the same in both lists. |
The format of the AMUcheck rule:
FROM <Address>+ TO (<Address> <Response>)+
where + indicates the preceding item may be repeated.
The <Address> part of the rule is specified using the MAILsweeper generic address format user@location. This format is used regardless of the underlying mail system. See page 7-5 for more details.
The AMUcheck rules
are used to determine the <Response> generated as
a result of the validation, when the source and destination
addresses of the message match any of the FROM
and TO
address combinations specified.
FROM fred@sales
TO joe@sales deny
(The rule can appear all on one line)
This rule gives the <Response>
deny
if the source address of the message is fred@sales
and the destination address of the message is joe@sales.
The FROM
and TO
parts of the rule can each have multiple
entries. The message can match with any combination of these FROM
and TO
entries.
FROM fred@sales
mary@sales
TO joe@sales deny
sid@sales deny
This rule gives the <Response>
deny
if the source address of the message is fred@sales
or mary@sales and the destination address of the message
is joe@sales or sid@sales.
FROM fred@sales
TO joe@sales allow
sid@sales deny
allow
if the source address of the message is fred@sales
and the destination address of the message is joe@sales.
deny
if the source address of the message is fred@sales
and the destination address of the message is sid@sales.![]() |
If the TO part of the rule has multiple entries then each entry must have always have its own <Response>. This applies even if all entries use the same <Response>. |
Any part of the address elements specified in an AMUcheck rule may be substituted with the wildcard character (*). This character matches any value and is used to make the match more general.
FROM *@sales *@accounts TO *@location.* copyadministrator
This rule gives the <Response>
allow
for all messages.
![]() |
If no rule
match is found, AMUcheck generates the <Response>
NoRule . |
If a rule match is found then this rule provides the <Response> that AMUcheck will generate as a result of the validation.
For example, assume a message is sent from mary@sales to joe@sales and the authorisation file lists the following three rules:
FROM *@* TO *@* allow From fred@sales TO joe@sales deny mary@sales deny *@marketing deny
From *@sales TO *@marketing copyadministrator
Using this example,
the source and destination addresses will match the first rule,
but not the second or third, therefore the <Response>
generated for this message will be allow
.
More than one rule match may be found for the message. For example, assume a message is sent from fred@sales to joe@marketing. Using the same rules as shown above, the source and destination addresses will match all three rules. In this event rule priorities are used to determine which shall provide the <Response>. These priorities are based on the number and location of wildcard characters the rule contains and, in this example, the rule providing the <Response> will be the second one. See page 7-127 for more details on how AMUcheck rules are prioritised.
For example, a message sent from fred@sales to sid@sales and joe@marketing will be compared against the AMUcheck rules twice:
Comparison against the AMUcheck rules is made in the usual way for each source and destination address combination, that is, by finding rule matches and using rule priorities according to the number of wildcards the rule has, when more than one rule match is found. This determines the highest priority rule that will provide the <Response> for that particular address combination. See page 7-127 for more details on how AMUcheck priorities are determined.
As a result, each source and destination address combination will have its own highest priority rule and each rule may subsequently have a different <Response>. For example, using the rules listed on the previous page, the above addresses match with two different AMUcheck rules:
allow
. deny
.
At this point, a decision has to be made regarding which of these rules should provide the final <Response> for the message. This decision is made according to a second set of priorities, based on the priority value assigned to the <Response> when it is defined at the start of the authorisation file. See page 7-120 for more details.
![]() |
AMUcheck rules are prioritised in two ways, that is, according to:
![]() |
These rules still apply, even if the wildcard is specified as part of the address element, for example, user@location.*, user@location.*.* and user@* will all be treated equally. |
If a message has a source address of fred@sales and a destination address of joe@marketing then this message would match the following three rules.
FROM *@* TO *@* allow
FROM fred@sales TO joe@sales deny mary@sales deny *@marketing deny
FROM *@sales TO *@marketing copyadministrator
In this case, the rule with the highest overall priority is the one that will provide the <Response>. The overall priority for the rule is determined by the location and the number of wildcards it contains so, according to the table shown on the previous page:
Therefore, the <Response>
for this message is provided by the second rule,
that is, deny
.
![]() |
If the rule has multiple entries, as in the second rule shown above, only the matching entries are used to calculate the priority. The other entries are not taken into account. |
Another example is a message with the source address mary@sales and a destination address of joe@marketing. This message will match with the first and third rules so, according to the table shown on the previous page:
Therefore, the <Response>
for this message is provided by the third rule,
that is, copyadministrator
.
FROM *@* TO *@* allow
FROM *@* TO *@example.* deny
FROM *@*
TO *@*sales.* copyadministrator
For the purpose of
calculating priorities all of these combinations will be treated
equally and the above rules will all have the same priority, that
is, 1
.
Assume a message is sent from fred@sales to sid@sales and joe@marketing. Each source and destination address combination is compared against the AMUcheck rules 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.
Using the AMUcheck rules shown on the previous page and the priorities based on wildcard characters (shown on the table on page 7-127):
allow
(this address only matches the first rule). deny
(this address matches the second and third rules so,
according to the number of wildcards contained in each,
the second rule has the highest priority and provides the
<Response>).At this point a decision has to be made
regarding which of the two <Response> values
AMUcheck should generate for the message. The <Response>
provided will be the one that has the highest priority, as
determined by the value assigned to it using a RESPONSE
statement, at the top of the authorisation file. See page 7-120 for more details.
RESPONSE allow
2
RESPONSE isjunkmail PRIORITY 2 RESPONSE copyadministrator PRIORITY 2
According to this
list of RESPONSE
statements, deny
has a
higher priority than allow
, so, in this instance,
the <Response> generated for the message will be deny
and the next stage of processing should be to block the message.
This block applies to both recipients, regardless of the fact
that the first recipient (sid@sales) was entitled to
receive the message.
If the <Response> values have equal priority then the number of wildcards in each associated rule is then used to decide which <Response> is used. For example, assume each recipient matches a different rule, as follows:
FROM listserver@example.com TO *@* isjunkmail
FROM *@* TO *@sales copyadministrator
Using this example,
the two rules have equal <Response> priorities, so
the number and position of wildcards in each associated rule is
taken into account. The <Response> provided will
therefore be isjunkmail
.
By using <Response> priorities in this way, you can ensure that messages with multiple recipients are treated in the most appropriate way for your company requirements. For example, the previous example shows that, whilst one recipient was entitled to receive the message, another recipient was not, so the overall decision was to block the message. While this may be inconvenient for the legitimate recipient, a compromise has to be made between this inconvenience and your company access security needs.
![]() |
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. |
RESPONSE allow
RESPONSE allow_in PRIORITY 1
RESPONSE deny RETURNS 2
RESPONSE isjunkmail PRIORITY 3
FROM *@* TO *@* allow ; Allow everything FROM *@sales ; Deny everything from TO *@accounts deny ; sales to accounts and *@marketing deny ; marketing
FROM joe@sales ; but allow joe from sales
TO *@accounts allow ; to send to accounts
FROM fred@sales
TO *@* isjunkmail ; All fred's mail is junk
FROM *@* ; Add text to incoming TO *@sales allow_in ; mail for sales3
FINISH ; End of rules
[Disposal] DEFAULTDISPOSAL=Clean
... copyadministrator=Warning allow_in=EditIn...
deny=Blockisjunkmail=JustDelete
... LOADFAILURE=FailedLoad
Each <Response>
defined in the authorisation file has an entry in the [Disposal]
section. This entry maps the <Response> to a
disposition. Assuming isjunkmail
is the highest
priority <Response> returned after validation then
the final disposition for the message is JustDelete
.
The JustDelete
disposition has a configuration section in the same file as the [Disposal]
section.
[JustDelete]
This section controls the disposal actions for the message. In this case the configuration section has no directives so the message is deleted with no further action.
For more details on disposal actions see page 7-22.
[AMU]
AuthFile=C:\MSW\CONFIG\AUTHFILE.TXT
If=allow_in,direction=in,allow4
The [AMU]
configuration section specifies the path to the authorisation
file. See page 7-100
for more details.
1 An exception may be when the If
directive is used in the [AMU]
section to modify the
<Response> before it is passed to the [Disposal]
section. See page 7-102
for details.
2 allow
has no
priority assigned, therefore it is allocated a default priority
of 1
.
3 Achieved using automated message editing. See page 7-34.
4 The If
directive
can be used to modify the <Response> generated by
AMUcheck. See page 7-102
for details.
Copyright © 1998, Content Technologies Limited. All rights reserved.