Difference between revisions of "Message tracking and recall setup and configuration"

From Messaging Server Technical Reference Wiki
Jump to: navigation, search
m (Bulk update)
m (Bulk update)
 
Line 194: Line 194:
 
* [[log_tracking MTA option#log_tracking|log_tracking MTA Option]]
 
* [[log_tracking MTA option#log_tracking|log_tracking MTA Option]]
 
* [[tracking*, notracking* Channel Options#trackinginternal|trackinginternal Option]]
 
* [[tracking*, notracking* Channel Options#trackinginternal|trackinginternal Option]]
 +
* [[tracking_hash_algorithm MTA option#tracking_hash_algorithm|tracking_hash_algorithm MTA Option]]
 
[[Category: Reference]]
 
[[Category: Reference]]
 
[[Category: Discussion]]
 
[[Category: Discussion]]

Latest revision as of 17:12, 13 February 2020


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

  1. Setting up a shared memcached server (or other software that implements the memcache protocol in a compatible fashion) to store tracking/recall information.
  2. Configuring all the MTAs in the deployment to enable tracking and recall.
  3. 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's often possible to simply say:

        
  memcached -l <ip-address>

Where <ip-address> 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 memcache_host MTA option; there is no tracking-specific host setting at the present time. The memcache_port MTA option must be explicitly set if the server is listening on a port other than 11211. It may be appropriate to set the memcache_expire MTA option to an appropriate value as well.

Tracking/recall is enabled within the MTA by setting the tracking_mode MTA option to 1. Logging tracking identifiers is good idea; this is controlled by the log_tracking 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> show memcache_host
role.mta.memcache_host memcache-server-ip
msconfig> show tracking_mode
role.mta.tracking_mode 1
msconfig> show log_tracking
role.mta.log_tracking 1

or in legacy configuration:

        
  MEMCACHE_HOST=<memcache-server-ip>
  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 trackinginternal, trackingrelayed, and trackingdelivered. The general rules are:

  1. Internal processing channels such as process, reprocess, conversion, and defragment require no special decoration.
  2. Channels that perform final delivery must be marked with the trackingdelivered channel option. This includes not only ims-ms and tcp_lmtpcs channels, but also the bitbucket and filter_discard channels.
  3. Any channel that relays messages to systems outside the deployment must be marked with the trackingrelayed channel option. Of course this includes the tcp_local channel, but would also include, say a special tcp_aol channel set up to handle mail to the aol.com domain.
  4. Finally, any channel that relays message to other MTAs inside the deployment where tracking is enabled. This would typically be something like a tcp_intranet channel.

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 tcp_local  vs.  tcp_intranet 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 trackingclient and trackingserver 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 trackingclient on every tcp_* channel that has trackinginternal set. Then place trackingserver 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'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> set channel:mtqp.officical_host_name mtqp-daemon
msconfig# set channel:mtqp.smtp

Although somewhat counterintuitive, the "smtp" channel option is required to indicate this is a channel with an associated server. Various optional channel options can also be specified, including:

Some MTQP-server-specific options are also available:

TOTAL_RECALL (boolean 0 or 1, default 0)
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'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.
AUTH_DEBUG (debug token list, default "")
This option is used to specify authentication debugging tokens.
COMMAND_TIMEOUT (integer seconds, default 60)
This option specifies the time the server will wait for a command before disconnecting.
STATUS_TIMEOUT (integer seconds, default 60)
This option specifies the time the server will wait for a status write to the client before disconnecting.
CUSTOM_BANNER_STRING (string, default "")
This option specifies the name the server uses to announce itself.

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

Finally, a Dispatcher service definition for the MTQP server is also required. In legacy configuration:

        
  [SERVICE=MTQP]
  PORT=1038
  IMAGE=IMTA_BIN:mtqp
  LOGFILE=IMTA_LOG:mtqp_server.log
  STACKSIZE=2048000

or in Unified Configuration:


msconfig> 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: