Intermediate processing channels

Special attention is warranted for intermediate processing channels. Intermediate processing channels are channels which re-enqueue back to the MTA the mail they dequeue from it. For example, a virus scanner or a conversion channel, which, after scanning or converting a message, re-enqueues it back to the MTA for further routing or delivery. Such channels should do the following:

• Preserve Envelope Information

• Use MTA_ENV_TO

• Use Rewrite Rules to Prevent Message Loops

The sample code, Intermediate Channel Example, illustrates the SDK usage required to effect the first two preceding points.

Preserve Envelope Information

All queued messages have envelope fields which are unique to the message. For instance, a message will have the RFC 1891 envelope ID that was either assigned by the MTA when the message was first enqueued, or was specified by a remote MTA and transmitted over SMTP. The same applies to the RFC 1891 original recipient address fields that specify the original form of each of the message’s envelope recipient addresses. Furthermore, there may be other envelope fields which have non-default settings such as notification handling flags. Whenever possible, this information should be preserved as the message flows from MTA channel to MTA channel. In order to preserve this information, it must be copied from the message being dequeued to the new message being enqueued. This copying process is best done using the MTA_DQ_CONTEXT item code in conjunction with the mtaEnqueueStart() and mtaEnqueueTo() routines. When used with the former, it causes per-message envelope information to be automatically copied from the message being dequeued to the new message being enqueued. When used with the latter, it causes per-recipient information to be automatically copied.

Channel programs should not attempt to explicitly copy envelope information other than the envelope From: and envelope recipient addresses. The MTA_DQ_CONTEXT item code should always be used to implicitly perform the copy. The reason for this is straightforward: if a program attempts to do the copy explicitly by querying the fields one by one from the message being dequeued, and then setting them one by one in the message being enqueued, then any new envelope fields introduced in later versions of Messaging Server will be lost unless the program is updated to explicitly know about those new fields too.

Use MTA_ENV_TO

Intermediate processing channels should use the MTA_ENV_TO item code with mtaEnqueueTo() rather than the MTA_TO, MTA_CC, and MTA_BCC item codes. This tells the MTA that the recipient address being specified should be added to only the message’s envelope and not also to a Resent-To:, Resent-Cc:, or Resent-Bcc: header line. Example 4–3, and Example 5–2 illustrate the use of the MTA_ENV_TO item code. Both of those examples represent intermediate processing channels which are handling a previously constructed message. As such, they do not need to alter the existing message header.

Use Rewrite Rules to Prevent Message Loops

Finally, intermediate processing channels often require special rewrite rules in order to prevent message loops. Specifically, loops in which mail re-enqueued by the intermediate processing channel is queued back to the intermediate processing channel. See Preventing Mail Loops when Re-enqueuing Mail for further information on this topic.