Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to MAPI.
Nothing was collected or created yet.
from Wikipedia
Messaging Application Programming Interface (MAPI) is an API for Microsoft Windows which allows programs to become email-aware. While MAPI is designed to be independent of the protocol, it is usually used to communicate with Microsoft Exchange Server.[1]
Details
[edit]MAPI uses functions loosely based on the X.400 XAPIA standard. It includes facilities to access message transports, message stores, and directories.
While Simple MAPI (SMAPI) is a subset of 12 functions which enable developers to add basic messaging functionality, Extended MAPI (EMAPI) allows complete control over the messaging system on the client computer. This includes creation and management of messages, plus management of the client mailbox, and service providers.
Simple MAPI is included with Microsoft Windows as part of Outlook Express/Windows Mail while the full Extended MAPI is included with Microsoft Outlook and Exchange.
In addition to the Extended MAPI client interface, programming calls can be made indirectly through the Simple MAPI API client interface, through the Common Messaging Calls (CMC) API client interface, or by the object-based CDO Library interface. These three methods are easier to use and designed for less complex messaging-enabled and -aware applications. (Simple MAPI and CMC were removed from Exchange 2003.)
MAPI was originally designed by Microsoft. The company founded its MS Mail team in 1987, but it was not until it acquired Consumers Software in 1991 to obtain Network Courier that it had a messaging product. Reworked, it was sold as MS PC Mail (or Microsoft Mail for PC Networking). The basic API to MS PC Mail was later known as MAPI version 0 (or MAPI0), to differentiate it from "true" MAPI.
Service provider interface
[edit]The full Extended MAPI interface is required for interfacing messaging-based services to client applications such as Outlook. For example, several non-Microsoft e-mail server product vendors created "MAPI service providers" to allow their products to be accessed via Outlook. Notable examples include Axigen Mail Server, Kerio Connect, Scalix, Zimbra, HP OpenMail, IBM Lotus Notes, Zarafa/Kopano, and Bynari.
MAPI also had a service provider interface of sorts. Microsoft used this to interface MS Mail to an email system based on Xenix, for internal use.
Extended MAPI is the main e-mail data access method used by Outlook, to interface to Microsoft Exchange, via MAPI service providers shipped with Outlook.
MAPI/RPC protocol details
[edit]Microsoft has released full details of the MAPI/RPC protocol since August 2007.[2]
"MAPI protocol" is a colloquial name for the MAPI/RPC. At times, Microsoft has also called it "Exchange RPC" and "Outlook-Exchange Transport Protocol".
Microsoft provides a sample MAPI/RPC-based application called MFCMAPI[3] to assist developers. It is also widely used as a diagnostics tool by both developers and Microsoft Exchange administrators.
MAPI over HTTP
[edit]The original implementation was designed for use on a local network, or LAN.
With Exchange 2003 and Outlook 2010, Microsoft introduced RPC over HTTP (later renamed Outlook Anywhere) as a way to Exchange over the internet.[4]
In 2014, Exchange 2013 SP1 introduced another variant, this time with a more "normal" HTTP-based stack known as "MAPI over HTTP".[5]
Incompatibility with Internet Mail
[edit]The Simple Mail Transfer Protocol has always supported the concept of mail with multiple authors, and distinguishes between the "sender" and "authors" whenever there is more than one of the latter. MAPI cannot represent separate authors and senders except through the delegation mechanism, which does not permit more than one author. Thus MAPI cannot accurately transmit group letters from scientific communities to legislators, or presentation of group research via email, or similar scenarios. When fully SMTP compliant mailers (e.g. Thunderbird) send perfectly formed SMTP messages with multiple authors into MAPI-dependent email infrastructures (such as Exchange/Outlook, O365, or Outlook.com) the messages must have their information density reduced to fit MAPI, presenting challenges for authentication and anti-spoofing technologies that rely on accurate message metadata transmission, and fundamentally changing messages to be something other than what was originally sent. Although the security implications impact all users, inability to represent multiple authorship is generally of little concern in purely hierarchical settings such as traditional businesses and military organizations, primarily impacting legislative and academic institutions.
Reimplementations
[edit]Several open-source software projects have started working on implementing MAPI libraries, including:
- Grommunio/Gromox has C++20 implementations of MAPI/RPC and MAPI/HTTP servers.
- The OpenMapi project (now demised)[6] had a C# implementation.
- Kopano Groupware Core has a C++2011 implementation called "mapi4linux" (continuation of the same from Zarafa), which offers an API that is source-backwards-compatible with the Messaging API (code written for M4L also build with the Windows SDK). Kopano GWC comes with a connector for the Zarafa/Kopano-based SOAP/HTTP transport.
- OpenChange has a "libmapi" component written in C that only partially resembles MAPI. (Lacks interfaces like IMsgStore, the OpenEntry function.)
- The OpenChange subproject Evolution-MAPI is a connector for Exchange implementing the MAPI/RPC transport.
- The GNOME Evolution project develops evolution-ews, which has implemented much of MAPI.[7]
References
[edit]- ^ "MAPI over HTTP in Exchange 2016". Microsoft TechNet. 2016-12-20.
- ^ Exchange Server Protocols. Msdn.microsoft.com. Retrieved on 2013-07-17.
- ^ Mfcmapi - Home. https://github.com/stephenegriffin/mfcmapi. Retrieved on 2017-07-26.
- ^ "Exchange Server 2003 RPC over HTTP Deployment Scenarios". 2014-12-22. Archived from the original on 2014-12-22. Retrieved 2014-12-22.
- ^ "Outlook Connectivity with MAPI over HTTP". You Had Me At EHLO…. Microsoft. Archived from the original on 2019-04-20. Retrieved 20 April 2019.
- ^ openmapi.org used to host the downloads; it no longer exists
- ^ "EWS Operations Features' Parity Matrix". Retrieved 17 December 2018.
External links
[edit]- Messaging API at MSDN Library
- OpenChange project - details of MAPI protocol and tools for exploring MAPI protocol
- OpenMapi project - Open Source, multi-language MAPI implementation which can connect to other groupware sources, with API documentation
- Messaging API Archived User Forum
- Enabling Outlook Connector logging for support
from Grokipedia
Messaging Application Programming Interface (MAPI) is a set of application programming interfaces developed by Microsoft for the Windows operating system, enabling mail-enabled and mail-aware applications to create, manipulate, transfer, and store email messages and other messaging data through a unified interface independent of the underlying messaging systems.[1] It provides developers with functions to manage mailboxes, address books, and message services, facilitating integration with various email protocols and providers.[2]
Originally introduced in the early 1990s as part of Microsoft Mail (MS-Mail), MAPI served as the foundational API for programmable access to email features in early Microsoft messaging products.[3] By 1992, it became integral to the development of Microsoft Exchange Server and the client application that evolved into Microsoft Outlook, establishing MAPI as the core interface for data access in Microsoft's mail systems.[3] Over the decades, MAPI has evolved to support modern protocols, including MAPI over HTTP, which enhances the reliability and stability of connections between Outlook clients and Exchange servers.[4]
MAPI's architecture consists of two primary variants: Simple MAPI, which offers basic messaging functions like sending mail for simpler Windows applications, and Extended MAPI (or Full MAPI), a more comprehensive COM-based API for advanced applications requiring full control over messaging operations, such as custom Outlook add-ins or service providers.[1] Key components include client-side libraries for application development, server-side implementations for Exchange, and protocol layers like MAPI/RPC (legacy) and MAPI over HTTP (current standard).[4] This layered design allows MAPI to abstract complex messaging tasks, supporting features like profile management, message composition, and attachment handling across diverse environments.[2]
In contemporary Microsoft ecosystems, MAPI remains essential for Outlook's connectivity to Exchange Server and Exchange Online, powering email synchronization, calendar sharing, and collaborative features in enterprise settings.[4] As of 2025, MAPI over HTTP continues to be the recommended transport protocol for improved performance and security, with ongoing support in classic Outlook versions, though the newer web-based Outlook for Windows limits some MAPI automation capabilities.[5] Developers leverage MAPI through the Windows SDK and Outlook API references to build robust messaging solutions, ensuring compatibility with Microsoft's evolving cloud infrastructure.[6]
This sets MAPI over HTTP as the default for all mailboxes, with options to configure virtual directories (e.g., via
Introduction
Definition and Purpose
MAPI, or Messaging Application Programming Interface, is a Microsoft Windows API designed to enable the development of email-aware and mail-enabled applications.[2] It provides a set of functions and interfaces that allow applications to create, manipulate, transfer, and store mail messages, thereby facilitating interaction with various messaging systems.[2] The primary purpose of MAPI is to grant programs access to message stores, transport providers, and directory services, empowering developers to control core messaging operations such as sending and receiving emails, managing contacts, and scheduling appointments.[7] This architecture supports seamless integration with Microsoft Exchange Server, enabling robust handling of email, calendaring, and collaboration features in enterprise environments.[8] MAPI's design emphasizes modularity through service providers, which extend functionality for specific messaging components without delving into their implementation details.[7] MAPI exists in two main variants: Simple MAPI and Extended MAPI. Simple MAPI offers a lightweight subset of 12 functions for basic tasks, such as composing and sending simple messages, making it suitable for straightforward integration in applications like those using Windows Mail.[1] In contrast, Extended MAPI—often simply referred to as MAPI—provides a comprehensive, object-based interface for advanced control over messaging systems, including detailed property manipulation and multi-user support.[1] Key use cases for MAPI include its central role in Microsoft Outlook, where it powers client-side messaging applications through a rich set of interfaces and data types.[6] It also enables third-party tools to integrate with Exchange for features like shared mailboxes and directory access, supporting collaborative workflows in business settings.[8] Overall, MAPI incorporates support for industry standards such as X.400 to promote interoperability across messaging systems.[7]History
The development of the Messaging Application Programming Interface (MAPI) began in the late 1980s as part of Microsoft's efforts to create a standardized way for applications to interact with messaging systems. In 1987, Microsoft established its MS Mail team to focus on PC-based email solutions, laying the groundwork for what would become MAPI.[9] This initial work targeted local area network email for personal computers, emphasizing integration with Windows environments. A pivotal milestone occurred in 1991 when Microsoft acquired the assets of Consumers Software Inc., including the Network Courier product line for PC networks.[10] This acquisition enhanced Microsoft's PC Mail offerings and led to the introduction of MAPI version 0, a basic API designed to enable simple email functionality across applications.[9] The enhancements from Network Courier provided the foundation for more robust messaging capabilities, shifting focus from standalone email to programmable interfaces. By the early 1990s, MAPI evolved into a full-featured system with the development of Extended MAPI, which offered advanced object-based programming for complex messaging tasks.[11] This version integrated deeply with Windows operating systems and Microsoft Exchange Server, supporting industry standards like X.400 for improved interoperability in messaging transports, stores, and directories.[7] Extended MAPI emphasized scalability and extensibility, allowing developers to build mail-enabled applications with support for calendaring, contacts, and groupware features. Key product integrations marked further evolution, with MAPI becoming central to Microsoft Outlook and Exchange Server starting with the 1997 releases. Outlook 97 leveraged Extended MAPI as its primary interface for Exchange connectivity, enabling seamless client-server communication. In August 2007, Microsoft publicly released detailed specifications for the MAPI/RPC protocol as part of its Open Specifications program, promoting broader interoperability and third-party development. This disclosure included protocol documentation for remote procedure calls over RPC, facilitating access to Exchange data stores. Significant milestones included the transition away from earlier standards like Common Messaging Calls (CMC), an X.400-derived API, which was fully removed from Exchange Server in 2003 to streamline support for MAPI. By 2014, Microsoft introduced MAPI over HTTP with Exchange Server 2013 SP1, replacing older RPC-based transports with a more efficient, web-friendly protocol that improved Outlook connectivity over the internet while maintaining backward compatibility where possible. As of 2025, MAPI remains integral to Outlook and Exchange, with MAPI over HTTP as the primary protocol for enhanced performance and security.[4] These advancements reflected MAPI's ongoing adaptation to modern networking demands and its enduring role in Microsoft's messaging ecosystem.Architecture and Components
Core Components
The Messaging Application Programming Interface (MAPI) employs a modular architecture that separates the common user interface from the underlying programming interfaces, enabling developers to build messaging applications with consistent user experiences across diverse systems. This design includes a set of dialog boxes in the common user interface for standard operations like composing messages or selecting recipients, while the programming interfaces provide the foundational APIs for accessing messaging functionality. At its core, MAPI adopts an object-based model inspired by the Component Object Model (COM), featuring primary objects such as the MAPI session for overall client management, the message store for handling folders and messages, the address book for recipient information, and transport objects for message delivery mechanisms.[12][13] Key interfaces form the backbone of this object model, ensuring interoperability and extensibility. The IUnknown interface serves as the base for all MAPI objects, facilitating COM integration by providing methods for querying supported interfaces, adding references, and releasing objects. The IMAPISession interface is essential for initializing and managing a client's MAPI session, including logon operations, access to providers, and session-wide notifications. For message storage, the IMsgStore interface allows opening and manipulating message stores, supporting operations like creating folders, submitting messages, and querying contents. Similarly, the IABProvider interface enables interaction with address book providers, offering functions to resolve names, retrieve distribution lists, and manage container hierarchies. These interfaces collectively ensure that MAPI applications can navigate and manipulate messaging data in a structured manner.[14][15] MAPI relies on specific data structures to represent and exchange information efficiently. Properties, which encapsulate metadata for objects like messages or attachments, are identified and accessed via SPropTagArray, an array structure that tags properties with unique identifiers combining type, identifier, and optional multi-value flags. For handling larger or unstructured data, such as email attachments or embedded message content, MAPI uses binary large objects (BLOBs), which store raw binary data in a flexible format that supports streaming and partial access to avoid memory overhead. These structures promote a property-centric approach, where nearly all MAPI elements are defined by their properties, enabling uniform handling across different providers.[16][14] Supporting subsystems enhance MAPI's robustness and responsiveness. Profile management allows administrators and users to configure messaging profiles that aggregate multiple service providers, such as email accounts and address books, into a single logon context for seamless access. The spooling subsystem queues outgoing messages, managing submission to transport providers and handling retries for undeliverable items to ensure reliable delivery. The notification system, powered by advise sinks and event callbacks, informs clients of changes like new arrivals or deletions without constant polling, using the IMAPISession::Advise method to register interests in specific objects or scopes. These subsystems operate beneath the object layer, providing essential services for asynchronous and multi-provider environments.[17][13][18] Integration layers extend MAPI's accessibility for different development needs. Simple MAPI functions as a lightweight subset that wraps calls to the full Extended MAPI, offering simplified functions likeMAPILogon for basic email operations suitable for legacy or resource-constrained applications. Additionally, Collaboration Data Objects (CDO) build on MAPI as a higher-level abstraction, providing object models like CDO.Message for easier scripting and web-based integrations without direct exposure to low-level interfaces. This layered approach allows developers to choose the appropriate complexity level while maintaining compatibility with the core MAPI infrastructure.[13]
Service Provider Interface
The Messaging Application Programming Interface (MAPI) Service Provider Interface (SPI) enables the extensibility of MAPI by allowing developers to create custom components that connect client applications, such as Microsoft Outlook, to diverse messaging systems without modifying the core client code.[19] These service providers function as modular drivers, abstracting the underlying messaging infrastructure and supporting a pluggable architecture that integrates with various backends, including proprietary servers and databases.[20] By implementing standardized interfaces, providers ensure compatibility with MAPI's object model, facilitating features like message creation, addressing, storage, and transmission.[21] MAPI defines three primary types of service providers to handle distinct aspects of messaging. Transport providers manage the submission and retrieval of messages, queuing them for delivery and handling transmission protocols on behalf of the client.[20] Store providers oversee message storage and retrieval, presenting data in hierarchical folders using mechanisms like Personal Storage Table (PST) or Offline Storage Table (OST) files, or connecting to server-based databases.[19] Address book providers supply directory services for recipient resolution, supporting corporate directories or external services to validate and expand addresses.[20] Service providers must adhere to specific interface requirements based on Component Object Model (COM) standards, inheriting from IUnknown for interoperability. They typically implement core interfaces such as IProviderAdmin for administrative tasks like profile management and shutdown handling, and provider-specific ones like IMsgStore for store providers to manage properties, folders, and messages via the IMAPIProp base interface.[21] Additional requirements include registering unique identifiers with IMAPISupport::SetProviderUID, supporting hierarchy and contents tables for navigation, event notifications for changes, and progress indicators for user feedback.[20] Transport providers, for instance, implement IXPLogon to declare address types and manage delivery status.[20] Prominent examples include Microsoft's Exchange service provider, which integrates Outlook with Exchange Server by providing all three provider types for seamless email, calendar, and contact management.[19] For third-party integrations, the Kerio Outlook Connector implements message store and transport providers to enable native MAPI access to Kerio Connect servers, allowing Outlook users to connect without additional bridges while leveraging the default address book.[22] Development of MAPI service providers involves using official MAPI header files, such as Mapidefs.h for definitions and Mapiguid.h for GUIDs, along with the MAPI stub library for building 32-bit and 64-bit applications.[23] Tools like MFCMAPI, an open-source utility, serve as a reference implementation and testing framework, enabling developers to inspect MAPI stores, simulate provider interactions, and debug implementations directly through Outlook profiles.[24] This provider model benefits Outlook compatibility by permitting diverse backend systems to appear uniformly to the client, reducing development overhead and enabling features like offline access and unified inboxes across custom messaging environments.[7] Providers extend core MAPI objects, such as IMsgStore, to customize behavior while maintaining adherence to the interface contract.[21]Communication Protocols
MAPI/RPC
MAPI/RPC, also known as Exchange RPC, is a remote procedure call protocol that facilitates client-server communication in the Messaging Application Programming Interface (MAPI) environment, primarily for accessing mailbox and public folder data in Microsoft Exchange Server. It employs Remote Procedure Calls (RPC) over TCP/IP to transmit Remote Operations (ROPs), which are tokenized binary requests and responses exchanged between clients like Microsoft Outlook and the Exchange server. This protocol establishes a session context for ongoing interactions, enabling operations such as message retrieval, folder management, and address book queries through the EMSMDB interface.[25] The mechanics of MAPI/RPC involve client-side stubs that generate RPC calls to invoke server-side functions, abstracting the underlying network transport. Clients initiate a connection by binding to the server's RPC endpoint mapper on TCP port 135, which dynamically assigns subsequent ports (typically in the range 49152-65535) for the actual RPC communication. Once connected, the client issues ROPs via the synchronous EMSMDB interface for immediate operations or the asynchronous AsyncEMSMDB interface for notifications like new mail events; responses are returned as byte arrays containing status codes, data, or errors. This supports both blocking (synchronous) and non-blocking (asynchronous) modes, with optional compression using the LZ77 algorithm to optimize bandwidth.[25][26][27] The protocol's technical details were publicly released by Microsoft in August 2007 as part of the Open Specifications for Exchange Server protocols, enabling third-party interoperability. It served as the primary transport for Outlook-Exchange connectivity from early versions through Exchange Server 2010 and into Exchange 2013, where it began transitioning to successors like MAPI over HTTP for improved firewall compatibility. As of 2025, direct MAPI/RPC is legacy and supported only in older configurations, such as Exchange 2010 SP3 with compatible Outlook versions.[28][4] Tools such as MFCMAPI, a Microsoft-provided sample application, allow developers and administrators to debug RPC interactions by simulating client calls, inspecting ROP buffers, and logging MAPI function invocations. Microsoft also offers sample code in the MAPI documentation to illustrate RPC stub generation and ROP handling.[29][30] Security in MAPI/RPC relies on Windows authentication mechanisms, including NTLM for challenge-response authentication and Kerberos for ticket-based access, integrated with the RPC security context to encrypt sessions via SSL/TLS when configured. However, its use of dynamic ports and direct TCP connections posed challenges for firewall traversal, often necessitating RPC over HTTP as a workaround before the protocol's deprecation in favor of more secure, HTTP-native alternatives.[25][27]MAPI over HTTP
MAPI over HTTP is a transport protocol introduced with Exchange Server 2013 Service Pack 1 in February 2014, designed to enhance the reliability and stability of connections between Microsoft Outlook clients and Exchange servers by leveraging HTTP for communication.[31] It serves as the successor to RPC over HTTP (also known as Outlook Anywhere), particularly for internet-facing scenarios, allowing Outlook to connect more efficiently over the web without requiring custom firewall ports.[31] This protocol extends the Messaging Application Programming Interface (MAPI) to use standard HTTP methods, enabling better error visibility, pause-and-resume functionality during network interruptions, and faster reconnections after events like hibernation or network switches.[4] At its core, MAPI over HTTP operates over HTTP or HTTPS as the transport layer, separating key functions into distinct endpoints: the NSPI endpoint handles address book queries, while the RopProxy endpoint manages data operations such as email retrieval and manipulation.[32] The protocol supports data compression to optimize bandwidth usage during transfers and accommodates authentication via methods including OAuth and NTLM, facilitating secure access in both on-premises and cloud environments.[32] These features build on the original RPC-based MAPI by adapting it to modern web standards, reducing dependency on legacy tunneling mechanisms. Key advantages of MAPI over HTTP include improved compatibility with firewalls, as it relies on standard HTTP/HTTPS ports (80 and 443), and reduced latency in wide-area network (WAN) scenarios through maintained session context and quicker recovery from disruptions.[4] It became the required protocol for new connections in Exchange Online after the deprecation of RPC over HTTP on October 31, 2017, positioning it as the preferred method for Outlook clients accessing cloud-based mailboxes.[33] Implementation occurs on the client side with Outlook 2013 Service Pack 1 and later versions, as well as Outlook 2010 Service Pack 2 with specific updates (KB2956191 and KB2965295 from April 2015), while server-side support begins with Exchange 2013 SP1 and extended to Exchange 2016 and 2019 (end of support October 14, 2025), and continues with Subscription Edition.[31][34] Administrators enable it organization-wide using PowerShell commands, such as:Set-OrganizationConfig -MapiHttpEnabled $true
Set-OrganizationConfig -MapiHttpEnabled $true
Set-MapiVirtualDirectory) for internal and external URLs and authentication methods like Negotiate.[35] Mailbox-level control is available through Set-CasMailbox -MapiHttpEnabled $true for specific users.[35]
In the context of ongoing evolution, RPC over HTTP was fully deprecated in Exchange Online on October 31, 2017, solidifying MAPI over HTTP as the standard for Outlook connectivity in modern Exchange deployments.[33]