Mercury/32 has a pretty complex data flow for processing mail. A good understanding of the way that mail flows through Mercury/32 will be a great aid to many administration functions, such as virus scanning and ControllingSpam.

This guide is intended as an update to "Mercury/32's message processing flowchart" provided in the official Pegasus Mail and Mercury Knowledgebase. The posted knowledgebase guide is slightly out of date in parts, as it was last updated at the release of Mercury/32 3.31. In particular, it does not address DNSBL checks, compliance checks, or the TransactionFiltering introduced in Mercury/32 v4.01a.

Michael Walsh has A GRAPHICAL PROCESSING CHART on his web site. In addition, Michael's site also has a ONE-FILE REPLACEMENT TRANSFLT.MET to automagically immediately BEGIN HALTING SPAM, and spam only, before it enters the server. Han van de Bogaerde also has a processing flow description on his site that is similar to the one posted on the official knowledgebase, but more up to date.

This chart is up to date as of Mercury/32 4.01b.

Note: The following process flow assumes that all options are enabled. Many options can be enabled or disabled as desired.

Steps 1 through 5 are applied in real time as the message is being received by MercuryS. Failing any one of these checks results in the specified action being taken. The action could be a droped connection, message logged, etc. Check the Mercury/32 help files for more information regarding TransactionFiltering, as well as Michael Walsh's free replacement advanced transflt.mer as described in steps 2 through 5.

  1. The first step in message processing come when the sending server's IP address is checked against the MERCURYS.ACL. If an IP is listed as Refuse in the ACL, it cannot connect to the MercuryS module at all.

    Note: ACLs are kept separately for the various Mercury/32 modules. The presence of an IP address in the ACL for one module does not confer any restrictions or exemptions for other modules.

  2. When the HELO/EHLO line is sent by the sending server, it is checked against the appropriate H type transaction filtering rules.

  3. When the MAIL FROM: line is sent, several things happen, in the following order:

    1. It is checked against any M type transaction filters.
    2. It is checked against the MercuryS killfile.
    3. The connecting IP address is checked against any DNSBLs or DNSWhiteLists. DNSBL failure can result in rejection or tagging. A positive match against a DNS white lists stops all futher DNSBL testing.
  4. When the RCPT TO: line is sent, it is checked against any applicable R type transaction filtering rules.

  5. While the DATA portion of the message is being received, the following items are checked:

    1. The From: line can optionally be checked against the MercuryS killfile.
    2. The Subject line is checked against any applicable S type transaction filter rules.

    3. Other message headers are checked against MercuryS compliance options, as applicable, such as:

      1. No or missing subject
      2. No date
      3. Non-MIME format
      4. Pure HTML
  6. This step applies only to messages written directly to the Mercury queue directory by Pegasus Mail or Mercury/32 itself as .101 files: Mercury core opens the .101 file and converts it to QCF/QDF format. The QCF, or Queue Control File, contains the envelope addressing information. The QDF, or Queue Data File, contains the actual message. The original .101 file is deleted.
  7. This step applies only to messages received by MercuryS or MercuryD: The message is written to the Mercury/32 queue directory by Mercury/32 as a QCF and QDF file pair. The QCF, or Queue Control File, contains the envelope addressing information. The QDF, or Queue Data File, contains the actual message.
  8. The message is sent to any daemons for processing. The daemon receives both the QCF and QDF file.
  9. After daemons, any pre-filtering policies are performed. Policies only get access to the QDF file, as well as several standard headers through substitution variables. Refer to the Mercury/32 help files for more information on policies.
  10. ContentControl is performed. Note that each Content Control definition has it's own white and black lists. Content Control only gets access to the QDF file, containing the message headers and body.
  11. Global filtering rules are performed. Global filters only get access to the QDF file.
  12. Post-filtering policies are performed. Policies only get access to the QDF file, as well as several standard headers through substitution variables.
  13. Mercury Core extracts the originator address from the message and validates it.

  14. Mercury Core steps through the recipients, one at a time. For each address, it takes the following steps:

    1. 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).
    2. It processes special aliases in the order FILE:, TFILE:, DAEMON: then FILTER:.
    3. It resolves the address as a synonym. It only does this one level deep, because you can't have a synonym for a synonym.
    4. It breaks the address down into username and domain portions.
    5. If the domain portion is not recongized as local, an outgoing job containing a copy of the message is created, addressed to the return address.
    6. It is at this point that Mercury determines whether or not the address refers to a domain mailbox (DM).
    7. Next, it checks to see if the address is a mailing list.
    8. Next, it checks again to see if the address is a synonym - this allows synonyms to have a domain or not, depending on the needs of the administrator.
    9. Next, it checks to see if the address is a network (NetWare) group reference.
    10. Next it checks for the "percent hack" - this is basically the point at which it decides whether or not an address refers to a noticeboard (e.g. comp.humor%nb@domain.com).
    11. Near the end now: it checks to see if the username part is a valid local username.
    12. If the username is not a valid local part, it compares it with "postmaster" and "supervisor" as a final check.
    13. If it hasn't determined that the address is local by this point, it returns an error, otherwise it gets the mailbox for the user and writes the message into it.

Significant portions (particularly, step 14) shamelessly copied from the knowledgebase article specified at the beginning of this guide.

3 pages link to MessageProcessingFlowChart:
 . Page Name .   . Last Modified . 
 Mercury32   June 28, 2006 8:39 am 
 MercuryDaemons   April 11, 2006 9:10 am 
 Spamwall FAQ   September 4, 2006 11:26 am