Sieve Email Filtering: Extension for Processing Calendar Attachments
Extracted elements (26)
The extension is designed to handle both standard iTIP/iMIP calendar messages and non-standard cases where the enclosed iCalendar data lacks a METHOD property, or the data is in an alternative machine-readable format such as JSCalendar, reflecting real-world diversity in calendar email practices.
The extension can be used with any machine-readable calendar data format (e.g., iCalendar RFC 5545, JSCalendar RFC 8984) that can express the relevant concepts, not exclusively iTIP-based iMIP messages.
The :organizers argument requires the 'extlists' extension to be enabled. The :outcome and :reason arguments require the 'variables' extension. When these extensions are not enabled, using their associated arguments MUST cause an error per RFC 5228.
If a mail message contains calendar data in multiple MIME parts, the action MUST verify that the calendar data in each part are semantically equivalent. If the data is semantically different, the action MUST NOT process the message; otherwise it MUST only process one representation.
If :allowpublic is omitted, the implementation MUST NOT process calendar data unless it is a well-formed iTIP message and one of the recipient's email addresses matches the Calendar User Address of the intended target (ORGANIZER for REPLY; ATTENDEE for REQUEST, CANCEL, ADD).
If calendar data is malformed in any way, it MUST be ignored and no action taken.
Sieve interpreters implementing this extension MUST have an identifier of 'processcalendar' for use with the capability mechanism.
The action SHOULD remove alarms from calendar data before applying it to a calendar, to avoid unwelcome notifications being triggered for the recipient.
The 'processcalendar' action can only be executed once per script; a script MUST fail with an appropriate error if it attempts to execute two or more 'processcalendar' actions.
The 'processcalendar' action is incompatible with the Sieve 'reject' and 'ereject' actions and does not cancel the implicit keep action.
The 'processcalendar' action MUST NOT make any changes to the participant status of the recipient when processing the calendar data.
The extension is believed not to introduce any privacy considerations beyond those in RFC 5228 (the base Sieve specification).
The :addresses argument specifies additional email addresses belonging to the recipient, supplementing those known to the implementation, for use in matching Calendar User Addresses.
The :allowpublic argument permits processing of calendar data that does not contain ATTENDEE properties, such as iTIP PUBLISH messages or non-iTIP messages lacking METHOD and/or ORGANIZER properties. If used with :organizers, the implementation MUST NOT process non-iTIP messages.
The :calendarid argument specifies the identifier of the calendar onto which new calendar objects should be placed. If omitted, new objects go to the user's 'default' calendar. Mutually exclusive with :updatesonly.
The :deletecancelled argument instructs the implementation that upon receiving a cancellation message it SHOULD remove the associated calendar object. If omitted, the object's status is set to cancelled and it remains on the calendar.
The :organizers argument specifies an external list (requires 'extlists' extension) of email addresses from which the recipient accepts events. Implementations MUST NOT process calendar data unless it is a well-formed iTIP message and one of the list addresses matches the ORGANIZER's Calendar User Address.
The :outcome argument names a variable to receive the action result string: 'no_action', 'added', 'updated', or 'error'. Requires the 'variables' extension.
The 'processcalendar' action parses encapsulated calendar data in a MIME email message and performs appropriate create, update, or delete operations on a user's calendars. It accepts optional arguments: :allowpublic, :addresses, :updatesonly/:calendarid, :deletecancelled, :organizers, :outcome, and :reason.
The :reason argument names a variable to receive a human-readable description of the outcome reason. Implementations MUST set the variable to the empty string if no reason is available.
The :updatesonly argument limits processing to messages targeting existing calendar objects only; if the unique identifier does not exist on any user calendar, the implementation MUST NOT add the object. :updatesonly and :calendarid are mutually exclusive.
IANA added 'processcalendar' to the 'Sieve Actions' registry (defined in RFC 9122 Section 2.1), noting incompatibility with 'reject'/'ereject' actions, no cancellation of implicit keep, and that it cannot be used with IMAP events.
IANA added 'processcalendar' to the 'Sieve Extensions' registry (defined in RFC 5228 Section 6.2) with capability name 'processcalendar', description 'Adds the processcalendar action command to add and update items on a user's calendars', and contact [email protected].
If calendar data contains embedded attachments, implementations SHOULD decode and scan them for malicious content. If an attachment is found to be malicious, 'processcalendar' MUST NOT process the calendar data.
The extension SHOULD NOT process calendar data from potentially malicious or untrustworthy senders. Trustworthiness may be evaluated via SPF, DKIM, DMARC, or S/MIME signatures; allow/deny lists using 'extlists' are recommended.
The 'processcalendar' extension MUST NOT process any calendar data enclosed in a message flagged as spam and/or malicious. The 'spamtest' and 'virustest' extensions or header tests can be used to make processing conditional on safe content.