3

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

  • in Outlook 2010: The email is shown, the event icon is shown but you cannot save the event to your calendar
  • in OWA: The email is not shown!
  • in Thunderbird via IMAP: The email is not shown. Instead you get a strange email with subject "Fehler beim Abrufen der folgenden Nachricht mithilfe des IMAP4-Protokolls: 1393431." (Error on fetching the following message using IMAP4-protocol).

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.

iCalendar event, based on Minimal Published Event in RFC 5546


    BEGIN:VCALENDAR
    METHOD:REQUEST
    PRODID:-//Example/ExampleCalClient//EN
    VERSION:2.0
    BEGIN:VEVENT
    ORGANIZER;CN="a":MAILTO:a@example.com
    DTSTART:19970701T200000Z
    DTSTAMP:19970611T190000Z
    SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
    UID:0981234-1234234-23@example.com
    STATUS:CONFIRMED
    END:VEVENT
    END:VCALENDAR

PHP script based on swiftmailer


    setSubject('Your subject')
    ->setFrom(array('a@example.com' => 'a'))
    ->setTo(array('b@example.com' => '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);

The resulting email


    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

  • the event is attached
  • the event is quoted-printable instead base64
  • the body is filled with text/plain and/or text/html
  • the line ending of the event file are dos (\r\n) or unix (\n)

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?

Community
  • 1
  • 1
Alexander
  • 43
  • 8
  • I find it a bit weird that you're using a multipart email, but there's only one part. Why not move the part up one level? Aside from that, I also noticed that some clients don't like this attachment base64 encoded. You could try quoted-printable or not encoded at all. – Evert Jun 02 '16 at 02:16
  • Just read your notes. Could you try to make sure that 1. There is text, 2. The iCalendar object is not encoded, 3. it has Content-Disposition: attachment, preferably also containing a filename? I imagine that those three combined will do the trick. – Evert Jun 02 '16 at 02:19
  • Thank you @Evert for your ideas. The combination of multipart/alternative body with an base64 encoded text/calendar as part (not attachement) is exactly the way, Outook sends emails. I tried to get as close as possible to this behaviour and with method=REQUEST, that's no problem at all. I tried now once more, to add a 1. text/plain part, 2. not encode the iCalendar object, 3. add it as attachment with filename ("Content-Disposition: attachment; filename=Minimal.ics"). No success :-( – Alexander Jun 02 '16 at 07:45
  • What about removing `METHOD:PUBLISH`. iTip methods are a bit weird, maybe removing it will cause outlook to see it as a true attachment, instead of an iTip message. – Evert Jun 02 '16 at 19:02
  • No change in the behaviour. Missing METHOD:PUBLISH is like setting it. If I write METHOD:SOMETHINGSTUPID the attachment is shown and renamed in "not supported calendar message.ics" and not recognized as event. – Alexander Jun 03 '16 at 08:18

0 Answers0