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




Authorisation file


The built-in validator, AMUcheck, performs validation by comparing the source and destination addresses of the message against a set of access rules. These rules are defined in a special file, know as the authorisation file. This file is normally called AUTHFILE.TXT.

The location and name of the authorisation file are specified by a directive in the [AMU] section. This section is usually found in the validation configuration file, VALIDATE.CFG. See page 7-100 for more details.

The authorisation file can be considered as split into sections:

The ordering of these sections should not be changed.

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.

For example:

; 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.

Responses

The first section of the authorisation file defines the <Response> values that can be used by the AMUcheck rules. Each <Response> is defined using a RESPONSE statement.

The format is:

RESPONSE <Response> [PRIORITY <Priority>]

[Brackets indicate that this value is optional]

For example:

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=Clean
isjunkmail=Warning
copyadministrator=Warning
...
deny=Block
...
LOADFAILURE=FailedLoad

By following this rule you will ensure that the links between the priorities in the authorisation file and the priorities in the [Disposal] section always correspond correctly.

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

You may occasionally need to add a new <Response> to the authorisation file, for example, to use with a new rule. This <Response> should be added to both the list of RESPONSE statements and the [Disposal] section, according to its considered priority.

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.

For example:

In AUTHFILE.TXT:

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.

For example:

In MIMESWP.CFG:

[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.

Rules

AMUcheck rules are listed after the RESPONSE statements in the authorisation file. There can be any number of rules listed in the file.

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.

For example:

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.

For example:

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.

Another example is:

FROM fred@sales 
   TO joe@sales allow
      sid@sales deny

This rule gives:

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.

For example:

FROM *@sales
     *@accounts 
 TO  *@location.* copyadministrator

This rule gives the <Response> copyadministrator if the source address of the message is any user from sales or any user from accounts (*@sales or *@accounts) and the destination address of the message is any user at any the locations specified (*@location.*), for example, location.* could include location.co.uk, location.com, location.co.au, and so on.

Another example is:

FROM *@* TO *@* allow

This rule gives the <Response> allow for all messages.

If no rule match is found, AMUcheck generates the <Response> NoRule.

As each message is processed, the source and destination addresses are compared against all of the AMUcheck rules listed in the authorisation file.

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.

If a rule match cannot be found, AMUcheck generates the <Response> NoRule. Using the above example, a match will always be found as the first rule matches any address.

If a message does not have a source address AMUcheck generates the <Response> NoFrom.

A message may be addressed to more than one recipient. If it is then each recipient address is compared with the rules in its own right.

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:

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 priorities are discussed on the next few pages.

Priorities

AMUcheck rules are prioritised in two ways, that is, according to:

According to wildcard priority

Wildcard priorities are used when more than one rule match is found for the source and destination addresses of the message. In this case, the rule with the highest overall priority provides the <Response>. The number and position of wildcards contained in the rule elements determine the overall priority, according to the following table:

Priority FROM TO
9 (highest priority) user@location user@location
8 user@location *@location
7 user@location *@*
6 *@location user@location
5 *@location *@location
4 *@location *@*
3 *@* user@location
2 *@* *@location
1 (lowest priority) *@* *@*
 
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.

For example:

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.

It doesn't matter if the wildcard is used to represent the whole address element, or just part of the address element. Neither does it matter if the address element contains more than one wildcard.

For example:

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.

According to response priority

The optional priority value assigned to a <Response> becomes important when the message is destined for more than one recipient. For messages with multiple recipients, this priority is used to determine the <Response> that will be generated when each recipient address matches a different rule.

For example:

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):

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.

For example:

RESPONSE allow2 
RESPONSE isjunkmail PRIORITY 2
RESPONSE copyadministrator PRIORITY 2

RESPONSE deny PRIORITY 3

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.

AMUcheck example

The following example shows how the authorisation file would typically be structured. The example follows the path taken by a message sent from fred in the sales department (fred@sales) to any destination address (*@*). All fred's mail is deemed to be junk and is deleted with no further action.

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.

In AUTHFILE.TXT:

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

If the message has a source address of fred@sales and any destination address (*@*) then the <Response> returned by AMUcheck for this message is isjunkmail. Each <Response> is defined by a statement at the top of the file.

In MIMESWP.CFG:

[Disposal]
DEFAULTDISPOSAL=Clean
...
copyadministrator=Warning
allow_in=EditIn
...
deny=Block
isjunkmail=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.

For example

[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.

In VALIDATE.CFG:

[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.



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



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.

msw.support@mimesweeper.com

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