Page 15 - Mercury Manual.book

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

retry period you have defined. Progressive retry mode works well when you use a retry period
You cannot currently set a
retry count greater than 99 of fifteen minutes and a maximum of 99 retries (giving a maximum retry period of about four
attempts. days).

Process the queue in two passes (file locking fix) If you check this control, Mercury will
change the way it processes mail submitted by programs such as Pegasus Mail; instead of tak-
ing the submitted job immediately, it will wait until the job has the same non-zero size for
two polling cycles in a row before processing it. This can be necessary in systems such as
If you notice that you are
occasionally seeing mes- Windows Peer-to-Peer networking where file locking is not properly implemented; it ensures
sages that appear to be that the client has finished writing the mail message to the queue before Mercury tries to proc-
truncated, try turning this
option on. ess it. Turning this option on is always safe, but will result in a slightly longer delay in mail
being sent out.

Secondary queues for mail submission
When Pegasus Mail and Mercury are used together, Pegasus Mail submits mail to be proc-
essed by Mercury as files in a queue directory. Mercury then takes these submission files and
creates its own special queue format from them.

Mercury and Pegasus Mail can, if you wish, simply share a queue directory - this is complete-
ly safe. In some cases, though, there may be advantages in separating the core Mercury queue
from the submission directory used by Pegasus Mail. To do this, click the Secondary queues
button, and tell Mercury the full path to the directory where it should look for the submission
files created by Pegasus Mail. You can create as many secondary queues as you wish - the
Mercury core module will poll them in the order they are defined at the start of each mail poll-
ing cycle.

There are typically two reasons why you might want to create secondary queues:

• Improved reliability If your file server or shared volume is less than completely reliable,
then moving the Mercury core queue to a local drive can reduce the likelihood of prob-
lems during processing if the file server or shared volume becomes unavailable for some
reason.

• Novell NetWare NDS mode When using Novell's NDS-based networking products,
licensing is calculated based on the number of connections made to the server, rather
than the number of actual users. If your users need to authenticate to a specific server to
place mail in the Mercury queue directory, then each such authentication will consume a
license entry, even if the user primarily functions on another file server on the net-
work.Creating a secondary queue on each server can dramatically reduce the number of
licensed connections used on your NDS network, because the user does not have to
establish separate authentication just to send mail - he or she can simply use the queue on
the server to which they are currently attached.

Performance note: In the Novell NetWare environment, you can gain significant extra per-
formance from Mercury by having its processing queue on a local hard drive on the worksta-
tion and the Pegasus Mail submission queue on the NetWare server. This type of
configuration also means that Mercury can usually continue running more or less normally if
your file server crashes or goes offline for any short period of time.

Important note: when using secondary queues, it is up to you to ensure that the path is valid,
It is up to you to ensure
that any secondary and that the workstation where Mercury is running has been authenticated to the file server
queues you define are ac- where the queue is located - Mercury does not attempt authentication by itself. We recom-
cessible by Mercury..
mend in the strongest possible terms that you use the Windows UNC format to specify the
location of the secondary queue, rather than a drive letter.