iMIP response should not be sent if deleting event you have not sent an RSVP for

[neilj]

When an email with an iMIP invitation is sent to you, it may get added to your calendar automatically (so your PARTSTAT is NEEDS-ACTION). If you delete the event from the calendar without first setting your PARTSTAT to something else, we MUST NOT send an iMIP response. Otherwise, the user has no way of avoiding sending a response to this event, which is particularly bad if the event was spam.

FastMail had some code to fix this, but I'm not sure at what layer it's implemented. Certainly, deleting an event over JMAP always seems to send an RSVP at the moment. So, please check and ensure:

• Deleting an event over CalDAV where your PARTSTAT=NEEDS-ACTION does not send an iMIP response.
• Deleting an event over JMAP where your PARTSTAT=NEEDS-ACTION does not send an iMIP response.

If you had previously RSVPed to the event as ACCEPTED or TENTATIVE then of course deleting the event can send a response as before to indicate you are now DECLINED.

[dilyanpalauzov]

It is a matter of using the Schedule-Reply: F header to prevent the server from sending iMIP messages.

[rsto]

We might want to add a Cyrus config option so that installations may choose if to send DECLINE. If the client explicitly sets the Schedule-Reply header that always overrides what's configured. The default should be sending declines as-is IMHO.

@ksmurchison I'm not sure which legacy records the following snippet is referring to, do you know?

https://github.com/cyrusimap/cyrus-imapd/blob/6ddf27bdd2642e4be4001234a3f77a9258f12409/imap/http_caldav.c#L1589-L1594

[rsto]

For JMAP, I've just pushed https://github.com/cyrusimap/cyrus-imapd/commit/06908ba702c71ab58bfae853fce03739f86a8d41

We might want to rework the code if we find a generic solution for both CalDAV and JMAP.

[ksmurchison]

@rsto I'm not sure what that comment refers to either. I honestly don't remember writing it (assuming that I did).

I think Cyrus CalDAV as currently written is correct. The client can control whether or not they want the DECLINE to be sent by using the Schedule-Reply header. JMAP Calendar probably needs a similar control, rather than having the server unilaterally suppressing the DECLINE.

[rsto]

JMAP Calendar probably needs a similar control, rather than having the server unilaterally suppressing the DECLINE.

Agreed, a scheduleReply boolean argument on the JMAP request, or in the JSCalendar object, could do the trick.

[ksmurchison]

I think it belongs on the JMAP request, as its an instruction to the server and not part of the calendar data.

[rsto]

Yes. In which case it might need to become a multi-valued list or set of ids, similar to what's done in EmailSubmissions/set.

[dilyanpalauzov]

For CalDAV suppressing the iMIP message it is not only a matter of deleting an event, but also changing it locally without notifying the others. Such a modification would be extending the end of the meeting.

[rsto]

Indeed, thanks for the input @dilyanpalauzov . IMO we keep CalDAV as-is, it's up to the CalDAV client to decide if an iMIP message should be generated. For JMAP we can figure out what's best for the clients. Do you agree, @neilj ?

[dilyanpalauzov]

The user uses UI and communicates over CalDAV or JMAP changes. If you don’t know what the user wants, when he uses CalDAV and let the user be explicit, you don’t know what the user wants, when JMAP is used. This JMAP choice is at best standardized.

[dilyanpalauzov]

It is not a good idea to send iMIP message on deleting an event dependent from the used protocol for deletion. This will drive users crazy. Users don’t have to know whether their client uses CalDAV or JMAP to conclude how the server behaves. Think on deleting an event from the mobile phone uses CalDAV and sends notification and deleting the same event over web uses JMAP and does not send notification. But using another web client uses CalDAV and thus sends notification.