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. <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.