| RFC 9671 | Sieve Extension for Processing Calendar | October 2024 |
| Murchison, et al. | Standards Track | [Page] |
This document describes the "processcalendar" extension to the Sieve email filtering language. The "processcalendar" extension gives Sieve the ability to process machine-readable calendar data that is encapsulated in an email message using Multipurpose Internet Mail Extensions (MIME).¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9671.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Users frequently receive invites, replies, and cancellations for events, tasks, etc. via Internet mail messages. It is sometimes desirable to have such messages automatically parsed and the enclosed calendar data added to, updated on, or deleted from the user's calendars.¶
Typically, such messages are based on the iCalendar Message-Based Interoperability Protocol (iMIP)[RFC6047]. However, sometimes the enclosed iCalendar[RFC5545] data does not include an iCalendar Transport-Independent Interoperability Protocol (iTIP) method property (see[RFC5546],Section 1.4), or the enclosed data may be in some other machine-readable format (e.g., JSCalendar[RFC8984]).¶
This document defines an extension to the Sieve language[RFC5228] that enables scripts to process machine-readable calendar data that is encapsulated in an email message using MIME[RFC2045]. Specifically, this extension provides the ability to alter items on a user's calendars that are referenced in the encapsulated calendar data.¶
Conventions for notations are as inSection 1.1 of [RFC5228], including use of the "Usage:" label for the definition of action and tagged arguments syntax.¶
This document uses terminology and concepts from iCalendar[RFC5545] and iTIP[RFC5546] to describe the processing of calendar data, but this extension can be used with any machine-readable calendar data format that can express similar concepts.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Sieve interpreters that implement this extensionMUST have an identifier of "processcalendar" for use with the capability mechanism.¶
Usage: processcalendar [ :allowpublic ] [ :addresses <string-list> ] [ :updatesonly / :calendarid <string> ] [ :deletecancelled ] [ :organizers <ext-list-name: string> ] [ :outcome <variablename: string> ] [ :reason <variablename: string> ]¶
The "processcalendar" action is used to parse encapsulated calendar data and perform the appropriate action based on the content. If the calendar data is malformed in any way, itMUST be ignored and no action is taken. Otherwise, calendar objects may be created, updated, or deleted from a given calendar.¶
This action can be used with or without the "extlists" extension[RFC6134]. When the "extlists" extension is enabled in a script using <require "extlists">, the script can use the :organizers argument (Section 4.6) in the "processcalendar" action as described below. When the "extlists" extension is not enabled, the :organizers argumentMUST NOT be used andMUST cause an error according to[RFC5228].¶
This action can be used with or without the "variables" extension[RFC5229]. When the "variables" extension is enabled in a script using <require "variables">, the script can use the :outcome (Section 4.7) and :reason (Section 4.8) arguments in the "processcalendar" action as described below. When the "variables" extension is not enabled, the :outcome and :reason argumentsMUST NOT be used andMUST cause an error according to[RFC5228].¶
If a mail message contains calendar data in multiple MIME[RFC2045] parts, this actionMUST verify that the calendar data in each part are semantically equivalent to one another. If the data is found to be semantically different, the actionMUST NOT process the message. Otherwise, the actionMUST only process one representation of the data.¶
This actionMUST NOT make any changes to the participant status of the recipient when processing the calendar data. The mechanism for a recipient to change their participant status to an event is out of scope for this document.¶
This actionSHOULD remove alarms from calendar data before applying it to a calendar. Failure to do so could result in unwelcome notifications being triggered for the recipient.¶
The optional :allowpublic argument is used to tell the implementation that it can process calendar data that does not contain any ATTENDEE properties, such as iTIP messages where the METHOD is PUBLISH or non-iTIP messages where the calendar data does not contain METHOD and/or ORGANIZER properties.¶
If used in conjunction with the :organizers argument (Section 4.6), the implementationMUST NOT process non-iTIP messages.¶
If :allowpublic is omitted, the implementationMUST NOT process calendar data unless is it is a well-formed iTIP message and one of the recipient user's email addresses matches the Calendar User Address (seeSection 3.3.3 of [RFC5545]) of the intended target of the message, as determined by the iTIP method (seeSection 1.4 of [RFC5546]) of the message:¶
The recipient user's email address matches the Calendar User Address of the target if the Calendar User Address is in the form of a mailto URI and the email address matches the "addr-spec" of the URI.¶
An email address is considered to belong to the recipient if it is one of the following:¶
The optional :addresses argument is used to specify email addresses that belong to the recipient in addition to the addresses known to the implementation.¶
The optional :updatesonly argument is used to limit the messages processed to those targeting existing calendar objects only. If the message contains a new calendar object (its unique identifier does not exist on any of the user's calendars), the implementationMUST NOT add the object to a calendar.¶
If :updatesonly is omitted, new calendar objects may be added to one of the user's calendars.¶
The :updatesonly and :calendarid (Section 4.4) arguments are incompatible with each other. It is an error if both arguments are used in the same "processcalendar" action.¶
The optional :calendarid argument specifies the identifier of the calendar onto which new calendar objects should be placed.¶
If :calendarid is omitted, new calendar objects will be placed on the user's "default" calendar as determined by the implementation.¶
The :updatesonly (Section 4.3) and :calendarid arguments are incompatible with each other. It is an error if both arguments are used in the same "processcalendar" action.¶
The optional :deletecancelled argument is used to tell the implementation that if it receives a cancellation message, itSHOULD remove the associated calendar object from the calendar.¶
If :deletecancelled is omitted, the status of the associated calendar object will be set to cancelled and will remain on the calendar.¶
The optional :organizers argument is used to specify an external list of email addresses from which the recipient is willing to accept public events, invites, updates, and cancellations. ImplementationsMUST NOT process calendar data unless is it is a well-formed iTIP message and one of the addresses in the external list matches the Calendar User Address of the ORGANIZER property. An email address in the external list matches the Calendar User Address of the ORGANIZER property if it is in the form of a mailto URI and the email address matches the "addr-spec" of the URI.¶
If :organizers is omitted, no validation of the ORGANIZER property is performed.¶
The optional :outcome argument specifies the name of a variable into which one of the following strings specifying the outcome of the action will be stored:¶
The optional :reason argument specifies the name of a variable into which a string describing the reason for the outcome will be stored. If no reason for the outcome is available, implementationsMUST set the variable to the empty string.¶
For example, an outcome of "no_action" may have a reason of "only processing updates", or an outcome of "error" may have a reason of "missing unique identifier".¶
The "processcalendar" action does not cancel Sieve's implicit keep action.¶
The "processcalendar" action can only be executed once per script. A scriptMUST 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[RFC5429].¶
The following example specifies email addresses belonging to the user and the identifier of the calendar onto which to place new calendar objects:¶
require [ "processcalendar" ];processcalendar :addresses [ "me@example.com", "alsome@example.com" ] :calendarid "1ea6d86b-6c7f-48a2-bed3-2a4c40ec281a";¶
The following example tells the interpreter to process flight itineraries from a particular airline:¶
require [ "processcalendar" ];if allof (address ["from", "sender"] "airline@example.com", header :contains "subject" "itinerary") { processcalendar :allowpublic;}¶The following example adds headers to the message if calendar data isn't processed :¶
require [ "processcalendar", "variables", "editheader" ];set "processcal_outcome" "no_action";set "processcal_reason" "";processcalendar :outcome "processcal_outcome" :reason "processcal_reason";if not string :is "${processcal_outcome}" ["added", "updated"] { addheader "X-ProcessCal-Outcome" "${processcal_outcome}"; addheader "X-ProcessCal-Reason" "${processcal_reason}";}¶This document describes a method for altering an electronic calendar without user interaction. As such, unless proper precautions are undertaken, it can be used as a vector for calendar abuse.¶
It is critical that implementations correctly implement the behavior and restrictions described throughout this document. Security issues associated with processing unsolicited calendar data and methods for mitigating them are discussed in[CALSPAM]. Specifically:¶
Additionally, if the calendar data has embedded (a.k.a. inline) attachments, implementationsSHOULD:¶
If an attachment is found to be malicious, "processcalendar"MUST NOT process the calendar data.¶
It is believed that this extension doesn't introduce any privacy considerations beyond those in[RFC5228].¶
This document defines the following new Sieve extension, which IANA has added to the"Sieve Extensions" registry. The registry is defined inSection 6.2 of [RFC5228].¶
This document defines the following new Sieve action, which IANA has added to the"Sieve Actions" registry. The registry is defined inSection 2.1 of [RFC9122].¶
The authors would like to thank the following individuals for contributing their ideas and support for writing this specification:Ned Freed andAlexey Melnikov.¶