Pegasus Mail & Mercury

Welcome to the Community for Pegasus Mail and
The Mercury Mail Transport System, the Internet's longest-serving PC e-mail system!
Welcome to Pegasus Mail & Mercury Sign in | Join | Help
in
Home Blogs Forums Downloads Pegasus Mail Overview Mercury Overview Wiki

Mercury/32's message processing flowchart

Last post 04-30-2007, 21:41 by Rob. 2 replies.
Sort Posts: Previous Next
  •  04-22-2007, 15:15

    Mercury/32's message processing flowchart

    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.
  •  04-26-2007, 21:56

    • Rob is not online. Last active: 05-11-2010, 15:18 Rob
    • Top 500 Contributor
    • Joined on 02-07-2007
    • Ohio, USA
    • Member
    • Points 380
    • BetaTeam Moderator

    Re: Mercury/32's message processing flowchart

    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.
  •  04-30-2007, 21:41

    • Rob is not online. Last active: 05-11-2010, 15:18 Rob
    • Top 500 Contributor
    • Joined on 02-07-2007
    • Ohio, USA
    • Member
    • Points 380
    • BetaTeam Moderator

    Re: Mercury/32's message processing flowchart

    At Peter's request, I have updated the chart he posted with the new, updated version.
View as RSS news feed in XML

Contact | Advertise | Host provider: PraktIT | Terms of Use | Privacy Statement
Copyright © 2007-2011 David Harris / Peter Strömblad. | Pegasus Mail Home Page