17 Message Tracking and Recall

Oracle Communications Messaging Server includes a general message tracking and recall facility that conforms to RFCs 3885-3887. This includes support for the SMTP Extension for Message Tracking, Message Tracking Query Protocol (MTQP), and the Submission Future Release Extension (RFC 4865). The client provides tracking ID and a secret and future release delay during which the message can be recalled from the mail queue.

The recall aspect is implemented as a tracking extension. Additionally, some tracking extensions have been implemented to make it possible for a tracking client to track and recall messages submitted by a non-tracking client.

Table 17-1 shows the MTA and channel options used for and relevant to message tracking and recall.

Table 17-1 MTA and Channel Options

Option	Description
tracking_mode integer	The tracking_mode MTA option controls how message tracking information is stored by the MTA. The default value of 0 disables storage of tracking information. Setting tracking_mode to 1 enables storage using a memcached server shared across the deployment. The use of other values is currently restricted. Note that the memcache protocol is implemented by many database systems. Any implementation that supports memcached semantics can be used as an alternative to memcached. Default 0.
tracking_retries integer	Tracking information updates can fail because of simultaneous access attempts to the underlying database. If this happens the update can be retried. The tracking_retries MTA option specifies how many times to retry the update.Default 5.
tracking_retry_delay integer	The tracking_retry_delay MTA option specifies the amount of time to delay between retry attempts in units of centiseconds.Default 10.
tracking_debug integer	The tacking_debug MTA option is used to enable debug output from the MTA's tracking subsystem. The default value of 0 disables debug output. Positive values enable it. The larger the value, the more output that is produced.Default 0.
log_tracking integer	The log_tracking MTA option controls logging of message tracking and recall information. Bit 0 (value 1), if set, includes the tracking ID and the current tracking in transaction log entries. The two appear as a single field. The ID appears first and is separated from the timeout value by a colon. Tracking information appears immediately after the envelope ID and before the deferred delivery time. An mt attribute is used in the XML log format. If bit 1 (value 2) is set in the log_tracking MTA option, then the tracking ID and timeout, again separated by a colon, appear in the LOG_ACTION mapping table probe, again immediately after the envelope ID and before the deferred delivery time.Default 0.
log_futurerelease	The log_futurerelease MTA option logs the values associated with the FUTURERELEASE SMTP extension. Setting bit 0 (value 1) causes the future release value, expressed as an offset in seconds from the current time, to be logged immediately after the mailbox UID is logged. An fr attribute is used in the XML log format. If bit 1 (value 2) is set in the log_futurerelease MTA option, then this information appears in the LOG_ACTION mapping table probe immediately after the mailbox UID.
notrackingclient, notrackingserver, trackingclient, trackingserver	These channel options control the availability and use of the Message Tracking SMTP extension specified in RFC 3885. Availability of the extension is enabled with the trackingserver source channel option. The notrackingserver channel option disables the availability of the extension, and is the default. The SMTP client's use of the extension is controlled by the trackingclient and notrackingclient channel options. The former enables use of the extension. The latter disables it and is the default. Note that the extension must be enabled on all internal SMTP clients and servers throughout a deployment in order for tracking and recall to work across that deployment.
trackingtimeoutdefault integer	The trackingtimeoutdefault option specifies the default timeout that's applied if the MTRK option is issued to the SMTP server without a timeout value.Default 259200 (3 days).
trackingtimeoutmax integer	The trackingtimeoutmax option specifies the maximum allowed timeout value in seconds. Any value greater than the maximum is silently lowered to the maximum. Default 1209600 (14 days).
trackingtimeoutmin integer	The trackingtimeoutmin option specifies the minimum allowed timeout value in seconds. Any value less than the minimum is silently raised to the minimum. Default 86400 (1 day).
trackinginternal, trackingrelayed, trackingdelivered	The handling of messages relayed internal to a deployment, including internal channel hops, needs to be distinguished from the case where messages leave the administrative domain for tracking and recall to work properly. However, the SMTP protocol is commonly used in both cases. Additionally, the case where a successful channel dequeue results in message delivery also needs to be distinguished from dequeues where this does not occur. Three channel options are provided to specify these semantics: trackinginternal, trackingrelay, and trackingdelivered. trackinginternal, the default, specifies that the message is being transferred internally. trackingrelayed specifies that the channel transfers messages to some external system. trackingdelivered specifies that the channel performs final delivery of the message.
trackingmultiple, trackingsingle, trackingfirst	RFC 3885 specifies how the Message Tracking SMTP Extension interacts with aliases and mailing lists. In particular, it says, "MTAs MUST NOT copy MTRK certifiers when a recipient is aliased, forwarded, or otherwise redirected and the redirection results in more than one recipient. However, an MTA MAY designate one of the multiple recipients as the "primary" recipient to which tracking requests shall be forwarded; other addresses MUST NOT receive tracking certifiers. MTAs MUST NOT forward MTRK certifiers when doing mailing list expansion." This arguably makes sense for tracking-only applications where presenting the results of a complex alias expansion process to the end user may be confusing. However, the situation with message recall is different. Users expect recall to work when feasible, including when alias expansion is involved. (Mailing lists are different; a mailing list effectively "owns" its messages once it expands, so recall past a mailing list expansion is inappropriate.) Accordingly, three source channel options are provided to control the MTA's behavior in this regard. trackingmultiple, the default, tells the MTA to pass tracking ID/timeout information to all recipients of an alias expansion. trackingsingle causes tracking ID/time information to pass through only when there is a single recipient. trackingfirst causes tracking information to pass through to the first alias expansion recipient. (Note that in the case of aliases stored in LDAP, the first recipient is unpredictable.)
trackinggenerate n	Message tracking and recall depends on the generation, attachment, and transfer of tracking identifiers. Such identifiers are normally generated and attached to messages by the submitting client. However, essentially no clients currently support the generation of such identifiers, making it impossible to write a separate tracking/recall client to deal with messages submitted by a non-tracking-enabled client. Additionally, a user who elects to use multiple clients, some tracking-enabled and some not, will end up with only a subset of their messages able to be tracked and recalled. Tracking identifiers can also provide, independent of their use for user tracking and recall, a stable identifier that ties MTA log entries across multiple systems together in ways that envelope IDs and Message-ID header fields do not and cannot. As such, automatic assignment of tracking identifiers to message on ingress as well as submission has real utility independent of user tracking and recall functions. The trackinggenerate source channel option addresses these needs. A single required integer option specifies the default tracking timeout. If set, a tracking identifier for the message is generated in one of two ways: If authentication has been used and the user has a general recall secret associated with their LDAP entry, a per-message recall secret is generated by computing a SHA-1 hash of the concatentaiton of the content of Message-ID: header field , the Date: header field (if present), and the general recall secret. The tracking timeout is controlled by the trackinggenerate value. If authentication was not used or no general recall secret is associated with the account, a tracking identifier is created by hashing a unique identifier with an MD4 hash. Note that the security of this process is controlled not by the randomness of the unique identifier or the use of MD4, but rather by the infeasibility of computing X given T, where SHA1(X) = MD4(T).
ldap_attr_auth_recall_secret	The ldap_attr_auth_recall_secret MTA option specifies the name of the LDAP attribute where a user's general recall secret is stored. This option has no default.
memcache_host	Specifies the name of the host running either memcached or a memcached-compatible server where tracking and recall information will be stored. Note that each tracked message creates a single entry with the tracking ID as the key. The size of the entries is highly dependent on the number of recipients. Messages with large numbers of recipients can result in very large entries. This option has no default.
memcache_port	Specifies the memcached port on the host specified by memcache_host.Default 11211.