Hi all, I'm encountering an issue with sending iCal format attachments through Exchange, and I thought since you all have worked with these things quite a bit, you might have the knowledge to help me work around Exchange's strange behavior. Apologies if this is OT. I have extensively searched for info on this particular issue, but it appears to be undocumented (or at least quite well hidden).
So we have a calendaring app that sends an email announcement to users when a new event is added. We have recently added an iCal attachment to the emails, using Content-Type: text/calendar and sending the file as Base64 encoded. This works great for most recipients. However, we have discovered that Exchange (version unclear; whatever is 'latest' -- 2003?) is breaking the iCal attachments. What happens is: 1. Email arrives at Exchange server, Exchange stores it locally in its original MIME format. 2. When an Outlook client connects via MAPI (and we think via MAPI *only*, doesn't affect POP or IMAP) to retrieve the message, Exchange rewrites the attachment on the fly to create a "rich meeting request." 3. When the Outlook user receives the attachment and clicks to open it, the "rich meeting request" is broken -- it has buttons to accept/reject, but they are grayed out. User can't do anything to add the appointment to the calendar. After much testing, it appears that Exchange does this re-writing under specific circumstances: - Attachment must be sent as Content-Type: text/calendar...if it is sent as text/plain, Exchange does not recognize it and lets it go through unchanged (in which case it works...except text/calendar is the proper way to do this AFAIK). - Client must be connecting via the MAPI protocol. The core of the breakage appears to be related to the METHOD string. We are generating an iCal file containing METHOD:PUBLISH, because all we're doing is announcing an appointment (there is no free/busy scheduling or accept/decline going on here). Exchange takes this and replaces it with METHOD:REQUEST (as well as adding various other stuff, which doesn't seem real significant). I believe the issue is basically that Exchange turns it into a meeting *request* but the iCal attachment doesn't contain enough info for the user to actually accept the request (ie there is no organizer/attendee data in the iCal file). So the user ends up with a meeting request with no buttons to accept it. Note that when the user retrieves the email+attachment via POP or some other mechanism, the attachment works fine -- they double click it and get a window with the event info and a button to 'save and close.' Does anyone know what to do to get around Exchange's behavior here? Possibilities I can think of are: - Change the attachment type to text/plain...but I think this will break standards-compliant clients that are looking for text/calendar? - Change my iCal syntax in some way which will slip under Exchange's radar. Problem is I don't know what to change? I wish there was an X-MS-DONTBREAKMYICAL item in the spec. Any thoughts? Thanks for your time, and sorry for something that is not Evolution specific. However I figured you guys may have been through the same stuff. ;Chris Higgins ;Portland, OR _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
