Custom MAPI transport providers may not function in Outlook 2003 and in Outlook 2002 (304116)


The information in this article applies to:

  • Microsoft Office Outlook 2003
  • Microsoft Outlook 2002
This article was previously published under Q304116

SYMPTOMS

Transport providers that call the IMAPISupport::SpoolerNotify method to specify the NOTIFY_SENTDEFERRED flag that is running on a computer that has Microsoft Outlook 2002 or Microsoft Office Outlook 2003 installed, may receive a Non-Delivery Reports (NDR) and the messages for that transport are not sent.

Additionally, transport providers that implement functions that result in calls to the MAPI Spooler experience unexpected behaviors or the loss of functionality. The following is a list that contains the application programming interfaces (APIs) that are affected, but the list is not limited to these APIs:

  • IXPLogon::EndMessage
  • IMAPISupport::CompleteMsg
  • IMAPISupport::ModifyStatusRow
  • IMAPISupport::SpoolerNotify
  • IMAPISupport::StoreLogoffTransports
  • IMAPISupport::SpoolerYield
  • IMAPISupport::StatusRecips
  • IMAPIStatus::FlushQueues
  • IMAPISession::EnumAdrTypes - Instead of returning a list of address types supported by the various transport providers in the profile, it returns NULL.
  • IMAPISession::QueryDefaultMessageOpt
  • IMAPISession::QueryDefaultRecipOpt
  • PreprocessMessage
  • RemovePreprocessInfo


  • The following list includes other symptoms:

  • The following list includes other symptoms:Returning from IXPLogin::EndMessage(...) with END_DONT_RESEND set does not have the desired effect.
  • The following list includes other symptoms:The MAPI Spooler notification does not work (calling IMAPISupport::SpoolerNotify(NOTIFY_NEW_MAIL...) does not do anything).
  • The following list includes other symptoms:Calling IMAPISupport::ModifyStatusRow(...) with the STATUS_OUTBOUND_FLUSH bit set does not do anything.
  • The following list includes other symptoms:NDRs are not generated when the Microsoft Exchange Server store is used instead of personal folder (.pst) files (calling IMAPISupport::StatusRecips(...) fails).
  • The following list includes other symptoms:MAPI Spooler calls the transport provider for address types that were not advertised with IXPLogon::AddressTypes(...).
  • The following list includes other symptoms:IMAPISession::MessageOptions always returns MAPI_E_NOT_FOUND.

CAUSE

Outlook 2002 and Outlook 2003 have redesigned the use of the MAPI Spooler. The Mapisp32.exe file process is no longer used in Outlook 2002 and in Outlook 2003. With the new design, the Outlook Protocol Manager (OPM) calls the MAPI Protocol Handler (MPH), which calls each of the MAPI transports as needed. If the MAPI transport registers that it can handle a specific type of message, such as the FAX message type that is written by a third-party software company, the transport is responsible for sending that message and setting the PR_RESPONSIBILITY flag to TRUE, or an NDR is produced.

The behavior occurs if the transport does not mark the recipients as handled before it returns to the MAPI Spooler that the message was deferred from. Not marking the recipients as handled has always caused issues. However, the MAPI Spooler allows the behavior because no other transports will handle the recipient type in question, and because it does not consider the message finished until the deferred message is actually sent. Deferred messages are sent if the transport calls back on the spooler notify or if another message that required a legacy transport is sent. Calling send and receive without messages to send does not cause the OPM to send the deferred message because the transport does not indicate that it was ready.

There is not a way for the transport to programmatically control the Send/Receive function with the new design in Outlook 2002 and in Outlook 2003 because the OPM is in control of this functionality.

RESOLUTION

To resolve this behavior, developers of transport providers need to redesign their providers prior to upgrading their customers to Outlook 2002 or to Outlook 2003.

WORKAROUND

In relation to the IMAPISupport::SpoolerNotify method, the transport provider needs to rework the logic to account for the new design. To process messages, the transport must deliver the message when it receives them, set the PR_RESPONSIBILITY flag to TRUE, and return to the MPH.

Work arounds for the loss of functionality may not exist for the other transport APIs and are currently unavailable.

STATUS

This behavior is by design. All MSDN documentation that references or describes the MAPI Spooler should be considered obsolete in the context of Outlook 2002 and of Outlook 2003. Developers of transport providers should reconsider their products functionality and feature set.
Modification Type:MinorLast Reviewed:3/10/2006
Keywords:kbnofix kbprb KB304116
©2004 Microsoft Corporation. All rights reserved.