Reputation: 43
We send calendar events in iCalendar format to our customers after subscribing or unsubscribing to an event.
The iCalendar content is attached as file AND embedded inline in the email. With embedding, Outlook 2010 used to show the event and offered to import it you calendar. Thunderbird / Lightning works perfectly the same.
We use the method=PUBLISH as specified in RFC 5546 - 3.2.1. We don't want the customers to "Accept" or "Decline" the event as it is already confirmed by the booking system. This could be done with method=REQUEST.
This worked as intended as long we used Exchange 2007. With Exchange 2013 we have odd behaviour
Doing so with the method=REQUEST, everything seems to be fine even for Outlook.
I downstripped our setup to find a solution. Now I have no idea anymore.
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalClient//EN VERSION:2.0 BEGIN:VEVENT ORGANIZER;CN="a":MAILTO:[email protected] DTSTART:19970701T200000Z DTSTAMP:19970611T190000Z SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES UID:[email protected] STATUS:CONFIRMED END:VEVENT END:VCALENDAR
setSubject('Your subject') ->setFrom(array('[email protected]' => 'a')) ->setTo(array('[email protected]' => 'b')) //->attach(Swift_Attachment::fromPath('Minimal.ics')) ; // include as inline part $part = \Swift_MimePart::newInstance() ->setEncoder(\Swift_Encoding::getBase64Encoding()) ->setContentType('text/calendar; method=PUBLISH') ->setBody(file_get_contents('Minimal.ics')); $message->attach($part); $transport = Swift_SmtpTransport::newInstance('localhost', 25); // Create the Mailer using your created Transport $mailer = Swift_Mailer::newInstance($transport); $mailer->send($message);
Return-Path: [...] Message-ID: Date: Wed, 01 Jun 2016 16:29:34 +0000 Subject: Your subject From: a To: b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_=_swift_v4_1464798574_0bd8d119cc81344afaa03879bf961d51_=_" --_=_swift_v4_1464798574_0bd8d119cc81344afaa03879bf961d51_=_ Content-Type: text/calendar; method=PUBLISH; charset=utf-8 Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOi0vL0V4YW1wbGUvRXhhbXBs ZUNhbENsaWVudC8vRU4NClZFUlNJT046Mi4wDQpCRUdJTjpWRVZFTlQNCk9SR0FOSVpFUjtDTj0i QWxleGFuZGVyIEJpZ2dhIjpNQUlMVE86QWxleGFuZGVyLkJpZ2dhQHNsdWItZHJlc2Rlbi5kZQ0K RFRTVEFSVDoxOTk3MDcwMVQyMDAwMDBaDQpEVFNUQU1QOjE5OTcwNjExVDE5MDAwMFoNClNVTU1B Ulk6U1QuIFBBVUwgU0FJTlRTIC1WUy0gRFVMVVRILVNVUEVSSU9SIERVS0VTDQpVSUQ6MDk4MTIz NC0xMjM0MjM0LTIzQGV4YW1wbGUuY29tDQpTVEFUVVM6Q09ORklSTUVEDQpFTkQ6VkVWRU5UDQpF TkQ6VkNBTEVOREFSDQo= --_=_swift_v4_1464798574_0bd8d119cc81344afaa03879bf961d51_=_--
The behaviour doesn't change, if
Thunderbird / Lightning and Googlemail both are working as expected.
So, what's wrong with this? Or is this a known behaviour of Exchange 2013 / Outlook 2010? Or who is the devil in this case?
Upvotes: 3
Views: 1825