Page 106 - Mercury Manual.book

101 Workflow and Implementation
Deferred jobs

8: Mercury now extracts the originator address from the message and examines it: if it is from
a domain Mercury regards as local, it validates the address and (unless it has been instructed
to accept messages from non-existent local senders) issues an error if the address is invalid.
If the originator address is non-local, Mercury does not attempt to validate the address in any
way.

9: Next, Mercury steps through the job’s control file, one recipient at a time. For each recip-
ient address, it takes the following steps:

• It attempts to resolve the address as an alias; it will do this up to a maximum of five
times (in case you have aliases for aliases).
• It processes special aliases in the order FILE:, TFILE:, DAEMON: then FILTER: if the
address resolves to one of these special alias forms, it is processed immediately, which
may result in a new job or jobs being placed in the Mercury queue.
• It checks the entire address to see if it is a synonym (alternative address format). It only
does this one level deep, because you can't have a synonym for a synonym.
• It breaks the address down into username and domain portions.
• If the domain portion is not recognized as local, an outgoing job containing a copy of the
message is created, and the address is added as a recipient. If an outgoing job has already
been created for a prior address, the address is added as a recipient of that job.
• It scans the “local domains” list to determine whether or not the domain portion of the
address refers to a domain mailbox (a “DM” entry).
• It compares the username portion of the address with the “List of Lists”, to see if it refers
to a mailing list.
• It checks once again to see if the username portion of the address is a synonym - this
allows synonyms to have a domain or not, depending on the needs of the administrator.
• It checks to see if the address is a network (NetWare) group reference.
• It checks for the "percent hack" address format - this is primarily done to determine
whether or not an address refers to a noticeboard (e.g. comp.humor%nb@domain.com).
• It checks to see if the username part of the address is a valid local username. If it is, it
determines the location of the user’s mailbox directory and writes a copy of the message
there as a .CNM file, adding a Received: header as required.
• If the username is not a valid local part, it compares it with the reserved usernames
"postmaster" and "supervisor" as a final check. If the address matches either of these
reserved addresses, it looks up the username associated with the postmaster account and
delivers the message to that user’s mailbox directory.
• If it hasn't determined that the address is local by this point, it creates a non-delivery
notification and adds the recipient’s address to it as “user not known”.

Deferred jobs

From time to time, you may see the diagnostic “* Deferred” in the Mercury Core Module
console window when it attempts to deliver a message to a local user. A job is deferred in the
following situations:

• When the underlying user database indicates that it is temporarily unavailable for some
reason, preventing Mercury from verifying user details. This happens in NetWare NDS
mode if the NDS database is closed (for instance, by a backup process) while a job is
being processed.
• If the recipient address refers to a mailing list, but Mercury is unable to open the list
membership file (this can happen if another process has the file open).
• If a Daemon (a third-party plugin module) indicates to Mercury that the job should be
deferred for some reason.