Page 14 - Mercury Manual.book

9 The Mercury Core Module
The “Mercury Core Module” Configuration menu option.

mote system, and the connection to the remote system becomes unavailable, mail may be lost
or damaged.

Mercury creates Queue Job Files in the primary queue: queue job files are typically pairs of
files with the same name part and different extensions: a job will always have a Queue Con-
trol File (with the extension .QCF) and a Queue Data File (with the extension .QDF); any
job may also have one or more Queue Information Files (with the extension .QIF). Queue
information files do not necessarily have the same name part as the job to which they belong
- they are used to store information about the processing state of the job, such as error mes-
sages. While queue job files may look like text files, they are not - they have a very specific
structure, and you should not attempt to edit them manually unless you are very sure of what
you are doing.

Primary queue directory Enter here the directory on a local drive which Mercury should use
as its primary mail queue. If you have a real-time virus scanner system, make sure that this
directory is exempted from its operation: real-time scanners interfere with Mercury's access
to its files and may result in damage or loss of mail. To perform anti-virus scanning of your
mail, create a Mercury policy, or use a Mercury anti-virus Daemon (plugin) such as Lukas
Gebauer's ClamWall instead.

Queue Processing Controls
This group of controls manage the way Mercury accesses the queue, and how it handles errors
and delays.

Basic minimum period between queue job retries Controls how frequently Mercury/32
should retry messages that have temporary delivery problems. You cannot set a retry period
shorter than one minute. 60 minutes is usually a good default value for this control, unless
you are using Mercury's progressive backoff algorithm (see below), in which case we recom-
mend a value of 15 minutes.

Maximum number of retries allowed before failure Controls the maximum number of times
a job should be retried before Mercury should conclude that it cannot be delivered. You can-
not set fewer than two, or more than 99 retry attempts.

Send delivery status notifications... These three controls allow you to configure Mercury to
send out Delivery Status Notifications (DSNs) when a message is delayed in the queue. By
default, Mercury will send DSNs at 3 hours (180 minutes), 24 hours (1440 minutes) and 72
hours (4320 minutes) of delay, but you can specify any gap you wish between the notifica-
tions. To suppress a DSN, enter a value of zero for its delay. To suppress status notifications
altogether, set all three fields to zero. Mercury uses a template file called DWARN.MER in the
same directory as MERCURY.EXE to prepare Delivery Status Notifications; deleting or renam-
ing this file will also prevent DSNs from being generated.
Only send delivery status notifications to local users If you check this control, Mercury will
only send DSNs (see above) when it can identify the sender of the message as being a local
address, or an address served by an alias on the local machine. Checking this reduces the like-
lihood of having DSNs for delayed spam cluttering up your system - you should normally
leave it checked (the default state).

Use progressive backoff algorithm to calculate job retries When you check this control,
Mercury will change the way it calculates retries on undeliverable mail. Normally, it simply
adds whatever retry period you have defined to the current time, but in progressive mode, it
will increase the period between retries the more of them there are. For every ten retries, the
time between retries increases by progressively larger steps, to a maximum of seven times the