[Evolution-hackers] Exchange servers breaking iCal attachments?

[Chris Higgins <higgins kavi com>]

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