Improve iTIP compatibility for meeting invitations and cancellations

[mfr]

Hello,

I would like to suggest an improvement for meeting invitations and cancellations sent by EspoCRM.

Currently, EspoCRM can send meeting invitations with a Meeting.ics file attached. In my tests, the sender address, SPF, DKIM and DMARC were correct, and the email itself was delivered properly.

However, Thunderbird did not recognize the message as a native calendar invitation. It treated it as a regular email with an ICS attachment. As a result, the recipient did not get native calendar actions such as Accept, Decline or Tentative.

The generated ICS content looked mostly correct. For example, invitations contained:

METHOD
UID:<event uid>
SEQUENCE:0
STATUS
ORGANIZER:MAILTO:organizer@example.com
ATTENDEE:MAILTO:participant@example.com

Cancellations contained:

METHOD
UID:<same event uid>
SEQUENCE:0
STATUS

One possible issue seems to be the MIME structure. The calendar data is currently sent as a separate attachment, for example:

Content-Type: text/calendar; name=Meeting.ics
Content-Disposition: attachment; name=Meeting.ics; filename=Meeting.ics

A working calendar invitation from another system used a structure where the text/calendar part was inside multipart/alternative:

multipart/mixed
multipart/alternative
text/plain
text/html
text/calendar; method=REQUEST
application/ics attachment

Would it be possible to improve EspoCRM’s meeting invitation emails so that they are more iTIP-compatible and recognized as native calendar invitations by clients such as Thunderbird, Outlook, Apple Calendar and Google Calendar?

Possible improvements could include:

• adding method=REQUEST or method=CANCEL to the text/calendar MIME part
• embedding the text/calendar part inside multipart/alternative
• keeping a separate ICS attachment as fallback
• increasing SEQUENCE for updates, cancellations and maybe replys
• ensuring cancellations use METHOD, STATUS, the same UID and the same organizer

This would make it easier to use EspoCRM as the main system for customer meetings while still allowing external participants to process invitations and cancellations directly in their calendar clients.

Thank you.

Best regards, Martin

[yuri]

Hi Martin,

Changing it to use a MIME part will not be easy to do.

There might be some other reason (more simple to fix) why Thunderbird does not support our ICS attachment. Any help appreciated.

[yuri]

I added some changes.

What I noticed, that after the attachment is sent as a mime part with the METHOD parameter, if I send it via Microsoft SMTP, it rejects the email if there is something wrong with the meeting's ICS. For example, if there's no Attendee. Before, the email was still sent. Microsoft treats such emails as not regular emails, prioritizing the correct ICS over delivery.

https://github.com/espocrm/espocrm/pull/3705

[mfr]

Hi Yuri,

thank you for looking into this and for the changes you already added.

I can gladly help with testing from my side, especially with Thunderbird and Linux/Unix-based mail clients. I cannot really say much about Microsoft SMTP or Outlook/Exchange behavior myself, as I am Linux/Unix-only in my own environment. Also, I am not deeply familiar with the full iCalendar/iTIP/iMIP implementation details, so please treat my findings more as user-side testing and observations than as expert guidance.

I tried to understand the behavior a bit better by looking at RFC 5545, RFC 5546 and RFC 6047. From what I understand, your Microsoft SMTP observation could make sense:

Before the change, the ICS file was probably treated more like a normal attachment. After adding the "method" parameter to the "text/calendar" MIME part, the message is more clearly identified as an actual iMIP scheduling message. At that point, stricter validation seems expected.

As far as I understand it:
* RFC 5545 defines the iCalendar content itself.
* RFC 5546 defines the scheduling semantics, for example "REQUEST", "CANCEL", "UID", "ORGANIZER", "ATTENDEE" and "SEQUENCE".
* RFC 6047 defines how those scheduling messages are transported via email/MIME.

So maybe the issue is not the MIME part itself, but that EspoCRM should only send a real iMIP invitation when the generated ICS is valid enough for the corresponding method.

For example, if a meeting has no attendee, it may not be a valid "METHOD:REQUEST" invitation. In that case, falling back to a regular ICS attachment may be safer. If the meeting has valid attendees and the required scheduling properties, then sending it as "text/calendar; method=REQUEST" sounds correct.

For cancellations, it may be important to use "METHOD:CANCEL", the same "UID", the same "ORGANIZER", the affected attendees, "STATUS:CANCELLED" for a full cancellation, and an increased "SEQUENCE".

Again, I am not an expert in this area, but this seems to match your observation that Microsoft starts validating the ICS more strictly once the email is treated as a real calendar scheduling message.

[mfr]

Hi Yuri,

one technical question regarding the missing "ATTENDEE" case:

Would a meeting without an "ATTENDEE" actually be a real invitation at all?

From my understanding, that would rather be a personal calendar entry, a published event, or maybe a regular ICS export/import case. But if nobody is invited, I would not expect it to be sent as a real meeting invitation by email.

So maybe Microsoft rejecting a "METHOD:REQUEST" without an "ATTENDEE" is not wrong, but actually a useful hint.

In my understanding, the logic could be:
* if a meeting has attendees, send it as a real iTIP/iMIP invitation with "METHOD:REQUEST" and "text/calendar; method=REQUEST"
* if a meeting has no attendees, do not send it as a meeting invitation
* in that case, maybe only allow a regular ICS attachment/export, or use a non-invitation method if appropriate

I am not deep enough into the standard to say this with certainty, but as a user this distinction makes sense to me. A meeting request without a participant sounds more like an internal calendar entry than an invitation.