Message tracking and recall setup and configuration

There are three parts to setting up message tracking and recall capabilities:



 Setting up a shared memcached server (or other software that implements the memcache protocol in a compatible fashion) to store tracking/recall information. 

 Configuring all the MTAs in the deployment to enable tracking and recall. 

 Setting up Message Tracking and Query Protocol (MTQP) servers on every MTA and possibly additional hosts. 



Memcache server setup
Setting up memcached or compatible server is beyond the scope of this document. That said, note that mecmached setup is very simple: Configuration consists of a small number of options on the command line. Indeed, it&#x27;s often possible to simply say: memcached -l &#x3c;ip-address&#x3e; Where &#x3c;ip-address&#x3e; is the IP address where memcached accepts connections.

Once a server implementing the memcache protocol has been set up, every MTA in the deployment have to be configured to access it. This is done with the  MTA option; there is no tracking-specific host setting at the present time. The  MTA option must be explicitly set  if the server is listening on a port other than 11211. It may be appropriate to set the   MTA option to an appropriate value as well.

Tracking/recall is enabled within the MTA by setting the   MTA option to 1. Logging tracking identifiers is good idea; this is controlled by the  MTA option.

Taken together, and assuming the memcache server is listening on the default port, the MTA option settings should look something like this: msconfig&#x3e; show memcache_host role.mta.memcache_host memcache-server-ip msconfig&#x3e; show tracking_mode role.mta.tracking_mode 1 msconfig&#x3e; show log_tracking role.mta.log_tracking 1 or in legacy configuration: MEMCACHE_HOST=&#x3c;memcache-server-ip&#x3e; TRACKING_MODE=1 LOG_TRACKING=1

MTA channel setup for message tracking and recall
The next step is to tell the tracking subsystem the semantics of the various channels in the deployment using the,  , and. The general rules are:



 Internal processing channels such as ,  ,   , and    require no special decoration. 

 Channels that perform final delivery must be marked with the   channel option. This includes not only   and    channels,  but also the   and   channels. 

 Any channel that relays messages to systems outside the deployment must be marked with the   channel option. Of course this includes the   channel,  but would also include, say a special   channel set up to handle mail to the aol.com domain. 

 Finally, any channel that relays message to other MTAs inside the deployment where tracking is enabled. This would typically be something like a   channel. </li>

</ol>

Note that for tracking and recall to work messages relayed to external systems MUST be handled by a different channel than messages relayed to other MTAs inside the deployment. (At a minimum, this tends to mean using a distinct   vs.     channel.) Meeting this requirement may require additional configuration changes.

The MTRK SMTP extension defined in RFC 3885 is used to transfer tracking/recall information from one MTA to another. Use of this extension MUST be enabled on SMTP connections between MTAs inside the deployment. It also must be enabled on SUBMIT channels used by tracking/recall-enabled clients.

Since MTRK is an SMTP extension, its use is negotiated by the SMTP client and server. So the simplest way to activate this extension is to put the   and    on the defaults channel. However, if you wish to avoid use of this extension with systems outside the deployment, a more targeted approach is needed: Place  on every   channel that has   set. Then place  on every channel that accepts messages from other hosts within the deployment. (Note that once again this may require configuration changes to separate internal and external traffic.)

MTQP server setup
An extended version of MTQP as specified in RFC 3887 is used to perform tracking and recall operations. If only tracking is desired a single MTQP server can be used for the entire deployment and can be run on any host. However, in order to recall messages an MTQP server must be running on every host with an MTA, and if "total recall" is enabled MTQP servers are required on all store hosts as well.

The MTQP server leverages existing MTA facilities which require a channel. Note that the MTQP channel doesn&#x27;t sent or receive messages and has no rewrite rules or associated queue. The specification of such a channel is very simple. In legacy configuration: mtqp smtp mtqp-daemon or in Unified Configuration: msconfig&#x3e; set channel:mtqp.officical_host_name mtqp-daemon msconfig# set channel:mtqp.smtp Although somewhat counterintuitive, the " " channel option is required to indicate this is a channel with an associated server. Various optional channel options can also be specified, including:

<ul>

 or  are used to control whether SSL/TLS is allowed or required, respectively, before tracking/recall operations may be performed. </li>

 enables MTQP server debugging. </li>

 may be specified to enable user authentication. User authentication is required in order to use the MTRACK and/or MRECALL commands. </li>

 , ,  and    have their usual meanings. </li>

</ul>

Some MTQP-server-specific options are also available:

<dl>

<dt> (boolean 0 or 1, default 0) </dt>

<dd> If set to 1, this option enables recall of messages from the store. Note that if this is used it will result in messages being deleted from recipient&#x27;s folder irrespective of whether or not they have been read. Use of this option should only be undertaken with a full understanding of the possible consequences. </dd>

<dt> (debug token list, default "") </dt>

<dd> This option is used to specify authentication debugging tokens. </dd>

<dt> (integer seconds, default 60) </dt>

<dd> This option specifies the time the server will wait for a command before disconnecting. </dd>

<dt> (integer seconds, default 60) </dt>

<dd> This option specifies the time the server will wait for a status write to the client before disconnecting. </dd>

<dt> (string, default "") </dt>

<dd> This option specifies the name the server uses to announce itself. </dd>

</dl>

Additionally, the server recognizes and will honor the TCP/IP channel-specific options,  ,  , and.

Finally, a Dispatcher service definition for the MTQP server is also required. In legacy configuration: &#x5b;SERVICE=MTQP&#x5d; PORT=1038 IMAGE=IMTA_BIN:mtqp LOGFILE=IMTA_LOG:mtqp_server.log STACKSIZE=2048000 or in Unified Configuration: msconfig&#x3e; set service:MTQP.image IMTA_BIN:mtqp msconfig# set service:MTQP.tcp_ports 1038 msconfig# set service:MTQP.logfilename IMTA_LOG:mtqp_server.log msconfig# set service:MTQP.stacksize 2048000

See also:
 * Message tracking MTA options
 * MTQP MTA options
 * Memcache MTA options
 * Message tracking channel options
 * Message tracking and recall
 * memcache_host Option
 * memcache_port Option
 * memcache_expire MTA Option
 * tracking_mode MTA Option
 * log_tracking MTA Option
 * trackinginternal Option
 * tracking_hash_algorithm MTA Option