Internet Engineering Task Force (IETF) A. Gulbrandsen
Request for Comments: 9698 ICANN
Category: Standards Track B. Gondwana
ISSN: 2070-1721 Fastmail
January 2025
This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via the JSON Meta Application Protocol (JMAP), and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client.
このドキュメントでは、IMAP拡張機能を定義して、このIMAPサーバーのメッセージがJSONメタアプリケーションプロトコル（JMAP）とその方法を介して利用できることをクライアントに知らせます。JMAPに徐々に移行したり、IMAPクライアント内のJMAP拡張機能を使用したりしたいクライアントを対象としています。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9698.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9698で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Details
4. The GETJMAPACCESS Command and the JMAPACCESS Response
5. Examples
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Authors' Addresses
An IMAP server can declare that the messages in its mailstore are also available via JMAP. For simplicity, only a complete equivalence is supported (the same set of messages are available via both IMAP and JMAP).
IMAPサーバーは、Mailstore内のメッセージがJMAPを介して利用できることを宣言できます。簡単にするために、完全な同等性のみがサポートされています（IMAPとJMAPの両方を介して同じメッセージセットが利用可能です）。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
By advertising the JMAPACCESS capability, the server asserts that if a mailbox or message has a particular object ID when accessed via either IMAP or JMAP (see [RFC3501], [RFC9051], and [RFC8620]), then the same mailbox or message is accessible via the other protocol, and it has the same ID.
JMAPACCESS機能を宣伝することにより、サーバーは、メールボックスまたはメッセージがIMAPまたはJMAPを介してアクセスしたときに特定のオブジェクトIDを持っている場合（[RFC3501]、[RFC9051]、および[RFC8620]）、同じメールボックスまたはメッセージが他のプロトコルからアクセス可能で、同じIDがあります。
The server MUST also advertise the OBJECTID extension, defined by [RFC8474]. The JMAP session resource that allows access to the same messages is called "the JMAP server" below.
サーバーは、[RFC8474]で定義されたObjectID拡張機能も宣伝する必要があります。同じメッセージへのアクセスを許可するJMAPセッションリソースは、以下の「JMAPサーバー」と呼ばれます。
This specification does not affect message lifetime: If a client accesses a message via IMAP and half a second later via JMAP, then the message may have been deleted between the two accesses.
この仕様はメッセージの寿命に影響しません。クライアントがIMAPを介してJMAPを介して半秒後にメッセージにアクセスした場合、2つのアクセスの間でメッセージが削除された可能性があります。
When the server processes the client's LOGIN/AUTHENTICATE command and enters Authenticated state, the server considers the way the client authenticated. If the IMAP server can infer from the client's authentication process that its credentials suffice to authenticate via JMAP, then the server MUST include a JMAPACCESS capability in any capability list sent after that point. This includes the capability list that some servers send immediately when authentication succeeds.
サーバーがクライアントのログイン/認証コマンドを処理し、認証状態に入力すると、サーバーはクライアントの認証方法を考慮します。IMAPサーバーがクライアントの認証プロセスから、その資格情報がJMAPを介して認証するのに十分であると推測できる場合、サーバーはその時点以降に送信された任意の機能リストにJMAPACCESS機能を含める必要があります。これには、認証が成功したときに一部のサーバーがすぐに送信する機能リストが含まれます。
Servers are encouraged to report the same message flags and other data via both protocols, as far as possible.
サーバーは、両方のプロトコルを介して同じメッセージフラグと他のデータを可能な限り報告することをお勧めします。
This specification does not require mailboxes to have the same name in IMAP and JMAP, even if they share a mailbox ID. However, the JMAP specification regulates that in the text about the name and role properties described in Section 2 of [RFC8620].
この仕様では、メールボックスIDを共有している場合でも、メールボックスはIMAPとJMAPで同じ名前を持つ必要はありません。ただし、JMAP仕様は、[RFC8620]のセクション2で説明されている名前と役割のプロパティについてテキストでそれを規制しています。
Note that all JMAP servers support internationalized email addresses (see [RFC6530]). If this IMAP server does not or if the IMAP client does not issue ENABLE UTF8=ACCEPT (see [RFC6855]), then it is possible that the client will receive accurate address fields via JMAP and downgraded fields via IMAP (see [RFC6857] and [RFC6858] for examples). Issuing ENABLE UTF8=ACCEPT is a simple way to sidestep the issue.
すべてのJMAPサーバーが国際化されたメールアドレスをサポートしていることに注意してください（[RFC6530]を参照）。このIMAPサーバーがそうでない場合、またはIMAPクライアントがUTF8 = Acceptを有効にしない場合（[RFC6855]を参照）、クライアントはJMAPを介して正確なアドレスフィールドを受け取り、IMAPを介して格下げされたフィールド（[RFC6857]を参照してください（[RFC6857]を参照）[RFC6858]例については）。Enable UTF8 = Acceptを発行することは、問題を回避する簡単な方法です。
The GETJMAPACCESS command requests that the server respond with the session URL for the JMAP server that provides access to the same mail.
getJMapaccessコマンドは、同じメールへのアクセスを提供するJMAPサーバーのセッションURLでサーバーが応答することを要求します。
If such a JMAP server is known to this server, the server MUST respond with an untagged JMAPACCESS response containing the JMAP server's session resource (a URL) followed by a tagged OK response.
このようなJMAPサーバーがこのサーバーに対して既知の場合、サーバーは、JMAPサーバーのセッションリソース（URL）を含む未編成のJMAPACCESS応答で応答する必要があります。
If such a JMAP server is not known, the server MUST respond with a tagged BAD response (and MUST NOT include JMAPACCESS in the capability list).
このようなJMAPサーバーが不明な場合、サーバーはタグ付きの悪い応答で応答する必要があります（機能リストにJMAPACCESを含めてはなりません）。
The JMAPACCESS response is followed by a single link to a JMAP session resource.
JMAPACCESS応答の後に、JMAPセッションリソースへの単一のリンクが続きます。
The formal syntax in [RFC9051] is extended as follows:
[RFC9051]の正式な構文は、次のように拡張されます。
command-auth =/ "GETJMAPACCESS"
mailbox-data =/ resp-jmapaccess
resp-jmapaccess = "JMAPACCESS" SP quoted
The syntax in [RFC3501] is extended similarly (this extension may be used with IMAP4rev1 as well as IMAP4rev2).
[RFC3501]の構文は同様に拡張されます（この拡張は、IMAP4REV1とIMAP4REV2で使用できます）。
Lines sent by the client are preceded by C: and lines sent by the server are preceded by S:. Each example starts with the IMAP banner issued by the server on connection, and generally abbreviates the capability lists to what's required by the example itself.
クライアントが送信した行の前にC：およびサーバーが送信した行の前にS：。各例は、接続でサーバーによって発行されたIMAPバナーから始まり、一般に、例自体が必要とするものに対して機能リストを省略します。
Real connections use longer capability lists, much longer AUTHENTICATE arguments and of course use TLS. However, these examples focus on JMAPACCESS.
実際の接続では、より長い機能リスト、はるかに長い認証引数を使用し、もちろんTLSを使用します。ただし、これらの例はjmapaccessに焦点を当てています。
Example 1:
例1：
A client connects, sees that SASL OAuth [RFC7628] is available, and authenticates in that way.
クライアントが接続し、SASL OAuth [RFC7628]が利用可能であることを確認し、そのように認証します。
S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1
C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB
The server processes the command successfully. It knows that the client used OAuth, and that it and its JMAP alter ego use the same OAuth backend subsystem. Because of that it infers that the (next) access token is just as usable via JMAP as via IMAP. It includes a JMAPACCESS capability in its reply (again, real capability lists are much longer):
サーバーはコマンドを正常に処理します。クライアントがOAuthを使用し、JMAPの分身が同じOAuth Backendサブシステムを使用していることを知っています。そのため、（次の）アクセストークンは、JMAPを介してIMAPを介して使用可能であると推測します。これには、返信にjmapaccess機能が含まれています（繰り返しますが、実際の機能リストははるかに長くなります）：
S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] done
C: 1b GETJMAPACCESS
S: * JMAPACCESS "https://example.com/.well-known/jmap"
S: 1b OK done
SASL OAuth is specified by [RFC7628], and the argument in this example is abbreviated from the more realistic length used in RFC 7628.
SASL OAuthは[RFC7628]で指定されており、この例の引数は、RFC 7628で使用されるより現実的な長さから略されます。
Example 2:
例2：
A client connects, sees no SASL method it recognizes, and issues a LOGIN command.
クライアントが接続し、認識しているSASLメソッドが表示され、ログインコマンドを発行します。
S: * OK [CAPABILITY IMAP4rev2] example2
C: 2 LOGIN "arnt" "trondheim"
The server sees that the password is accepted, knows that it and its JMAP alter ego use the same password database, and issues a JMAPACCESS capability:
サーバーは、パスワードが受け入れられていることを確認し、ITとそのJMAP Alter Egoが同じパスワードデータベースを使用していることを知っており、JMAPACCESS機能を発行します。
S: * OK [CAPABILITY IMAP4rev2 JMAPACCESS] done
S: 2 OK done
C: 2b JMAPACCESS
S: * JMAPACCESS "https://example.com/.well-known/jmap"
S: 2b OK done
The URL uses the same quoting rules as most other IMAP strings.
URLは、他のほとんどのIMAP文字列と同じ引用ルールを使用します。
Example 3:
例3：
A client connects, sees no SASL method it recognizes, and issues a LOGIN command with a correct password.
クライアントが接続し、認識しているSASLメソッドが表示されず、正しいパスワードでログインコマンドを発行します。
S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2] example3
C: 3 LOGIN "arnt" "trondheim"
The server operator has decided to disable password use with JMAP, but allow it for a while with IMAP to cater to older clients. Therefore, the login succeeds, but there is no JMAPACCESS capability.
サーバーオペレーターは、JMAPでパスワードの使用を無効にすることを決定しましたが、IMAPでしばらくの間、古いクライアントに対応することを許可します。したがって、ログインは成功しますが、JMAPACCESS機能はありません。
S: 3 OK done
Example 4:
例4：
A client connects, sees no SASL method it recognizes, and issues a LOGIN command. Its password is incorrect.
クライアントが接続し、認識しているSASLメソッドが表示され、ログインコマンドを発行します。そのパスワードは正しくありません。
S: * OK [CAPABILITY IMAP4rev2 AUTH=GSS] example4
C: 4 LOGIN "arnt" "oslo"
The server does not enter Authenticated state, so nothing requires it to mention JMAPACCESS. It replies curtly:
サーバーは認証された状態を入力しないため、jmapaccessに言及するために必要なものはありません。それはひどく答えます：
S: 4 NO done
The IANA has added the JMAPACCESS capability to the "Internet Message Access Protocol (IMAP) Capabilities Registry" and listed this document as the reference.
IANAは、JMAPACCESS機能を「インターネットメッセージアクセスプロトコル（IMAP）機能レジストリ」に追加し、このドキュメントを参照としてリストしました。
JMAPACCESS reveals to authenticated IMAP clients that they would be able to authenticate via JMAP using the same credentials and that the object IDs match.
JMAPACCESSは、同じ資格情報を使用してJMAPを介して認証できること、およびオブジェクトIDが一致することを認証したIMAPクライアントに明らかにします。
One does not normally reveal anything at all about authentication. However, if the client is an attacker, then the attacker is known to have valid credentials, and Section 2.2 of [RFC8620] tells the attacker how to find the revealed URL without the help of this extension. Therefore, it is believed that this document does not benefit an attacker noticeably, and its value for migration far outweighs its risk.
通常、認証については何も明らかにしません。ただし、クライアントが攻撃者である場合、攻撃者は有効な資格情報を持っていることが知られており、[RFC8620]のセクション2.2は、この拡張機能の助けなしに明らかになったURLを見つける方法を攻撃者に伝えます。したがって、この文書は攻撃者に著しく利益をもたらさないと考えられており、移行に対するその価値はそのリスクをはるかに上回っています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
2018, <https://www.rfc-editor.org/info/rfc8474>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
February 2012, <https://www.rfc-editor.org/info/rfc6530>.
[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
2013, <https://www.rfc-editor.org/info/rfc6855>.
[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for
Internationalized Email Messages", RFC 6857,
DOI 10.17487/RFC6857, March 2013,
<https://www.rfc-editor.org/info/rfc6857>.
[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,
March 2013, <https://www.rfc-editor.org/info/rfc6858>.
[RFC7628] Mills, W., Showalter, T., and H. Tschofenig, "A Set of
Simple Authentication and Security Layer (SASL) Mechanisms
for OAuth", RFC 7628, DOI 10.17487/RFC7628, August 2015,
<https://www.rfc-editor.org/info/rfc7628>.
[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
2019, <https://www.rfc-editor.org/info/rfc8620>.
Arnt Gulbrandsen
ICANN
6 Rond Point Schumann, Bd. 1
1040 Brussels
Belgium
Email: arnt@gulbrandsen.priv.no
URI: https://icann.org/ua
Bron Gondwana
Fastmail
Level 2, 114 William St.
Melbourne VIC 3000
Australia
Email: brong@fastmailteam.com
URI: https://fastmail.com