Page 41 - Mercury Manual.book
P. 41
Policies 36
Understanding how policies work
Policies
Mercury allows you to create policies – special tasks that are automatically applied to mail
as it passes through the server. Using policies, you could do any of the following things and
more:
• Scan incoming and outgoing mail messages for viruses
• Check messages for offensive or unsuitable content
• Keep copies of all mail messages sent to or from any address
• Create special logs indicating mail activity
• Start automated maintenance tasks simply by sending a mail message
In its simplest terms, a policy tells Mercury how to run an external program: the external pro-
gram is responsible for performing whatever task is required and communicating the results
Starting with Mercury
v4.01b, a policy can back to Mercury, which then decides how to handle the message based on the program's re-
modify the actual data in sponse. The external program can be an executable program, batch file, a script in a suitable
the message; in earlier
versions, policies only scripting language - just about anything you could run in the "Run..." dialog on the Windows
ever saw a copy of the "Start" menu. Policies are similar to filtering rules, but focus on providing the greatest possi-
message data and could
not alter the original. ble control over the way the external program is run. The decision whether particular types
of mail processing are better-handled by rules or policies will depend on your preferences and
system requirements.
You can define as many policies as you wish, and Mercury will apply them all to each mes-
sage in the central mail queue before it processes it. If any policy "triggers" (that is, indicates
by its return value that the message fits the criteria for which it is designed to test), Mercury
will perform the action associated with the policy, and will then delete the message.
To create or manage policies, select Mercury Core Module from the Configuration menu, and
select the Policy page. The Policy page shows all the policies present on your system, along
with the status of each policy (enabled or disabled). Policies are applied in the order they
appear in this dialog – it is important to keep this in mind as you work with your policies,
since the order of application can have a bearing on the point at which the actions you are
planning will occur.
Understanding how policies work
A policy consists of two parts - a command, which is an external program Mercury executes
to determine if the policy has been triggered, and an action, which describes the steps Mer-
cury should take when a policy's command indicates that a policy exception has occurred.
The policy mechanism is intended to offer the maximum of ease and flexibility in running
external processes - you should be able to run a program, a batch file, a script in a scripting
language - anything that could reasonably be run on a Windows system. To support this flex-
ibility, two different ways are provided for running the external process:
Run a program and examine the return code Mercury runs the external program and uses
Windows' process control facilities to work out when the program terminates. When the pro-
gram has finished, Mercury retrieves the program's return value from Windows and if it is
greater than zero, it assumes that the message is a policy exception. If you are writing your
own programs to implement policies for Mercury, this is usually the simplest and most effi-
cient way of doing it - simply return 0 if the message is OK, or 1 if the message contains a
policy exception. You can store any information about why the exception has occurred in the