exchange calendar invitation broken to external exchange/office 365 servers
exchange calendar invitation broken to external exchange/office 365 servers
When we send exchange calendar invitations it is broken to other exchange/office 365 servers but it appears to be ok when sent to linux servers
below is an example of a broken calendar invite when it is received. The receiver cannot accept nor does it show up on their calendar, they only get a plain text email. It also appears if we accept an external invitation but the acceptance is broken going back to them, it shows as not accepted/no status. All other emails appear to be ok in terms of richtext/html and people receiving our attachments. We have Exchange 2010/2016. This issues has existed before 2016 was introduced. The outgoing email is smart hosted thru our Cisco ESA Appliance aka IronPort.
When we send exchange calendar invitations it is broken to other exchange/office 365 servers but it appears to be ok when sent to linux servers
below is an example of a broken calendar invite when it is received. The receiver cannot accept nor does it show up on their calendar, they only get a plain text email. It also appears if we accept an external invitation but the acceptance is broken going back to them, it shows as not accepted/no status. All other emails appear to be ok in terms of richtext/html and people receiving our attachments. We have Exchange 2010/2016. This issues has existed before 2016 was introduced. The outgoing email is smart hosted thru our Cisco ESA Appliance aka IronPort.
Hello,
To add to my earlier update since you have IRONPORT.
A normal meeting request content type should be “Content-Type: multipart/alternative;” while a plain text meeting request content type is showing “Content-Type: multipart/mixed; boundary=”===============0
1. As stated earlier TNEF value needs to set to false .
2. Try to create a new outbound connector and route the email traffic through it, so that the emails go directly with this connector and disable the gateway connector. Send a test calendar invite and it should be received normally as calendar.
3. Further troubleshooting adds Gateway must be modifying the message header type in order to show up the Disclaimer of the email correctly.
4. You need to correct the Gateway in Ironport I mean settings.
5. Also since you are using smarthost, it is possible that the smarthost considers these emails as spam and converts them to plain txt, but I'm not sure about this may be you can check with smarthost vendor and see if they have some kind of rule for these types of messages.
To add to my earlier update since you have IRONPORT.
A normal meeting request content type should be “Content-Type: multipart/alternative;” while a plain text meeting request content type is showing “Content-Type: multipart/mixed; boundary=”===============0
1. As stated earlier TNEF value needs to set to false .
2. Try to create a new outbound connector and route the email traffic through it, so that the emails go directly with this connector and disable the gateway connector. Send a test calendar invite and it should be received normally as calendar.
3. Further troubleshooting adds Gateway must be modifying the message header type in order to show up the Disclaimer of the email correctly.
4. You need to correct the Gateway in Ironport I mean settings.
5. Also since you are using smarthost, it is possible that the smarthost considers these emails as spam and converts them to plain txt, but I'm not sure about this may be you can check with smarthost vendor and see if they have some kind of rule for these types of messages.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
On exchange server Get-RemoteDomain | Where {$_.TNEFEnabled -ne $false}
For each Remote domain, run the following command:
Set-RemoteDomain -Identity DomainName -TNEFEnabled $false
On exchange 2010 run command: Get-RemoteDomain | fl
The ContentType should be set either to MimeHtml
For domains that have the default content type set to MimeText, you need to change the ContentType property via the cmdlet below:
Set-RemoteDomain -Identity <name> -ContentType <type>