IMAP OBJECTID Account Identifier extension

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

The IMAP OBJECTID extension, defined in [RFC8474], provides persistent identifiers for mailboxes (MAILBOXID) and messages (EMAILID and THREADID) within an IMAP server. These identifiers enable clients to efficiently track and reference resources even when they are moved or renamed, thereby reducing the need for redundant data synchronization operations.¶

The JMAPACCESS extension for IMAP, specified in [RFC9698], establishes a mechanism by which IMAP clients can discover that the messages and mailboxes accessible via IMAP are also available through JMAP (the JSON Meta Application Protocol, as defined in [RFC8620]). When an IMAP server advertises the JMAPACCESS capability, it asserts that mailboxes and messages share the same object identifiers across both protocols. This allows clients to migrate gradually to JMAP or to leverage JMAP-specific features while continuing to use IMAP as their primary access method.¶

The JMAP Email Delivery Push extension [I-D.ietf-jmap-emailpush] extends JMAP's push notification capabilities to deliver EmailPush objects containing specific email properties directly to clients when new messages arrive. These push notifications include the accountId property, which identifies the JMAP account to which the delivered email belongs. This account-level identification is essential for clients managing multiple accounts, as it allows them to properly route notifications and display relevant information to users without requiring additional synchronization requests.¶

In JMAP, an authenticated user may have access to multiple accounts, each containing distinct sets of mailboxes and messages. Each account is identified by a unique accountId, which serves as a namespace for all objects within that account. The accountId is a fundamental concept in JMAP architecture, as it allows servers to represent different data stores, organizational units, or delegation scenarios within a single authenticated session. For instance, a user might have access to their personal account, one or more shared team accounts, and delegated accounts from other users.¶

The JMAPACCESS extension, as currently specified in [RFC9698], implicitly assumes that all IMAP mailboxes accessible to an authenticated user correspond to a single JMAP account. Consequently, when object identifiers are exchanged between IMAP and JMAP, the accountId is omitted from the IMAP representation, as it is presumed to be constant. This assumption holds true in the majority of deployment scenarios, where a user's IMAP connection maps directly to their primary JMAP account.¶

However, this assumption breaks down in environments where an IMAP session provides access to mailboxes from multiple JMAP accounts. Such scenarios commonly arise when users access shared mailboxes, delegated folders, or organizational resources that exist within separate JMAP accounts but are presented as part of a unified IMAP mailbox hierarchy. In these cases, the MAILBOXID alone is insufficient to uniquely identify a mailbox across the IMAP-JMAP boundary, because different JMAP accounts may theoretically use the same MAILBOXID for different mailboxes.¶

This ambiguity becomes particularly problematic when considering the JMAP Email Delivery Push extension. When a client receives an EmailPush notification containing an accountId and a mailbox identifier, it needs to correlate this information with its IMAP representation of the mailbox. Without an accountId in the IMAP context, the client cannot definitively determine which JMAP account a given IMAP mailbox belongs to, potentially leading to incorrect mailbox associations, failed synchronization attempts, or inability to properly handle push notifications for shared mailboxes.¶

The motivation for this specification is to extend the OBJECTID framework to include account-level identification in IMAP, thereby enabling precise correlation of mailboxes across IMAP and JMAP protocols in multi-account environments. By introducing the ACCOUNTID object identifier, this extension ensures that clients can unambiguously identify the JMAP account associated with each IMAP mailbox, facilitating interoperability and enabling advanced features such as account-aware push notifications.¶

2. ACCOUNTID Object Identifier

The ACCOUNTID is a server-allocated identifier that specifies the JMAP account to which a mailbox belongs. When used in conjunction with the MAILBOXID, the ACCOUNTID provides complete disambiguation of mailboxes in environments where multiple JMAP accounts are accessible through a single IMAP session.¶

The ACCOUNTID is represented as an opaque string using the same character set and syntactic constraints as the MAILBOXID, as defined in Section 4 of [RFC8474]. That is, an ACCOUNTID MUST consist of between 1 and 255 characters from the base64url alphabet defined in Section 5 of [RFC4648], excluding the padding character.¶

The server MUST ensure that for any mailbox accessible via both IMAP and JMAP, the ACCOUNTID returned via IMAP matches the accountId property of the corresponding Mailbox object in JMAP, as defined in Section 1.6.2 of [RFC8620]. This correspondence is essential for clients to correlate mailboxes across the two protocols.¶

The server MUST return the same ACCOUNTID for all mailboxes that belong to the same JMAP account. Conversely, the server MUST NOT return the same ACCOUNTID for mailboxes that belong to different JMAP accounts, even if accessed within the same IMAP session.¶

When a mailbox is accessed exclusively through IMAP and does not have a corresponding representation in JMAP (for instance, if the server does not support the JMAPACCESS extension), the server MAY still assign an ACCOUNTID to maintain consistency in the IMAP representation. However, such ACCOUNTIDs need not correspond to any JMAP account identifier.¶

If a server advertises both "OBJECTID=ACCOUNTID" and "JMAPACCESS" capabilities, clients can rely on the ACCOUNTID to determine the appropriate JMAP account context for operations involving the mailbox. This is particularly important when handling JMAP Email Delivery Push notifications, as described in the introduction, where the accountId field in an EmailPush object can be correlated with the ACCOUNTID of the corresponding IMAP mailbox.¶

The ACCOUNTID is conceptually immutable for a given JMAP account within an IMAP session. However, if the underlying JMAP account is deleted or the user's access to that account is revoked, the associated mailboxes will no longer be accessible via IMAP, and their ACCOUNTIDs become irrelevant. If a new account is subsequently created with the same accountId, and mailboxes from that account become accessible via IMAP, the server MAY reuse the same ACCOUNTID value.¶

C: 3 create foo
S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625) \
         ACCOUNTID (u1a48e8e3)] Completed
C: 4 create shared/team
S: 4 OK [MAILBOXID (F8839dca12-3ef8-4a72-b63d-54f9e8a1) \
         ACCOUNTID (u2b59f9f4)] Completed
C: 5 create foo
S: 5 NO Mailbox already exists

C: 27 select "foo"
[...]
S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625) \
         ACCOUNTID (u1a48e8e3)] Ok
[...]
S: 27 OK [READ-WRITE] Completed

C: 28 select "shared/team"
[...]
S: * OK [MAILBOXID (F8839dca12-3ef8-4a72-b63d-54f9e8a1) \
         ACCOUNTID (u2b59f9f4)] Ok
[...]
S: 28 OK [READ-WRITE] Completed

C: 31 status foo (MAILBOXID ACCOUNTID MESSAGES)
S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)\
                 ACCOUNTID (u1a48e8e3) MESSAGES 42)
S: 31 OK Completed

C: 32 status shared/team (MAILBOXID ACCOUNTID MESSAGES)
S: * STATUS shared/team (\
       MAILBOXID (F8839dca12-3ef8-4a72-b63d-54f9e8a1)\
       ACCOUNTID (u2b59f9f4) MESSAGES 17)
S: 32 OK Completed

C: 33 list "" "*" return (status (MAILBOXID ACCOUNTID))
S: * LIST (\HasNoChildren) "." "foo"
S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625)\
                 ACCOUNTID (u1a48e8e3))
S: * LIST (\HasNoChildren) "." "shared.team"
S: * STATUS shared.team (\
         MAILBOXID (F8839dca12-3ef8-4a72-b63d-54f9e8a1)\
         ACCOUNTID (u2b59f9f4))
S: 33 OK Completed

3. Implementation Considerations

The implementation considerations specified in Section 8 of [RFC8474] apply equally to the ACCOUNTID object identifier defined in this specification.¶

In particular, the ACCOUNTID is generated and managed entirely by the server. Clients MUST NOT attempt to construct, modify, or interpret the internal structure of an ACCOUNTID value. The ACCOUNTID MUST be treated as an opaque identifier whose only meaningful operation is equality comparison.¶

Servers SHOULD generate ACCOUNTIDs using mechanisms that ensure global uniqueness across all accounts within the server's administrative domain, similar to the recommendations for MAILBOXID generation. Suitable approaches include Universally Unique Identifiers (UUIDs) as defined in [RFC4122], or server-assigned sequence numbers that are guaranteed never to be reused.¶

When both "OBJECTID=ACCOUNTID" and "JMAPACCESS" capabilities are advertised, servers MUST ensure that the ACCOUNTID values correspond exactly to the accountId values used in the JMAP protocol. This correspondence is essential for clients that need to correlate IMAP mailboxes with their JMAP representations, particularly when handling JMAP Email Delivery Push notifications.¶

Servers that provide access to mailboxes from multiple JMAP accounts through a single IMAP session SHOULD advertise the "OBJECTID=ACCOUNTID" capability to enable clients to distinguish between accounts. However, servers that provide access only to mailboxes from a single JMAP account MAY choose not to advertise this capability, as the account context is unambiguous in such cases.¶

Clients that support both IMAP and JMAP SHOULD use the ACCOUNTID when available to maintain accurate mappings between IMAP mailboxes and JMAP Mailbox objects. This is particularly important for clients that use JMAP Email Delivery Push notifications, as these notifications include the accountId property. By correlating the accountId from a push notification with the ACCOUNTID of IMAP mailboxes, clients can efficiently determine which IMAP mailbox corresponds to a newly delivered message without requiring additional synchronization operations.¶

Clients SHOULD be prepared to handle IMAP servers that do not advertise "OBJECTID=ACCOUNTID", even when the server advertises "JMAPACCESS". In such cases, clients MAY assume that all accessible mailboxes belong to a single JMAP account, though this assumption may lead to incorrect behavior if the server subsequently exposes mailboxes from additional accounts.¶

4. Security Considerations

The security considerations specified in Section 11 of [RFC8474] and Section 7 of [RFC9698] apply to this specification.¶

The introduction of the ACCOUNTID object identifier does not fundamentally alter the security properties of the IMAP protocol or the OBJECTID extension. However, implementers should consider the following additional points.¶

5. IANA Considerations

6. References

Appendix A. Changes

[[This section to be removed by RFC Editor]]¶

draft-degennaro-imap-objectid-accountid-00¶

• Initial version¶

Author's Address