JMAP M. De Gennaro Internet-Draft Stalwart Labs Updates: RFC8621 (if approved) 2 November 2025 Intended status: Standards Track Expires: 6 May 2026 JMAP Mail Sharing draft-degennaro-jmap-mail-sharing-00 Abstract This document specifies an extension to the JSON Meta Application Protocol (JMAP) for Mail to enable sharing of mailboxes between users. Building upon the JMAP Sharing framework defined in [RFC9670], this specification extends the Mailbox data type defined in [RFC8621] with properties necessary to configure and manage access permissions for shared mailboxes. The extension introduces a new capability that indicates server support for mailbox sharing and defines the additional properties required to share mailboxes with other principals, including the ability to control which users may access a mailbox and what permissions they possess. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2026. Copyright Notice Copyright (c) 2025 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. De Gennaro Expires 6 May 2026 [Page 1] Internet-Draft JMAP Mail Sharing November 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Addition to the Capabilities Object . . . . . . . . . . . 3 1.2.1. urn:ietf:params:jmap:mail:share . . . . . . . . . . . 3 2. Mailbox Sharing . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3.1. Access Control Enforcement . . . . . . . . . . . . . . . 5 3.2. Interaction with IMAP ACLs . . . . . . . . . . . . . . . 5 3.3. Unauthorized Sharing . . . . . . . . . . . . . . . . . . 5 3.4. Information Disclosure Through Error Messages . . . . . . 6 3.5. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 6 3.6. Privilege Escalation . . . . . . . . . . . . . . . . . . 6 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 4.1. JMAP Capability Registration for "mail:share" . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction JMAP ([RFC8620] — JSON Meta Application Protocol) is a generic protocol for synchronizing data, such as mail, calendars or contacts, between a client and a server. It is optimized for mobile and web environments, and aims to provide a consistent interface to different data types. [RFC8621] defines JMAP for Mail, which provides a data model for accessing, organizing, and managing email messages and mailboxes. The specification enables clients to efficiently synchronize mail data with servers and includes support for mailbox hierarchies, message threading, and various mail operations. [RFC9670] subsequently standardized JMAP Sharing, which defines a framework for sharing data between users in collaborative environments. The specification introduces the Principal data type to represent entities (individuals, teams, or resources) and establishes a consistent model for defining shared access to data through the use of access control properties. De Gennaro Expires 6 May 2026 [Page 2] Internet-Draft JMAP Mail Sharing November 2025 However, [RFC8621] was published prior to the standardization of the JMAP Sharing framework in [RFC9670], and therefore does not incorporate the sharing model into the Mailbox data type. This creates a gap in the ability to share mailboxes using the standardized JMAP sharing mechanisms. This document bridges that gap by defining how the Mailbox object defined in [RFC8621] is extended to support the sharing framework established in [RFC9670]. This extension enables users to share their mailboxes with other principals using a consistent sharing model that can be applied uniformly across different JMAP data types. The specification defines the necessary properties, permissions, and capability advertisements to enable interoperable mailbox sharing implementations. 1.1. Notational Conventions 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. 1.2. Addition to the Capabilities Object The capabilities object is returned as part of the JMAP Session object; see Section 2 of [RFC8620]. This document defines one additional capability URI. 1.2.1. urn:ietf:params:jmap:mail:share This capability indicates server support for sharing mailboxes as defined in this specification. When a server advertises this capability, it signifies that the Mailbox data type has been extended with the sharing properties defined in Section 4 of [RFC9670] and that clients may use these properties to configure mailbox sharing with other principals. The value of this property in the JMAP Session "capabilities" property is an empty object. The value of this property in an account's "accountCapabilities" property is an empty object. De Gennaro Expires 6 May 2026 [Page 3] Internet-Draft JMAP Mail Sharing November 2025 2. Mailbox Sharing According to Section 4 of [RFC9670], shareable data types MUST define three specific properties to participate in the JMAP sharing framework: isSubscribed, myRights, and shareWith. These properties enable users to control whether they wish to see shared data, understand what permissions they have, and configure who the data is shared with, respectively. In addition to these three properties, shareable data types SHOULD define a permission within the rights object that indicates whether a user has the authority to share the object with others. This permission controls access to modifying the shareWith property. The Mailbox object defined in Section 2 of [RFC8621] already includes the isSubscribed and myRights properties, as mailbox subscription and access control were integral features of the original mail specification. However, the specification did not include the shareWith property or define a permission for sharing rights. This specification extends the JMAP Mailbox object defined in [RFC8621] to include the shareWith property as defined below: *shareWith*: Id[MailboxRights]|null (default: null) This is a map configuring who the mailbox is shared with, or null if it is not shared with anyone. Each key in the map is the id of a Principal with whom the mailbox is shared. The value for each key is the set of access rights that Principal has for the mailbox. The account id for the Principals may be found in the urn:ietf:params:jmap:principals:owner capability of the Account to which the mailbox belongs. The Principal to which this mailbox belongs MUST NOT be in the map. The property may only be modified if the user has the mayShare right. This specification also extends the JMAP MailboxRights object defined in Section 2 of [RFC8621] to include the mayShare property as defined below. For servers that also support IMAP [RFC3501], this property corresponds to the IMAP ACL "a" right as defined in [RFC4314]: *mayShare*: Boolean The user may modify the shareWith property for this mailbox. For servers supporting IMAP access to the same data, this corresponds to the IMAP ACL "a" right defined in [RFC4314], which grants the ability to administer access control lists. De Gennaro Expires 6 May 2026 [Page 4] Internet-Draft JMAP Mail Sharing November 2025 3. Security Considerations All security considerations described in [RFC8621] and [RFC9670] apply to this specification. Additional considerations specific to mailbox sharing are detailed below. 3.1. Access Control Enforcement Servers implementing this specification MUST strictly enforce access controls when sharing mailboxes. When a user has access to a shared mailbox, the server MUST ensure that the user can only perform operations permitted by their assigned rights. As specified in Section 9.5 of [RFC8621], servers MUST treat any data the user does not have permission to access as if it did not exist. This principle extends to shared mailboxes: a user with partial access to an account MUST NOT be able to infer the existence of mailboxes or messages they do not have permission to access. 3.2. Interaction with IMAP ACLs Servers that provide both JMAP and IMAP [RFC3501] access to the same mail store should carefully consider the interaction between JMAP sharing permissions and IMAP ACLs [RFC4314]. The mapping between JMAP MailboxRights and IMAP ACL rights must be consistent and clearly documented. When a mailbox is shared through either interface, the permissions MUST be properly reflected in the other interface to prevent security vulnerabilities arising from inconsistent access control enforcement. Particular attention must be paid to the mayShare right and IMAP ACL "a" right mapping. Servers MUST ensure that granting the mayShare permission through JMAP correctly corresponds to granting the "a" right in IMAP, and vice versa. Any discrepancies in permission semantics between the two protocols could lead to privilege escalation or unintended access. 3.3. Unauthorized Sharing As noted in Section 6.2 of [RFC9670], sharing data with another user can allow an attacker who gains transitory access to an account to establish persistent access by configuring sharing with an attacker- controlled principal. Servers implementing mailbox sharing SHOULD consider requiring additional authentication or confirmation when sharing permissions are modified, particularly when adding new principals to the shareWith map or granting elevated permissions such as mayShare. De Gennaro Expires 6 May 2026 [Page 5] Internet-Draft JMAP Mail Sharing November 2025 Servers MAY implement audit logging of sharing configuration changes to enable detection of unauthorized modifications. Administrators SHOULD be provided with tools to monitor and review sharing configurations across accounts. 3.4. Information Disclosure Through Error Messages Servers must be cautious not to leak information about the existence of mailboxes or their sharing status through error messages. When a user attempts to access or modify a mailbox they do not have permission to access, the server SHOULD return the same error response as it would if the mailbox did not exist, rather than indicating that access was denied. This prevents users from enumerating shared mailboxes they do not have access to. Similarly, when a user attempts to share a mailbox with a principal they do not have permission to share with, error messages should not reveal whether such restrictions exist or details about the target principal. 3.5. Resource Exhaustion Servers SHOULD implement limits on the number of principals with whom a single mailbox may be shared to prevent resource exhaustion attacks. Servers MAY also implement rate limiting on sharing configuration changes to mitigate denial-of-service attacks through excessive modifications to sharing permissions. As described in Section 6.3 of [RFC9670], servers should be prepared to handle scenarios where users create many sharing-related state changes, which could generate numerous ShareNotification objects. Servers SHOULD implement appropriate resource limits and notification coalescing strategies. 3.6. Privilege Escalation Servers MUST ensure that users cannot escalate their own privileges through manipulation of sharing permissions. For example, a user who has been granted limited access to a mailbox MUST NOT be able to grant themselves additional permissions by modifying the shareWith property unless they have been explicitly granted the mayShare right. The owner of a mailbox (the Principal associated with the account containing the mailbox) always has implicit full rights to the mailbox. This ownership MUST NOT be transferable through the sharing mechanism, and the owner MUST NOT appear in the shareWith map. De Gennaro Expires 6 May 2026 [Page 6] Internet-Draft JMAP Mail Sharing November 2025 4. IANA considerations 4.1. JMAP Capability Registration for "mail:share" IANA will register the "mail:share" JMAP Capability as follows: *Capability Name:* urn:ietf:params:jmap:mail:share *Specification document:* this document *Intended use:* common *Change Controller:* IETF *Security and privacy considerations:* this document, Section 3 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, . [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, August 2019, . [RFC9670] Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP) Sharing", RFC 9670, DOI 10.17487/RFC9670, November 2024, . 5.2. Informative References [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . De Gennaro Expires 6 May 2026 [Page 7] Internet-Draft JMAP Mail Sharing November 2025 Appendix A. Changes [[This section to be removed by RFC Editor]] *draft-degennaro-jmap-mail-sharing-00* * Initial version Author's Address Mauro De Gennaro Stalwart Labs LLC 1309 Coffeen Avenue, Suite 1200 Sheridan, WY 82801 United States of America Email: mauro@stalw.art URI: https://stalw.art De Gennaro Expires 6 May 2026 [Page 8]