Mercury FAQ
Mercury/32's message processing flowchart

At Peter's request, I have updated the chart he posted with the new, updated version.

At Peter's request, I have updated the chart he posted with the new, updated version.

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 Transaction Filtering, 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 DNS White Lists. 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. Content Control 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.

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 Transaction Filtering, as well as Michael Walsh's free replacement advanced transflt.mer as described in steps 2 through 5. <ol> <li class="tightenable"> <p class="tightenable top">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.</p> <p class="tightenable bottom"><i><b>Note:</b> 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.</i></p> </li> <li class="tightenable">When the HELO/EHLO line is sent by the sending server, it is checked against the appropriate H type transaction filtering rules.</li> <li class="tightenable"> <p class="tightenable top bottom">When the MAIL FROM: line is sent, several things happen, in the following order:</p> <ol> <li class="tightenable top bottom">It is checked against any M type transaction filters.</li> <li class="tightenable top bottom">It is checked against the MercuryS killfile.</li> <li class="tightenable top bottom">The connecting IP address is checked against any DNSBLs or DNS White Lists. DNSBL failure can result in rejection or tagging. A positive match against a DNS white lists stops all futher DNSBL testing.</li> </ol> </li> <li class="tightenable">When the RCPT TO: line is sent, it is checked against any applicable R type transaction filtering rules.</li> <li class="tightenable"> <p class="tightenable top bottom">While the DATA portion of the message is being received, the following items are checked:</p> <ol> <li class="tightenable top bottom">The From: line can optionally be checked against the MercuryS killfile.</li> <li class="tightenable top bottom">The Subject line is checked against any applicable S type transaction filter rules.</li> <li class="tightenable top bottom"> <p class="tightenable top bottom">Other message headers are checked against MercuryS compliance options, as applicable, such as:</p> <ol> <li class="tightenable top bottom">No or missing subject</li> <li class="tightenable top bottom">No date</li> <li class="tightenable top bottom">Non-MIME format</li> <li class="tightenable top bottom">Pure HTML</li> </ol> </li> </ol> </li> <li class="tightenable">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.</li> <li class="tightenable">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.</li> <li class="tightenable">The message is sent to any daemons for processing. The daemon receives both the QCF and QDF file.</li> <li class="tightenable">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.</li> <li class="tightenable">Content Control 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.</li> <li class="tightenable">Global filtering rules are performed. Global filters only get access to the QDF file.</li> <li class="tightenable">Post-filtering policies are performed. Policies only get access to the QDF file, as well as several standard headers through substitution variables.</li> <li class="tightenable">Mercury Core extracts the originator address from the message and validates it.</li> <li class="tightenable"> <p class="tightenable top">Mercury Core steps through the recipients, one at a time. For each address, it takes the following steps:</p> <ol> <li class="tightenable bottom">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).</li> <li class="tightenable top bottom">It processes special aliases in the order FILE:, TFILE:, DAEMON: then FILTER:.</li> <li class="tightenable top bottom">It resolves the address as a synonym. It only does this one level deep, because you can't have a synonym for a synonym.</li> <li class="tightenable top bottom">It breaks the address down into username and domain portions.</li> <li class="tightenable top bottom">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.</li> <li class="tightenable top bottom">It is at this point that Mercury determines whether or not the address refers to a domain mailbox (DM).</li> <li class="tightenable top bottom">Next, it checks to see if the address is a mailing list.</li> <li class="tightenable top bottom">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.</li> <li class="tightenable top bottom">Next, it checks to see if the address is a network (NetWare) group reference.</li> <li class="tightenable top bottom">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).</li> <li class="tightenable top bottom">Near the end now: it checks to see if the username part is a valid local username.</li> <li class="tightenable top bottom">If the username is not a valid local part, it compares it with "postmaster" and "supervisor" as a final check.</li> <li class="tightenable top bottom">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.</li> </ol> </li> </ol>

I created an updated version of this flowchart a few years ago that includes additions for transaction filtering, DNSBLs, and probably a few other things. The updated version can be found on my Wiki: http://email.arcm.com/wiki/index.php/MessageProcessingFlowChart Feel free to include a copy here, if you'd like.

I created an updated version of this flowchart a few years ago that includes additions for transaction filtering, DNSBLs, and probably a few other things. The updated version can be found on my Wiki: http://email.arcm.com/wiki/index.php/MessageProcessingFlowChart Feel free to include a copy here, if you'd like.
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft