Microsoft APIs which send meeting invitations start their work at the mailbox calendar of the meeting organizer and do not work directly against SMTP servers. These APIs provide many benefits and some drawbacks. There is no Microsoft API which sends meeting invitations by SMTP directly. For a service application Outlook Object Model (OOM) would be a very bad choice since it cannot be used in a service, on a background thread and needs to run in a user session; however, it works very well for most user session usages. EWS is an all-around good Exchange API to use for calendaring. REST and graph are newer than EWS, but not as flushed-out. REST can run on 2013 and later servers. Graph is only for Exchange Online at this time.
Some of the benefits are:
These are Microsoft APIs and fully supported.
There are a lot of sample and information on creating meeting invitations.
Exchange, Outlook, OWA, etc. should work properly with meeting invitations created by these APIs.
Note: An orphaned calendar item is one from meeting request where it has no corresponding entry in the organizer's calendar. It would only be orphaned if the organizer's calendar item is delete by something. That organizer calendar item is important since its used in the lifecycle of meeting items. Meeting invites get added to the organizer's calendars, Invitations tied to it are sent to attendees, the attendees accept, and the calendar item is added to their calendar and an update is sent back to the organizer's mailbox so that Outlook/Exchange can update the attendees calendar. Later the organizer may change something on the meeting and the cycle of updates and acceptance/rejection is done again. Calendaring for a meeting is like a living thing. In contrast ending an invite by an SMTP has no calendar item in the organizer's calendar – it's a one-shot fire-and-forget operation and in the end the calendar item in the attendee's calendar is orphaned.
Code sending invites using Outlook and Exchange items can save a copy in the sent items folder; however, this is not possible with our SMTP APIs since they don't access mailboxes.
Since meting invitations would be going through Exchange Transport (if Exchange is involved), the traffic is subject to Exchange throttling. There are send rate limits which would kick-in for high volume email blasts. Throttling for Exchange is geared to users and not servicing mass mailing.
Exchange transport is not going to be as fast as using a pure SMTP server. It's possible to send a lot of messages such as meeting requests, however the speed is not going to match that of a pure SMTP service.
How to: Programmatically Create a Meeting Request
MeetingItem Object (Outlook)
Working with Calendar Items
Outlook Object Model Overview
The code using this API needs to run on a machine with Outlook installed. OOM is not supported under a service – it Needs to run in a user session. It is not supported in a background thread.
EWS (Exchange 2007 and later):
How to: Create appointments and meetings by using EWS in Exchange 2013
About: Exchange Web Services (EWS) – Getting started with EWS
EWS Managed API
EWS Java API – The story gets better… Open Source!!!
EWS JAVA API
Getting Started Guide
Please note that there is no support for the JAVA Managed API, however we can provide support for it's over the wire traffic.
REST (Exchange on-premise 2013 and later (needs to be configured) and Exchange Online:
Office 365 REST APIs for mail, calendars, and contacts
Graph (Exchange Online):
Outlook calendar API overview
EWS is the most flexible, flushed-out and can be run from anywhere where you can reach its URL by a POST. Graph is the API emphasized to use for new development. All Exchange APIs go through the same transport mechanism.
APIs which send directly to an SMTP are not coded to supported calendaring and thus are not supported for calendaring. We don't support working with custom MIME or custom VCalendar content unless one of our APIs creates such content.
About: SMTP Sending APIs
Articles on supportability:
Building VCALENDAR content without an Microsoft API is not supported by MS.
Developer support limitations for public protocols
Exchange Protocol documents to look at for info on the subject:
Tools for troubleshooting:
There is a MIME parser in EWS Editor - it's on the Tools menu. It uses CDOSYS to parse the MIME. It uses CDOSYS to parse the MIME and can show you each body part separately and related properties. If this fails to parse MIME then there is likely something wrong with the MIME.
It's important to read-up on the throttling limits and on back pressure related to the version of Exchange you are going against.
Exchange Online Limits
Understanding message rate limits and throttling (2016
Understanding back pressure (2016)
Back pressure (2013)
Understanding Back Pressure (2010)
Message size limits in Exchange 2016
Message throttling (2013)
Understanding Message Throttling (2010)
Bulk E-Mail and Daily Recipient Rate Limits