Page 105 - Mercury Manual.book

Workflow and Implementation 100
Message Processing Flowchart

Workflow and Implementation

This chapter presents some overviews and insights into the way Mercury works: it may be
useful to help system admininstrators understand some of the many pathways by which mail
delivery and handling can occur on their system. It may also be useful in troubleshooting cer-
tain error conditions in some cases.

Message Processing Flowchart

From the time a message arrives in the Mercury mail queue until the time it ends up in the
The extension .CNM recipient’s mailbox as a file with the extension .CNM, a great deal can happen to it. This sec-
comes from the name I tion describes the various steps and processes that are applied to a message, and the order in
originally planned for
Pegasus Mail back in which they occur.
1989, “ComNet Mail”.
1: If the message originates internally within the mail system, then either Pegasus Mail or
Mercury has created a .101 file in the Mercury spool directory. Mercury processes the .101
spool file by processing the envelope information into a queue control file (.QCF) and the
data into a queue data file (.QDF), then it deletes the .101 file.

1a: If the message originates from outside the local mail system, then it has either been re-
ceived by the MercuryS SMTP server, or picked up from a remote POP3 mailbox by the Mer-
curyD POP3 client. In either case, it will enter the mail queue directly as a .QCF/.QDF file
pair, without ever being written into the interim .101 file format. Some other types of mes-
sage, including automatic replies, messages that are autoforwarded and messages generated
by the mail server also go directly into the queue without appearing in the interim .101 for-
mat.

2: On its next poll cycle, the core module opens the job. The job may contain internal timers
that indicate that it should not be processed until a particular time; if the job is not due for
processing yet, Mercury closes the job and moves onto the next one in the queue. If the job
is ready for processing, Mercury moves onto step 3.

Daemons can “kill” a mes- 3: Any Daemons in the system are given an opportunity to process the job. Daemons (or “plu-
sage, resulting in it being gins” as they might be called in other systems) get full access to both the queue control file
removed from the queue
without being processed. and the queue data file, and can modify the job in any way.
4: If any pre-filtering policy definitions exist, they are applied to the job. Policy tasks only
get access to the queue data file as well as to certain standard header values through substi-
tution variables and can alter the message data, or instruct Mercury to delete the job altogeth-
er.

5: Any content control sets that are enabled are applied to the message data. Like policies,
content control sets can result in the message data being altered, or the message being deleted
altogether.

6: Any active global filtering rules are applied to the job. Once again, the filtering process can
result in the message being diverted, deleted or otherwise removed from the queue, at which
point processing on the job ends.

7: If any post-filtering policy definitions are active, they are now applied to the job. As with
pre-filtering policies, this process may result in the message being altered or deleted.