RFC 9671

Sieve Email Filtering: Extension for Processing Calendar Attachments

📅 published October 2024, from ietf

RFC 9671 💖 Sieve Email Filtering: Extension for Processing Calendar Attachments

okay bestie, let's get into this one 🎀 here's the title block tea:

  • RFC number and title: RFC 9671, "Sieve Email Filtering: Extension for Processing Calendar Attachments"
  • Authors: Kenneth Murchison, Ricardo Signes, and Michael Horsfall, all from Fastmail
  • Category: Standards Track (ISSN 2070-1721)
  • Date: October 2024
  • Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates

Abstract 🌸

so this doc describes the "processcalendar" extension for the Sieve email filtering language. it gives Sieve the power to process machine-readable calendar data that's tucked inside an email using MIME. main character energy for your inbox 💅

Status of This Memo ✨

this is an Internet Standards Track document 🦋

it's a product of the Internet Engineering Task Force (IETF). it reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check out Section 2 of RFC 7841.

info about the current status of this doc, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9671 🧚

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please read them carefully, because they spell out your rights and restrictions for this doc. any Code Components pulled out of this doc have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 🙈

Table of Contents 🍓

   1.  Introduction
   2.  Conventions Used in This Document
   3.  Capability Identifier
   4.  Process Calendar Action
     4.1.  Allow Public Argument
     4.2.  Addresses Argument
     4.3.  Updates Only Argument
     4.4.  Calendar ID Argument
     4.5.  Delete Cancelled Argument
     4.6.  Organizers Argument
     4.7.  Outcome Argument
     4.8.  Reason Argument
     4.9.  Interaction with Other Sieve Actions
     4.10. Examples
   5.  Security Considerations
   6.  Privacy Considerations
   7.  IANA Considerations
     7.1.  Registration of Sieve Extension
     7.2.  Registration of Sieve Action
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

people get invites, replies, and cancellations for events, tasks, and so on through regular email all the time 📬 it's often really useful to have those messages parsed automatically, with the calendar data they carry added to, updated on, or deleted from the user's calendars. it's giving automation 🤖

usually these messages are based on the iCalendar Message-Based Interoperability Protocol (iMIP) [RFC6047]. but sometimes the enclosed iCalendar [RFC5545] data doesn't have an iCalendar Transport-Independent Interoperability Protocol (iTIP) method property (see [RFC5546], Section 1.4), or the calendar data is in some other machine-readable format, like JSCalendar [RFC8984] 🎀

this doc defines an extension to the Sieve language [RFC5228] that lets scripts process machine-readable calendar data encapsulated in an email using MIME [RFC2045]. specifically, the extension can change items on a user's calendars that are referenced in that encapsulated calendar data 🦋

2. Conventions Used in This Document 💅

notation conventions follow Section 1.1 of [RFC5228], including the "Usage:" label for defining actions and the tagged arguments syntax 🌸

this doc uses terminology and concepts from iCalendar [RFC5545] and iTIP [RFC5546] to describe how calendar data gets processed. but the extension works with any machine-readable calendar format that can express similar concepts, so it's not picky 🫶

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like shown here 🔥

3. Capability Identifier 🧚

Sieve interpreters that implement this extension MUST have an identifier of "processcalendar" for use with the capability mechanism. no skipping that one, periodt 💜

4. Process Calendar Action 👑

Usage:

Usage: processcalendar [ :allowpublic ]
                       [ :addresses <string-list> ]
                       [ :updatesonly / :calendarid <string> ]
                       [ :deletecancelled ]
                       [ :organizers <ext-list-name: string> ]
                       [ :outcome <variablename: string> ]
                       [ :reason <variablename: string> ]

the "processcalendar" action parses encapsulated calendar data and does the right thing based on what's inside it 🍓 if the calendar data is malformed in any way, it MUST be ignored and no action is taken. otherwise, calendar objects can be created, updated, or deleted from a given calendar ✨

this action works with or without the "extlists" extension [RFC6134]. if a script turns on "extlists" with <require "extlists">, it can use the :organizers argument (Section 4.6) in the "processcalendar" action, as described below. if "extlists" isn't enabled, the :organizers argument MUST NOT be used, and using it MUST cause an error according to [RFC5228] 🙈

this action also works with or without the "variables" extension [RFC5229]. if a script turns on "variables" with <require "variables">, it can use the :outcome (Section 4.7) and :reason (Section 4.8) arguments in the "processcalendar" action, as described below. if "variables" isn't enabled, the :outcome and :reason arguments MUST NOT be used, and using them MUST cause an error according to [RFC5228] 💖

if a mail message has calendar data in multiple MIME [RFC2045] parts, this action MUST verify that the calendar data in each part is semantically equivalent to the others. if the data turns out to be semantically different, the action MUST NOT process the message. otherwise, the action MUST only process one representation of the data 🔍

this action MUST NOT change the participant status of the recipient while it processes the calendar data. how a recipient changes their participant status to an event is out of scope for this doc 🚫

this action SHOULD remove alarms from calendar data before applying it to a calendar. if it doesn't, the recipient could get unwelcome notifications triggered, and nobody wants that 😭

4.1. Allow Public Argument 🌈

the optional :allowpublic argument tells the implementation that it can process calendar data that doesn't have any ATTENDEE properties. this covers iTIP messages where the METHOD is PUBLISH, and non-iTIP messages where the calendar data doesn't have a METHOD and/or ORGANIZER property 🦋

if :allowpublic gets used together with the :organizers argument (Section 4.6), the implementation MUST NOT process non-iTIP messages 🚫

if :allowpublic is left out, the implementation MUST NOT process calendar data unless it's a well-formed iTIP message AND one of the recipient user's email addresses matches the Calendar User Address (see Section 3.3.3 of [RFC5545]) of the intended target of the message. the intended target is determined by the iTIP method (see Section 1.4 of [RFC5546]) of the message, like this:

  • "REPLY": the value of the ORGANIZER property (see Section 3.8.4.3 of [RFC5545])
  • "REQUEST", "CANCEL", "ADD": the value of one of the ATTENDEE properties (see Section 3.8.4.1 of [RFC5545])

the recipient user's email address matches the Calendar User Address of the target if that 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 counts as belonging to the recipient if it's one of these:

  • an email address the implementation knows is associated with the recipient,
  • the final envelope recipient address, if the implementation has it available, or
  • an address the script writer sets with the :addresses argument (Section 4.2).

4.2. Addresses Argument 🍓

the optional :addresses argument specifies email addresses that belong to the recipient, on top of the addresses the implementation already knows about 💌

4.3. Updates Only Argument ✨

the optional :updatesonly argument limits the messages that get processed to ones that target existing calendar objects only. if the message has a new calendar object (meaning its unique identifier doesn't exist on any of the user's calendars), the implementation MUST NOT add that object to a calendar 🛑

if :updatesonly is left out, new calendar objects can be added to one of the user's calendars 🌸

the :updatesonly and :calendarid (Section 4.4) arguments are incompatible with each other. using both in the same "processcalendar" action is an error 🙅

4.4. Calendar ID Argument 🦋

the optional :calendarid argument specifies the identifier of the calendar where new calendar objects should go 🗓️

if :calendarid is left out, new calendar objects get placed on the user's "default" calendar, as the implementation decides 🧚

the :updatesonly (Section 4.3) and :calendarid arguments are incompatible with each other. using both in the same "processcalendar" action is an error 🙅

4.5. Delete Cancelled Argument 💜

the optional :deletecancelled argument tells the implementation that if it gets a cancellation message, it SHOULD remove the associated calendar object from the calendar 🗑️

if :deletecancelled is left out, the associated calendar object's status gets set to cancelled, and it stays on the calendar 🫶

4.6. Organizers Argument 👑

the optional :organizers argument specifies an external list of email addresses that the recipient is willing to accept public events, invites, updates, and cancellations from 💖 implementations MUST NOT process calendar data unless it's 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 that Calendar User Address if it's in the form of a mailto URI and the email address matches the "addr-spec" of the URI 🔐

if :organizers is left out, no validation of the ORGANIZER property happens at all 🙈

4.7. Outcome Argument 🌈

the optional :outcome argument names a variable where one of these strings, describing how the action went, will be stored ✨

  • "no_action": no action was performed. for example, the message didn't contain calendar data, or the options that were set stopped the message from being processed 😶
  • "added": a new calendar object was added to a calendar 🎉
  • "updated": a calendar object was updated, cancelled, or removed from the calendar 🔄
  • "error": the message would have been processed, but ran into an error while doing it 💀

4.8. Reason Argument ✨

okay so the optional :reason argument is basically the "why" behind the outcome 🧐 It names a variable where a string describing the reason for the outcome gets stored. If no reason is available, implementations MUST set the variable to the empty string 💅

For example, an outcome of "no_action" might come with a reason of "only processing updates", or an outcome of "error" might have a reason of "missing unique identifier" 🫶

4.9. Interaction with Other Sieve Actions 🦋

The processcalendar action does NOT cancel Sieve's implicit keep action 🌸

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 [RFC5429]. ngl, these three just don't mix 💀

4.10. Examples 🎀

bestie, here are the examples! 🧚

The first one specifies the email addresses that belong to the user, plus the identifier of the calendar where new calendar objects should go:

require [ "processcalendar" ];

processcalendar :addresses [ "me@example.com", "alsome@example.com" ]
                :calendarid "1ea6d86b-6c7f-48a2-bed3-2a4c40ec281a";

The next one 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;
}

And this last one adds headers to the message if calendar data isn't processed. It's giving debugging energy 🔍

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}";
}

5. Security Considerations 🔐

okay this one is SERIOUS, bestie 😭 This document describes a method for altering an electronic calendar without any user interaction. That means that, 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:
  • The processcalendar extension MUST NOT process any calendar data enclosed in a message flagged as spam and/or malicious. The spamtest and virustest extensions [RFC5235] (or the header test [RFC5228] if messages are scanned outside of the Sieve interpreter) can be used to make processcalendar conditional on "safe" content 🛡️
  • The processcalendar extension SHOULD NOT process calendar data received from a potentially malicious sender. The address and envelope tests [RFC5228] (optionally along with the extlists extension [RFC6134]) can be used to create a "deny list" and make processcalendar conditional on the sender not being a member of that list 🚫
  • Similarly, the processcalendar extension SHOULD only process calendar data received from a known sender. The address and envelope tests [RFC5228] (optionally along with the extlists extension [RFC6134]) can be used to create an "allow list" and make processcalendar conditional on the sender being a member of that list 💌
  • The processcalendar extension SHOULD NOT process calendar data received from an untrustworthy sender. Trustworthiness may depend on whether the message has a valid signature (see [RFC8551]) and/or on whether one or more of the following passes or fails on the message: Sender Policy Framework (SPF) [RFC7208], DomainKeys Identified Mail (DKIM) Signatures [RFC6376], and Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. The mechanism by which a Sieve interpreter accesses the results of such checks is outside the scope of this document, but if the results are available in the message's header fields, the header test [RFC5228] can be used to make processcalendar conditional on the sender being trustworthy 🕵️

Additionally, if the calendar data has embedded (a.k.a. inline) attachments, implementations SHOULD:

  • Decode the embedded attachment, if necessary.
  • Scan the (decoded) attachment for malicious content.

If an attachment is found to be malicious, processcalendar MUST NOT process the calendar data. Full stop, no exceptions 🚨

6. Privacy Considerations 🌈

It is believed that this extension doesn't introduce any privacy considerations beyond those in [RFC5228] 🫧

7. IANA Considerations 📋

7.1. Registration of Sieve Extension

This document defines the following new Sieve extension, which IANA has added to the "Sieve Extensions" registry (https://www.iana.org/assignments/sieve-extensions). The registry is defined in Section 6.2 of [RFC5228] 🗂️

Capability name:  processcalendar

Description:  Adds the "processcalendar" action command to add and
   update items on a user's calendars.

RFC number:  RFC 9671

Contact address:  Sieve discussion list <sieve@ietf.org>

7.2. Registration of Sieve Action

This document defines the following new Sieve action, which IANA has added to the "Sieve Actions" registry (https://www.iana.org/assignments/sieve-extensions). The registry is defined in Section 2.1 of [RFC9122] 🎟️

Name:  processcalendar

Description:  Add and update items on a user's calendars

References:  RFC 9671 [RFC5229] [RFC6134]

Capabilities:  "processcalendar", "variables", "extlists"

Action Interactions:  This action is incompatible with the "reject"
   and "ereject" actions.

Cancels Implicit Keep?  No

Can Use with IMAP Events?  No

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgments 🫶

The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Ned Freed and Alexey Melnikov. Iconic team behavior 👑

Authors' Addresses 💖

Kenneth Murchison
Fastmail US LLC
1429 Walnut Street, Suite 1201
Philadelphia, PA 19102
United States of America
Email: murch@fastmailteam.com


Ricardo Signes
Fastmail US LLC
1429 Walnut Street, Suite 1201
Philadelphia, PA 19102
United States of America
Email: rjbs@fastmailteam.com


Matthew Horsfall
Fastmail US LLC
1429 Walnut Street, Suite 1201
Philadelphia, PA 19102
United States of America
Email: alh@fastmailteam.com
📦 where this page comes from