[要約] RFC 8508はIMAP REPLACE拡張機能に関する仕様であり、既存のメッセージを置き換えるための新しいコマンドを定義しています。目的は、メッセージの一部を変更する際に、完全なメッセージを再送信する必要なく、効率的に変更を行うことです。
Internet Engineering Task Force (IETF) S. Brandt
Request for Comments: 8508 Verizon
Category: Standards Track January 2019
ISSN: 2070-1721
IMAP REPLACE Extension
IMAP REPLACE拡張
Abstract
概要
This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.
このドキュメントでは、メッセージストア内の既存のメッセージを新しいメッセージに置き換えるために使用できるIMAP拡張機能を定義しています。メッセージの置換は、下書きやメモをユーザーが作成するときに自動的に保存するクライアントの一般的な操作です。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8508.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8508で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . 3
3.1. Advertising Support for REPLACE . . . . . . . . . . . . . 3
3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3
3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4
3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 5
3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6
4. Interaction with Other Extensions . . . . . . . . . . . . . . 6
4.1. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. CATENATE . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. UIDPLUS . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. IMAP Events in Sieve . . . . . . . . . . . . . . . . . . 8
4.5. CONDSTORE/QRESYNC . . . . . . . . . . . . . . . . . . . . 8
4.6. OBJECTID . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. MULTIAPPEND . . . . . . . . . . . . . . . . . . . . . . . 8
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
This document defines an IMAP ([RFC3501]) extension to facilitate the replacement of an existing message with a new one. This is accomplished by defining a new REPLACE command and extending the Unique Identifier (UID) command to allow UID REPLACE.
このドキュメントでは、IMAP（[RFC3501]）拡張を定義して、既存のメッセージを新しいメッセージに簡単に置き換えることができるようにしています。これは、新しいREPLACEコマンドを定義し、Unique Identifier（UID）コマンドを拡張してUID REPLACEを許可することによって実現されます。
Since there is no replace function in the base IMAP specification, clients have instead had to use a combination of three separate commands issued in serial fashion; APPEND, STORE, and EXPUNGE. Pipelining of these three commands is not recommended since failure of any individual command should prevent subsequent commands from being executed lest the original message version be lost.
基本IMAP仕様には置換機能がないため、クライアントは代わりに、シリアル方式で発行された3つの個別のコマンドの組み合わせを使用する必要がありました。 APPEND、STORE、およびEXPUNGE。個々のコマンドが失敗すると、元のメッセージバージョンが失われないように後続のコマンドが実行されないようにするため、これら3つのコマンドのパイプライン処理はお勧めしません。
Because of the non-atomic nature of the existing sequence, interruptions can leave messages in intermediate states that can be seen and acted upon by other clients. Such interruptions can also strand older revisions of messages, thereby forcing the user to manually clean up multiple revisions of the same message in order to avoid wasteful quota consumption. Additionally, the existing sequence can fail on APPEND due to an over-quota condition even though the subsequent STORE/EXPUNGE would free up enough space for the newly revised message. And finally, server efficiencies may be possible with a single logical message replacement operation as compared to the existing APPEND/STORE/EXPUNGE sequence.
既存のシーケンスの非アトミックな性質のため、割り込みによってメッセージが中間状態のままになり、他のクライアントによって表示および操作される可能性があります。このような中断により、メッセージの古いリビジョンが取り残される可能性があるため、ユーザーは、同じメッセージの複数のリビジョンを手動でクリーンアップして、無駄なクォータの消費を回避する必要があります。さらに、後続のSTORE / EXPUNGEが新しく改訂されたメッセージのために十分なスペースを解放する場合でも、割り当て超過状態が原因で既存のシーケンスがAPPENDで失敗する可能性があります。そして最後に、サーバーの効率は、既存のAPPEND / STORE / EXPUNGEシーケンスと比較して、単一の論理メッセージ置換操作で可能になる場合があります。
In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED, and UID EXPUNGE for a message, except that it avoids any of the quota implications or intermediate states associated with the three-command sequence. Server developers are encouraged to implement REPLACE as an atomic operation to simplify error handling, minimize operational concerns, and reduce potential security problems. For systems where this is not possible, communication with the requesting client must ensure no confusion of message store state. A server MUST NOT generate a response code for the STORE +flags \DELETED portion of the sequence. Additionally, servers supporting the REPLACE command MUST NOT infer any inheritance of content, flags, or annotations from the message being replaced.
最も簡単な形式では、REPLACEコマンドは、メッセージのAPPEND、STORE + flags \ DELETED、およびUID EXPUNGEの単一コマンドのカプセル化ですが、3つのコマンドシーケンスに関連付けられているクォータの影響や中間状態を回避します。サーバー開発者は、エラー処理を単純化し、操作上の懸念を最小限に抑え、潜在的なセキュリティ問題を軽減するために、原子操作としてREPLACEを実装することをお勧めします。これが不可能なシステムの場合、要求元クライアントとの通信は、メッセージストアの状態の混乱を防ぐ必要があります。サーバーは、シーケンスのSTORE + flags \ DELETED部分の応答コードを生成してはなりません（MUST NOT）。さらに、REPLACEコマンドをサポートするサーバーは、置き換えられるメッセージからコンテンツ、フラグ、または注釈の継承を推測してはなりません（MUST NOT）。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Formal syntax is defined by [RFC5234].
正式な構文は[RFC5234]で定義されています。
Example lines prefaced by "C:" are sent by the client, and ones prefaced by "S:" are sent by the server.
「C：」で始まる行の例はクライアントによって送信され、「S：」で始まる行はサーバーによって送信されます。
Servers that implement the REPLACE extension will return "REPLACE" as one of the supported capabilities in the CAPABILITY command response.
REPLACE拡張機能を実装するサーバーは、CAPABILITYコマンド応答でサポートされる機能の1つとして「REPLACE」を返します。
Arguments: message sequence number mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
引数：メッセージシーケンス番号メールボックス名オプションのフラグ括弧で囲まれたリストオプションの日付/時刻文字列メッセージリテラル
Responses: no specific responses for this command Result: OK - replace completed NO - replace error; can't remove specified message or can't add new message content BAD - command unknown or arguments invalid
応答：このコマンドに対する特定の応答はありません結果：OK-完了した置換NO-置換エラー。指定されたメッセージを削除できない、または新しいメッセージコンテンツを追加できないBAD-コマンドが不明または引数が無効
Example:
C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822388-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C:
S: * OK [APPENDUID 1 2000] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A003 OK Replace completed
This extends the first form of the UID command (see Section 6.4.8 of [RFC3501]) to add the REPLACE command defined above as a valid argument. This form of REPLACE uses a UID rather than a sequence number as its first parameter.
これにより、UIDコマンドの最初の形式が拡張され（[RFC3501]のセクション6.4.8を参照）、上記で定義したREPLACEコマンドが有効な引数として追加されます。この形式のREPLACEは、最初のパラメーターとしてシーケンス番号ではなくUIDを使用します。
Example:
C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822389-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C: Hopefully next year you can join us.
C:
S: * OK [APPENDUID 1 2001] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A004 OK Replace completed
The REPLACE and UID REPLACE commands take five arguments: a message identifier, a named mailbox, an optional parenthesized flag list, an optional message date/time string, and a message literal. The message literal will be appended to the named mailbox, and the message specified by the message identifier will be removed from the selected mailbox. These operations will appear to the client as a single action. This has the same effect as the following sequence:
REPLACEおよびUID REPLACEコマンドは5つの引数を取ります。メッセージ識別子、名前付きメールボックス、オプションの括弧付きフラグリスト、オプションのメッセージ日付/時刻文字列、メッセージリテラルです。メッセージリテラルは指定されたメールボックスに追加され、メッセージ識別子で指定されたメッセージは選択されたメールボックスから削除されます。これらの操作は、単一のアクションとしてクライアントに表示されます。これは、次のシーケンスと同じ効果があります。
1. APPEND 2. [UID] STORE +FLAGS.SILENT \DELETED 3. UID EXPUNGE
1. 付録2. [UID] STORE + FLAGS.SILENT \ DELETED 3. UID削除
In the cited sequence, the quota implications of APPEND are evaluated within the context of the pending EXPUNGE so that only the net quota consumption is considered. Additionally, the EXPUNGE portion of the sequence only applies to the specified message, not all messages flagged as "\Deleted".
引用されたシーケンスでは、APPENDの割り当ての影響が保留中のEXPUNGEのコンテキスト内で評価されるため、正味の割り当ての消費のみが考慮されます。さらに、シーケンスのEXPUNGE部分は指定されたメッセージにのみ適用され、「\ Deleted」のフラグが付いたすべてのメッセージには適用されません。
Although the effect of REPLACE is identical to the steps above, the semantics are not identical; similar to MOVE [RFC6851], the intermediate states do not occur and the response codes are different. In particular, the response codes for APPEND and EXPUNGE will be returned while those for the STORE operation MUST NOT be generated.
REPLACEの効果は上記の手順と同じですが、セマンティクスは同じではありません。 MOVE [RFC6851]と同様に、中間状態は発生せず、応答コードが異なります。特に、APPENDおよびEXPUNGEの応答コードが返されますが、STOREオペレーションの応答コードは生成してはなりません（MUST NOT）。
When an error occurs while processing REPLACE or UID REPLACE, the server MUST NOT leave the selected mailbox in an inconsistent state; any untagged EXPUNGE response MUST NOT be sent until all actions are successfully completed.
REPLACEまたはUID REPLACEの処理中にエラーが発生した場合、サーバーは選択されたメールボックスを不整合な状態のままにしてはなりません（MUST NOT）。タグの付いていないEXPUNGE応答は、すべてのアクションが正常に完了するまで送信してはなりません。
While it may be common for the named mailbox argument to match the selected mailbox for the common use case of replacing a draft, the REPLACE extension intentionally does not require the two to be the same. As an example, it's possible to use the REPLACE command to replace a message in the \Drafts special-use mailbox (see Section 2 of [RFC6154]) with a message in the \Sent special-use mailbox following message submission.
名前付きメールボックスの引数が、下書きを置き換える一般的な使用例の選択されたメールボックスと一致することはよくありますが、REPLACE拡張機能では、意図的に2つが同じである必要はありません。例として、REPLACEコマンドを使用して、\ Drafts特殊用途メールボックス（[RFC6154]のセクション2を参照）のメッセージを、メッセージ送信後に\ Sent特殊用途メールボックスのメッセージで置き換えることができます。
Because of the similarity of REPLACE to APPEND, extensions that affect APPEND affect REPLACE in the same way. Response codes such as TRYCREATE (see Section 6.3.11 of [RFC3501]), along with those defined by extensions, are sent as appropriate. See Section 4 for more information about how REPLACE interacts with other IMAP extensions.
APPENDとREPLACEは類似しているため、APPENDに影響する拡張機能はREPLACEにも同じように影響します。 TRYCREATE（[RFC3501]のセクション6.3.11を参照）などの応答コードは、拡張機能によって定義されたコードとともに、必要に応じて送信されます。 REPLACEが他のIMAP拡張機能と相互作用する方法の詳細については、セクション4を参照してください。
Unlike the APPEND command, which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since REPLACE operates on message sequence numbers. Additionally, the REPLACE extension intentionally follows the convention for UID commands found in Section 6.4.8 of [RFC3501] in that the UID variant of the command does not support use from the authenticated state.
認証された状態で有効なAPPENDコマンドとは異なり、REPLACEおよびUID REPLACEコマンドは選択された状態でのみ有効でなければなりません。 REPLACEはメッセージのシーケンス番号を操作するため、APPENDとのこの違いが必要です。さらに、REPLACE拡張機能は、[RFC3501]のセクション6.4.8にあるUIDコマンドの規則に従って、コマンドのUIDバリアントは認証された状態からの使用をサポートしないという意図に従っています。
This section describes how REPLACE interacts with some other IMAP extensions.
このセクションでは、REPLACEが他のIMAP拡張機能とどのように相互作用するかについて説明します。
The Access Control List (ACL) rights [RFC4314] required for UID REPLACE are the union of the ACL rights required for UID STORE and UID EXPUNGE in the current mailbox, and APPEND in the target mailbox.
UID REPLACEに必要なアクセス制御リスト（ACL）権限[RFC4314]は、現在のメールボックスのUID STOREとUID EXPUNGEに必要なACL権限、およびターゲットメールボックスのAPPENDの和集合です。
Servers supporting both REPLACE and CATENATE [RFC4469] MUST support the additional append-data and resp-text-code elements defined in Section 5 ("Formal Syntax") of [RFC4469] in conjunction with the REPLACE command. When combined with CATENATE, REPLACE can become quite an efficient way of message manipulation.
REPLACEとCATENATE [RFC4469]の両方をサポートするサーバーは、REPLACEコマンドとともに[RFC4469]のセクション5（「正式な構文」）で定義された追加のappend-data要素とresp-text-code要素をサポートする必要があります。 CATENATEと組み合わせると、REPLACEはメッセージ操作の非常に効率的な方法になります。
Example:
例：
User composes message and attaches photo
----------------------------------------
C: A010 APPEND Drafts (\Seen \Draft) {1201534}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Message-ID: <B238822388-0100003@example.org>
C: MIME-Version: 1.0
C: Content-Type: multipart/mixed;
C: boundary="------------030305060306060609050804"
C:
C: --------------030305060306060609050804
C: Content-Type: text/plain; charset=utf-8; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Here is picture from the fireworks
C:
C: Yours...
C: Fritz
C:
C: --------------030305060306060609050804
C: Content-Type: image/jpeg;
C: name="Fireworks.jpg"
C: Content-Transfer-Encoding: base64
C: Content-Disposition: attachment;
C: filename="Fireworks.jpg"
C:
<large base64 encoded part goes here>
C:
C: --------------030305060306060609050804--
S: A010 OK [APPENDUID 1 3002] APPEND complete
User completes message with To: and Subject: fields
---------------------------------------------------
C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
S: + Ready for literal data
C: To: Mitzy <miss.mitzy@example.org>
C: Subject: My view of the fireworks
C: URL "/Drafts/;UID=3002")
S: * OK [APPENDUID 1 3003] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A011 OK REPLACE completed
Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send APPENDUID in response to a UID REPLACE command. For additional information, see Section 3 of [RFC4315]. Servers implementing REPLACE and UIDPLUS are also advised to send the APPENDUID response code in an untagged OK before sending the EXPUNGE or replaced responses. (Sending APPENDUID in the tagged OK as described in the UIDPLUS specification means that the client first receives EXPUNGE for a message and afterwards APPENDUID for the new message. It can be unnecessarily difficult to process that sequence usefully.)
REPLACEとUIDPLUSの両方をサポートするサーバー[RFC4315]は、UID REPLACEコマンドに応答してAPPENDUIDを送信する必要があります（SHOULD）。詳細については、[RFC4315]のセクション3をご覧ください。 REPLACEおよびUIDPLUSを実装するサーバーは、EXPUNGEまたは置換された応答を送信する前に、タグなしOKでAPPENDUID応答コードを送信することもお勧めします。 （UIDPLUS仕様で説明されているようにタグ付きOKでAPPENDUIDを送信するということは、クライアントが最初にメッセージのEXPUNGEを受信し、その後に新しいメッセージのAPPENDUIDを受信することを意味します。
REPLACE applies to IMAP events in Sieve [RFC6785] in the same way that APPEND does. Therefore, REPLACE can cause a Sieve script to be invoked with the imap.cause set to "APPEND". Because the intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by REPLACE, no action will be taken that results in an imap.cause of FLAG.
REPLACEはAPPENDと同じ方法でSieve [RFC6785]のIMAPイベントに適用されます。したがって、REPLACEにより、imap.causeを "APPEND"に設定してSieveスクリプトを呼び出すことができます。 STORE + FLAGS.SILENT \ DELETEDの中間状態はREPLACEによって公開されないため、FLAGのimap.causeを引き起こすアクションは実行されません。
Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] MUST treat the message being replaced as if it were being removed with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of [RFC7162] are particularly relevant for this condition.
REPLACEとCONDSTORE / QRESYNC [RFC7162]の両方を実装するサーバーは、置き換えられるメッセージを、UID EXPUNGEコマンドで削除されたものとして扱う必要があります。 [RFC7162]のセクション3.2.9および3.2.10は、この状態に特に関連しています。
Servers implementing both REPLACE and OBJECTID [RFC8474] MUST return different EMAILIDs for both the replaced and replacing messages. The only exception to this is the case outlined in Section 5.1 ("EMAILID Identifier for Identical Messages") of [RFC8474] when the server detects that both messages' immutable content is identical.
REPLACEとOBJECTID [RFC8474]の両方を実装するサーバーは、置換されたメッセージと置換されたメッセージの両方に対して異なるEMAILIDを返さなければなりません（MUST）。これの唯一の例外は、[RFC8474]のセクション5.1（「同一メッセージのメールID」）で概説されているケースで、サーバーが両方のメッセージの不変コンテンツが同一であることを検出した場合です。
The REPLACE extension has no interaction with MULTIAPPEND [RFC3502]. This document explicitly does not outline a method for replacing multiple messages concurrently.
REPLACE拡張機能は、MULTIAPPEND [RFC3502]との相互作用がありません。このドキュメントでは、複数のメッセージを同時に置き換える方法を明確に説明していません。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability","command-select", "mailbox", "seq-number", and "uid". [RFC4466] defines the non-terminal "append-message".
次の構文仕様は、[RFC5234]で指定されているAugmented Backus-Naur Form（ABNF）表記を使用しています。 [RFC3501]は、非端末の「機能」、「コマンド選択」、「メールボックス」、「シーケンス番号」、および「uid」を定義します。 [RFC4466]は非終端の "append-message"を定義しています。
Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特に明記しない限り、すべてのアルファベット文字は大文字と小文字を区別しません。トークン文字列を定義するための大文字または小文字の使用は、編集上の明確さのためだけです。実装は、大文字と小文字を区別しない方法でこれらの文字列を受け入れる必要があります。
capability =/ "REPLACE"
機能= / "置換"
command-select =/ replace
replace = "REPLACE" SP seq-number SP mailbox append-message
uid =/ "UID" SP replace
This document is believed to add no security problems beyond those that may already exist with the base IMAP specification. The REPLACE command may actually prevent some potential security problems because it avoids intermediate message states that could possibly be exploited by an attacker.
このドキュメントは、基本のIMAP仕様ですでに存在する可能性がある問題以外にセキュリティの問題を追加しないと考えられています。 REPLACEコマンドは、攻撃者に悪用される可能性のある中間メッセージの状態を回避するため、実際には潜在的なセキュリティの問題を防ぐことができます。
The IANA has added REPLACE to the "IMAP Capabilities" registry at <https://www.iana.org/assignments/imap-capabilities>.
IANAは、<https://www.iana.org/assignments/imap-capabilities>の「IMAP Capabilities」レジストリにREPLACEを追加しました。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<https://www.rfc-editor.org/info/rfc3501>。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, <https://www.rfc-editor.org/info/rfc4314>.
[RFC4314] Melnikov、A。、「IMAP4 Access Control List（ACL）Extension」、RFC 4314、DOI 10.17487 / RFC4314、2005年12月、<https://www.rfc-editor.org/info/rfc4314>。
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, <https://www.rfc-editor.org/info/rfc4315>.
[RFC4315] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP）-UIDPLUS拡張」、RFC 4315、DOI 10.17487 / RFC4315、2005年12月、<https://www.rfc-editor.org/info/rfc4315>。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, <https://www.rfc-editor.org/info/rfc4466>.
[RFC4466] Melnikov、A。およびC. Daboo、「IMAP4 ABNFに対する収集された拡張機能」、RFC 4466、DOI 10.17487 / RFC4466、2006年4月、<https://www.rfc-editor.org/info/rfc4466>。
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 2006, <https://www.rfc-editor.org/info/rfc4469>.
[RFC4469] Resnick、P。、「インターネットメッセージアクセスプロトコル（IMAP）CATENATE拡張機能」、RFC 4469、DOI 10.17487 / RFC4469、2006年4月、<https://www.rfc-editor.org/info/rfc4469>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC6785] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, November 2012, <https://www.rfc-editor.org/info/rfc6785>.
[RFC6785] Leiba、B。、「Sieveでのインターネットメッセージアクセスプロトコル（IMAP）イベントのサポート」、RFC 6785、DOI 10.17487 / RFC6785、2012年11月、<https://www.rfc-editor.org/info/rfc6785 >。
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/RFC7162, May 2014, <https://www.rfc-editor.org/info/rfc7162>.
[RFC7162] Melnikov、A。およびD. Cridland、「IMAP Extensions：Quick Flag Changes Resynchronization（CONDSTORE）and Quick Mailbox Resynchronization（QRESYNC）」、RFC 7162、DOI 10.17487 / RFC7162、2014年5月、<https：// www。 rfc-editor.org/info/rfc7162>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8474] Gondwana、B。、編、「オブジェクト識別子のIMAP拡張機能」、RFC 8474、DOI 10.17487 / RFC8474、2018年9月、<https://www.rfc-editor.org/info/rfc8474>。
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, March 2003, <https://www.rfc-editor.org/info/rfc3502>.
[RFC3502] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP）-MULTIAPPEND拡張機能」、RFC 3502、DOI 10.17487 / RFC3502、2003年3月、<https://www.rfc-editor.org/info/rfc3502>。
[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, March 2011, <https://www.rfc-editor.org/info/rfc6154>.
[RFC6154] Leiba、B。およびJ. Nicolson、「IMAP LIST Extension for Special-Use Mailboxes」、RFC 6154、DOI 10.17487 / RFC6154、March 2011、<https://www.rfc-editor.org/info/rfc6154 >。
[RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, <https://www.rfc-editor.org/info/rfc6851>.
[RFC6851] Gulbrandsen、A。およびN. Freed、編、「インターネットメッセージアクセスプロトコル（IMAP）-MOVE拡張機能」、RFC 6851、DOI 10.17487 / RFC6851、2013年1月、<https：//www.rfc-editor。 org / info / rfc6851>。
Acknowledgements
謝辞
The author would like to thank the participants of IMAPEXT with particular thanks to Arnt Gulbrandsen, Alexey Melnikov, Chris Newman, and Bron Gondwana for their specific contributions.
著者は、IMAPEXTの参加者に特に貢献してくれたArnt Gulbrandsen、Alexey Melnikov、Chris Newman、およびBron Gondwanaに感謝します。
Author's Address
著者のアドレス
Stuart Brandt Verizon 22001 Loudoun County Parkway Ashburn, VA 20147 United States of America
Stuart Brandt Verizon 22001 Loudoun County Parkway Ashburn、VA 20147アメリカ合衆国
Email: stujenerin@aol.com