Transport features of the sample gateway include:
The sample gateway provides native transport, which means it uses its own format for transporting the content of a message. Messages are encoded in a format based on RFC 822. This message format is shown in Sample Gateway Message Format.
If a syntax error occurs in the message envelope, the gateway places an event in the Windows NT Application event log indicating the message identifier and that it was rejected because of a syntax error. If there is a syntax error in the message content, the message is declared as nondeliverable.
The sample gateway does not support nested messages. It will not stop if it detects a nested message, but it will not attempt to preserve the content of nested messages.
The sample gateway always looks for a TNEF attachment when it receives a message and, if there is one, extracts any MAPI properties from it. If at least one recipient of a message is a MAPI recipient, the gateway generates a TNEF attachment in addition to the regular content of the message. The gateway ensures that each attachment has a unique file name relative to the message, and automatically creates unique attachment names if the message has multiple attachments with the same name. The gateway uses TNEF mechanisms to preserve attachment locations. Applying TNEF to a message preserves embedded messages while using native transport does not.
If a message is addressed to both MAPI and non-MAPI recipients, the gateway creates two files: one with a TNEF attachment for MAPI recipients and one without a TNEF attachment for non-MAPI recipients.
The message class determines how the gateway transports a message. IPM and REPORT messages are detected and transported differently. Other classes of messages are simply nondelivered, which means that a nondelivery report (NDR) is sent to the originator of the message. A useful enhancement to the sample gateway would be the ability to delivery any message class by packaging all the message's properties in a TNEF attachment and sending that attachment as the sole content of the outgoing message. The gateway could still generate NDRs if there are no MAPI recipients of such a message.
The sample gateway transports delivery reports, nondelivery reports, receipt notifications, and nonreceipt notifications as distinct message classes. It does this by defining a native format for the encoding of REPORT messages.
The sample gateway uses the MAPI IAddressBook::PrepareRecips method to map recipients to an address type that is configurable, which is initially set to EDK. Messages are nondelivered for Responsibility-TRUE recipients that cannot be mapped. Responsibility-FALSE recipients that cannot be mapped are dropped from the message.
The sample gateway passes Microsoft Exchange Server message identifiers through the transport without converting the identifiers into special attributes. It passes these identifiers in the X-Message-ID and X-Message-Subject-ID header fields.
The sample gateway writes information for the PR_TRACE_INFO property whenever a message passes through it. The PR_TRACE_INFO property is discussed in Message Transfer.
The external trace information is saved in the External-Received-By, External-Received-At, External-Attempted-By, and External-Deferred-At header fields as shown in the message example in XLATDRIV: Translating Messages. The internal trace information found in the PR_INTERNAL_TRACE_INFO property is saved in the Internal-Received-By, Internal-Received-At, Internal-Attempted-By, and Internal-Deferred-At header fields. The external trace information is used to prevent loops in message delivery between different sites, while the internal trace information is used to prevent loops in message delivery within a site.
The sample gateway translates both inbound and outbound messages. For outbound messages, the input is an LPMESSAGE pointer to the envelope and the output is a stream on a file. This is reversed for inbound messages. Translations are supported for ENVELOPE.IPM and REPORT.IPM message classes.