]> Stalwart Labs LLC

1309 Coffeen Avenue, Suite 1200 Sheridan WY 82801 USA mauro@stalw.art https://stalw.art

JMAP Internet-Draft 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 , this specification extends the Mailbox data type defined in 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.

Introduction JMAP ( — 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. 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. 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. However, was published prior to the standardization of the JMAP Sharing framework in , 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 is extended to support the sharing framework established in . 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.

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 when, and only when, they appear in all capitals, as shown here.

Addition to the Capabilities Object The capabilities object is returned as part of the JMAP Session object; see . This document defines one additional capability URI.

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 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.

Mailbox Sharing According to , 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 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 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 to include the mayShare property as defined below. For servers that also support IMAP , this property corresponds to the IMAP ACL "a" right as defined in :

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 , which grants the ability to administer access control lists.

Security Considerations All security considerations described in and apply to this specification. Additional considerations specific to mailbox sharing are detailed below.

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 , 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.

Interaction with IMAP ACLs Servers that provide both JMAP and IMAP access to the same mail store should carefully consider the interaction between JMAP sharing permissions and IMAP ACLs . 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.

Unauthorized Sharing As noted in , 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. 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.

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.

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 , 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.

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.

IANA considerations

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,

This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client. This document specifies a data model for sharing data between users using the JSON Meta Application Protocol (JMAP). Future documents can reference this document when defining data types to support a consistent model of sharing. The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]

Changes [[This section to be removed by RFC Editor]] draft-ietf-jmap-mail-sharing-00 Initial version