Page 42 - Mercury Manual.book

37 Policies
Understanding how policies work

result file, for which you can specify an explicit name, or for which Mercury can create a
name for you.

Run a program using a sentinel file When using this technique, Mercury creates an empty
file called a sentinel file, then runs the external task. When the sentinel file is deleted, Mer-
cury knows that the external task has completed, at which time it checks to see if another file,
called the result file, exists on the system: if the result file has been created, Mercury assumes
that the message has caused a policy exception. You can specify the names Mercury should
use for the sentinel and result files if you wish: if you do not, Mercury will assign names for
you. You can use commandline substitutions (see below) to pass the names of the sentinel
and result files to your external task. The sentinel file approach is usually the best way of im-
plementing your policy if you want to use batch files, scripting languages, or programs that
do not indicate success or failure via their process return codes.

Sentinel and result files
As part of defining your policy's commandline, you can specify the names of either or both
of two files: the sentinel file is only used if you are using the Run a program using a sentinel
file method, and the result file applies to both types of program execution. If your task looks
for a sentinel file with a specific name, or creates its result file with a specific name, enter that
name in the relevant field. If you do not enter a name, Mercury will create a temporary filena-
me for you automatically, which can be passed to your task on the commandline using sub-
stitutions (see below). The result file is particularly important in all cases, since Mercury
expects your task to write some kind of explanatory message it can use as a diagnostic into
this file.

Policy command settings
The external command in your policy item can have a number of settings associated with it.

This task requires attachment unpacking support If you check this control, Mercury will
check to see if the message contains multiple parts ("attachments"). If it does, Mercury will The unpacking process
extract and decode each part and pass it to your task. This is extremely useful, since it allows can significantly increase
programs that do not understand Internet transport encodings such as BASE64 or Quoted- the time it takes to apply
your policy to the mes-
printable to work with the raw data that they do understand. If you do not check this con- sage.
trol, Mercury will invoke your task once for every message, passing it a file that contains the
entire text of the message.

This task only acts on the message headers If your task only examines the headers of the
mail message and is not interested in the body or any attachments, check this control. Mer-
cury uses this control to determine whether it can optimize the policy application process by
only extracting the headers of the message. Note that even if you check this control, your task
may still be passed the entire text of the message, because Mercury only makes a single file
and if any other active policy task does not have this flag set, Mercury is forced to put the
entire text of the message into that file.

This task should only be applied to mail originating locally If you check this control, then
your task will only be invoked if the message was submitted to Mercury locally - that is, the
message was placed in the Mercury queue by a copy of Pegasus Mail or another compatible
client. Mail received via MercuryD or MercuryS never qualifies as "local" in this context.
This setting is primarily useful if you only want to apply the policy to mail sent to the outside
world by your local users.

This task should be applied before any filtering rules Checking this control will cause the
policy task to be executed before Mercury applies any global filtering rules you have defined,