Tracking*, notracking* Channel Options

Message Tracking and Recall Channel Options
The message tracking and recall facility consists of an SMTP service extension (RFC 3885) as well as a separate MTQP server (RFC 3887). (Note that these standards only specify message tracking; message recall is an Oracle extension.) Mail clients can use this facility to track and possibly recall messages they have sent. This set of keywords controls the availability and handling of the Message Tracking SMTP extension.

The extension is enabled with the  source channel option. The  channel option disables the availability of the extension, and is the default. The  source channel option specifies the default timeout in seconds if no timeout value is specified in the MTRK command, as allowed by the protocol. The default is 3 days.

The  and   source channel options specify the minimum and maximum allowed timeout value in seconds; any value greater than the maximum or less than the minimum is silently lowered or raised to the corresponding limit. The defaults are 1 and 14 days, respectively.

The SMTP client&#x27;s use of the extension is controlled by the  and   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 clients and servers throughout a deployment in order for tracking and recall to work across that deployment.

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:,  , and. , the default, specifies that the message is being transferred internally. specifies that the channel transfers messages to some external system. Finally,  specifies that the channel performs final delivery of the message.

RFC 3885specifies 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&#x27;s behavior in this regard. , the default, tells the MTA to pass tracking id/timeout information to all recipients of an alias expansion. causes tracking id/time information to pass through only when there is a single recipient. Finally,  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.)

See also:
 * tracking_mode MTA Option
 * tracking_debug MTA Option
 * log_tracking MTA Option
 * Message tracking channel options
 * Message tracking MTA options
 * Message tracking channel options