Replies to meeting request are showing as Tentative when they have been address rewritten
Symptom
===========
When sending replies to meeting request these are showing as Tentative when they have been address rewritten. In these instances for example we go from x_y@contoso.com and get rewritten to x.y@contoso.com by a third party, when the response is received it’s Tentative, even if it was Accepted
Cause
===========
We have seen this issue before in a very small amount of cases, pipeline tracing has shown that this is because Exchange uses a mixture of P1 and P2 headers along with the ICS information in the mail in base64 encoding to match up the recipients, doing address rewrite breaks this.
As mentioned the testing and the research has shown that the mismatch of SMTP headers and ICS body is causing this.
Resolution
============
The attendee is showing as Tentative because the P1 and P2 SMTP header information does not match with the contents of the ICS Calendar information in the body of the message, Exchange uses these to correlate recipients and attendees to meetings etc. By performing address rewrite when the message has left Exchange we are breaking this link.
Additional Information
==================
Accepted Meeting Invite shows up as 'Tentative'
Currently you have a domain rewrite to rewrite your domain from internal addresses to an external addresses. However, under certain scenarios when sending Meeting Requests or Accepting Requests the email domain is not rewritten causing incorrect display of the response. This behavior is by design and it is actually a limitation of the application rewriting the domain. SMTP MIME messages have 2 sets of properties, commonly refer to P1 and P2. The P1 properties are transport level properties that are passed from the sending server to the receiving sender via the SMTP Protocol. The P2 properties are message level properties which are passed as part of the message. Both of these property sets contain recipient and sender information, including email addresses. In your scenario the rewriting application is able to change these properties correctly to ensure that the internal domain is rewritten to the external domain.
In addition to the P1 and P2, the message may also have different body parts that contain additional information. When sending Meeting Requests, Exchange uses an iCal body part (<https://www.ietf.org/rfc/rfc2445.txt>) to describe the detail of the message and it is included in the message body. This is a widely used method for transmitting Scheduling events. This attachment contains all the information regarding the meeting request. The problem is that the rewrite tool only looks at the P1 and P2 headers and not at the body of the message. The receiving client will then use the iCal body part to gather all the information for Meeting Request, which contains the original internal domain.
During my testing I was able to decode the base64 encoded iCal information and make the domain changes to the iCal properties and the P2 headers. I encoded the iCal to base64 again and put the data back into the message. After doing this in both directions (incoming and outgoing) I did not see any of the issue with Tentative or incorrect addresses. It may or may not be difficult to have your Domain rewrite application do this, but that is where the problem is happening.
Using Rich Text Format for these messages is another workaround for this problem. When Exchange uses Rich Text Format to send a Meeting Request, it encapsulates the message using TNEF. During the encapsulation of a Meeting request, the Organizer and Attendee are actually mapped and stored in the From: and To: field respectively in the P2 header. When the message is sent the Rewrite tool is able to change the P2 header. The receiving server then rebuilds the message back and uses the P2 sender and recipient information to recreate the meeting request in addition to the information in the TNEF message body.
Please note that TNEF will only work between Exchange servers, since it is a proprietary format used by Exchange and other Microsoft Products. Non-Outlook clients will see the TNEF format as a winmail.dat attachment and the may cause other issues.