MERCURY MAIL 32BIT
MAIL PROCESSING ORDER.

Last update 30-Dec-2003.

 
Processing order Mercury/32 (version 3.30 and up)

 

  • MercuryS receives the message and creates a job in the queue.

  • It writes the envelope information into the queue control file (.QCF), and the data into the queue data file (.QDF).

  • MercuryS will add a "Received" header and a "Return-path" header to the data, and may add "X-ORBS" and "X-RBL" headers.

  • It typically does not add any other headers to the message.

  •  

  • On its next poll cycle, the core module opens the job.

  •  

  • It performs any Daemon processing on the job. Daemons get access to both the queue control file and the queue data file.

  •  

  • It performs any pre-filtering policy definitions on the job. Policy tasks only get access to the queue data file.

  •  

  • It preforms Content control on the job. CC only get access to the queue data file.

  •  

  • It performs any global filtering on the job. Filters only get access to the queue data file.

  •  

  • It performs any post-filtering policy definitions on the job. As before, policy tasks only get access to the queue data file.

  •  

  • It extracts the originator address from the message and validates it.

  •  

  • Next, it steps through the control file, one recipient at a time.

  •  
    For each 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:.

  •  

  • It resolves the address as a synonym. 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 recongized as local, an outgoing job containing a copy of the message is created, addressed to the address.
    It is at this point that Mercury determines whether or not the address refers to a domain mailbox.

  •  

  • Next, it checks to see if the address is a distribution list

  •  

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

  •  

  • Next, it checks to see if the address is a group reference.

  •  

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

  •  

  • Near the end now: it checks to see if the username part is a valid local username.

  •  

  • If the username is not a valid local part, it compares it with "postmaster" and "supervisor" as a final check.

  •  

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

  • The process of actually writing the message into the destination mail directory is the last step in the process. Prior to that, the message is held in a queue format that preserves information like the envelope, the number of retries and so on. Filtering and policies are applied to the queue version of the message, because they are designed to handle the message as a whole, rather than a single instance of its delivery.


    Han van den Bogaerde
    e-mail  Homepage