Internet Engineering Task Force (IETF) P. Resnick
Request for Comments: 9755 Episteme
Obsoletes: 6855 J. Yao
Category: Standards Track CNNIC
ISSN: 2070-1721 A. Gulbrandsen
ICANN
March 2025
This specification extends the Internet Message Access Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2 (RFC 9051), since that protocol includes everything in this extension.
この仕様により、インターネットメッセージアクセスプロトコル、特にIMAP4REV1（RFC 3501）が拡張され、UTF-8エンコードされた国際文字がユーザー名、メールアドレス、メッセージヘッダーをサポートします。この仕様はRFC 6855に置き換えられます。この仕様は、IMAP4REV2（RFC 9051）を拡張しません。そのプロトコルにはこの拡張機能のすべてが含まれているためです。
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/rfc9755.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9755で取得できます。
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. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings
4. "APPEND" Command
5. "LOGIN" Command and UTF-8
6. FETCH BODYSTRUCTURE and message/global
7. "UTF8=ONLY" Capability
8. Dealing with Legacy Clients
9. Issues with UTF-8 Header Mailstore
10. IANA Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Design Rationale
Appendix B. Changes Since RFC 6855
B.1. APPEND UTF8
B.2. FETCH BODYSTRUCTURE
Acknowledgments
Authors' Addresses
This specification forms part of the Email Address Internationalization protocols described in the Email Address Internationalization Framework document [RFC6530]. It extends IMAP [RFC3501] to permit UTF-8 [RFC3629] in headers, as described in "Internationalized Email Headers" [RFC6532]. It also adds a mechanism to support mailbox names using the UTF-8 charset. This specification creates two new IMAP capabilities to allow servers to advertise these new extensions.
この仕様は、電子メールアドレス国際化フレームワークドキュメント[RFC6530]で説明されている電子メールアドレスの国際化プロトコルの一部を形成します。「国際化されたメールヘッダー」[RFC6532]に記載されているように、ヘッダーでUTF-8 [RFC3629]を許可するようにIMAP [RFC3501]を拡張します。また、UTF-8チャーセットを使用してメールボックス名をサポートするメカニズムを追加します。この仕様では、サーバーがこれらの新しい拡張機能を宣伝できるようにする2つの新しいIMAP機能を作成します。
This specification assumes that the IMAP server will be operating in a fully internationalized environment, i.e., one in which all clients accessing the server will be able to accept non-ASCII message header fields and other information, as specified in Section 3. At least during a transition period, that assumption will not be realistic for many environments; the issues involved are discussed in Section 7 below.
この仕様は、IMAPサーバーが完全に国際化された環境で動作することを前提としています。つまり、サーバーにアクセスするすべてのクライアントが、セクション3で指定されているように、ASCIIメッセージヘッダー以外の情報やその他の情報を受け入れることができます。少なくとも移行期間中、その仮定は多くの環境で現実的ではありません。関係する問題については、以下のセクション7で説明します。
This specification replaces an earlier, experimental approach to the same problem; see [RFC5738] as well as [RFC6855].
この仕様は、同じ問題に対する以前の実験的アプローチを置き換えます。[RFC5738]および[RFC6855]を参照してください。
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] で説明されているように解釈されます。
The "UTF8=ACCEPT" capability indicates that the server supports the ability to open mailboxes containing internationalized messages with the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8 responses to the "LIST" and "LSUB" commands. This capability also affects other IMAP extensions that can return mailbox names or their prefixes, such as NAMESPACE [RFC2342] and ACL [RFC4314].
「UTF8 = Accept」機能は、サーバーが「Select」および「Examine」コマンドを使用して国際化されたメッセージを含むメールボックスを開く機能をサポートしており、サーバーは「リスト」および「LSUB」コマンドにUTF-8応答を提供できることを示しています。この機能は、名前空間[RFC2342]やACL [RFC4314]などのメールボックス名またはそのプレフィックスを返すことができる他のIMAP拡張機能にも影響します。
The "UTF8=ONLY" capability, described in Section 7, implies the "UTF8=ACCEPT" capability. A server is said to support "UTF8=ACCEPT" if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".
セクション7で説明されている「UTF8 = Only」機能は、「UTF8 = Accept」機能を意味します。サーバーは、「UTF8 = Accept」または「UTF8 = Only」のいずれかを宣伝する場合、「UTF8 = Accept」をサポートすると言われています。
A client MUST use the "ENABLE" command [RFC5161] with the "UTF8=ACCEPT" option (defined in Section 4 below) to indicate to the server that the client accepts UTF-8 in quoted-strings and supports the "UTF8=ACCEPT" extension. The "ENABLE UTF8=ACCEPT" command is only valid in the authenticated state.
クライアントは、「UTF8 = Accept」オプション（以下のセクション4で定義）を備えた「Enable」コマンド[RFC5161]を使用して、クライアントが引用符でYUTF-8を受け入れ、「UTF8 = Accept」拡張子をサポートすることをサーバーに示す必要があります。「UTF8 = Accept」コマンドは、認証された状態でのみ有効です。
The IMAP base specification [RFC3501] forbids the use of 8-bit characters in atoms or quoted-strings. Thus, a UTF-8 string can only be sent as a literal. This can be inconvenient from a coding standpoint, and unless the server offers IMAP non-synchronizing literals [RFC7888], this requires an extra round trip for each UTF-8 string sent by the client. When the IMAP server supports "UTF8=ACCEPT", it supports UTF-8 in quoted-strings with the following ABNF syntax [RFC5234]:
IMAPベース仕様[RFC3501]は、原子または引用された弦での8ビット文字の使用を禁止しています。したがって、UTF-8文字列はリテラルとしてのみ送信できます。これはコーディングの観点からも不便であり、サーバーが非同期リテラル[RFC7888]をIMAPに提供しない限り、クライアントが送信する各UTF-8文字列に追加の往復が必要です。IMAPサーバーが「UTF8 = Accept」をサポートすると、次のABNF構文[RFC5234]で引用されたストリングスのUTF-8をサポートします。
quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE
; QUOTED-CHAR is not modified, as it will affect
; other RFC 3501 ABNF non-terminals.
uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <Defined in Section 4 of RFC 3629>
UTF8-4 = <Defined in Section 4 of RFC 3629>
When this extended quoting mechanism is used by the client, the server MUST reject, with a "BAD" response, any octet sequences with the high bit set that fail to comply with the formal syntax requirements of UTF-8 [RFC3629]. The IMAP server MUST NOT send UTF-8 in quoted-strings to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command.
この拡張された引用メカニズムがクライアントによって使用される場合、サーバーは「悪い」応答で、UTF-8の正式な構文要件に準拠していないハイビットセットのオクテットシーケンスを拒否する必要があります[RFC3629]。IMAPサーバーは、「enable utf8 = accept」コマンドを使用して、クライアントがその構文のサポートを示していない限り、クライアントに引用されたストリングでUTF-8を送信してはなりません。
If the server supports "UTF8=ACCEPT", the client MAY use extended quoted syntax with any IMAP argument that permits a string (including astring and nstring). However, if characters outside the US-ASCII repertoire are used in an inappropriate place, the results would be the same as if other syntactically valid but semantically invalid characters were used. Specific cases where UTF-8 characters are permitted or not permitted are described in the following paragraphs.
サーバーが「UTF8 = Accept」をサポートしている場合、クライアントは、文字列（AstringおよびNSTRingを含む）を許可するIMAP引数で拡張された引用符の構文を使用できます。ただし、US-ASCIIレパートリーの外側の文字が不適切な場所で使用されている場合、結果は他の構文的に有効であるが、セマンティックに無効な文字が使用されているかどうかと同じです。UTF-8文字が許可されているか許可されていない特定のケースについては、次の段落に記載されています。
All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in mailbox names, and those that also support the Mailbox International Naming Convention described in [RFC3501], Section 5.1.3, MUST accept UTF-8 in mailbox names and convert them to the appropriate internal format. Mailbox names MUST comply with the Net-Unicode Definition ([RFC5198], Section 2) with the specific exception that they MUST NOT contain control characters (U+0000 - U+001F and U+0080 - U+009F), a delete character (U+007F), a line separator (U+2028), or a paragraph separator (U+2029).
「UTF8 = Accept」をサポートするすべてのIMAPサーバーは、メールボックス名でUTF-8を受け入れる必要があります。また、[RFC3501]、セクション5.1.3に記載されているメールボックス国際命名規則もサポートするものは、メールボックス名でUTF-8を受け入れ、適切な内部形式に変換する必要があります。メールボックス名は、コントロール文字（U+0000 -U+001FおよびU+0080 -U+009F）、削除文字（U+007F）、ラインセパレーター（U+2028）、またはライン分離器（U+2029）を含めてはならないという特定の例外を除いて、ネットユニコード定義（[RFC5198]、セクション2）に準拠する必要があります。
Once an IMAP client has enabled UTF-8 support with the "ENABLE UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that contains a charset specification. If an IMAP server receives such a "SEARCH" command in that situation, it SHOULD reject the command with a "BAD" response (due to the conflicting charset labels). This also applies to any IMAP command or extension that includes an optional charset label and associated strings in the command arguments, including the MULTISEARCH extension. For commands with a mandatory charset field, such as SORT and THREAD, servers SHOULD reject charset values other than UTF-8 with a "BAD" response (due to the conflicting charset labels).
IMAPクライアントが「UTF8 = Accept」コマンドを使用してUTF-8サポートを有効にしたら、CharSet仕様を含む「検索」コマンドを発行してはなりません。IMAPサーバーがそのような状況でそのような「検索」コマンドを受信した場合、「競合するチャーセットラベルのため）（悪い」応答でコマンドを拒否する必要があります。これは、MultiSearch Extensionを含むコマンド引数のオプションのCharSetラベルと関連する文字列を含むIMAPコマンドまたは拡張機能にも適用されます。ソートやスレッドなどの必須のチャーセットフィールドを持つコマンドの場合、サーバーは「悪い」応答を持つUTF-8以外のcharset値を拒否する必要があります（競合するcharsetラベルのため）。
If the server supports "UTF8=ACCEPT", then the server accepts UTF-8 headers in the "APPEND" command message argument.
サーバーが「UTF8 = Accept」をサポートする場合、サーバーは「Append」コマンドメッセージ引数でUTF-8ヘッダーを受け入れます。
If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not issued the "ENABLE UTF8=ACCEPT" command, the server MUST reject, with a "NO" response, an "APPEND" command that includes any 8-bit character in message header fields.
IMAPサーバーが「UTF8 = Accept」をサポートし、IMAPクライアントが「UTF8 = Accept」コマンドを発行していない場合、サーバーは「no」応答、メッセージヘッダーフィールドに8ビット文字を含む「append」コマンドを拒否する必要があります。
This specification does not extend the IMAP "LOGIN" command [RFC3501] to support UTF-8 usernames and passwords. Whenever a client needs to use UTF-8 usernames or passwords, it MUST use the IMAP "AUTHENTICATE" command, which is already capable of passing UTF-8 usernames and credentials.
この仕様では、UTF-8のユーザー名とパスワードをサポートするために、IMAP「ログイン」コマンド[RFC3501]を拡張しません。クライアントがUTF-8のユーザー名またはパスワードを使用する必要がある場合はいつでも、UTF-8ユーザー名と資格情報を既に渡すことができるIMAP「認証」コマンドを使用する必要があります。
Although using the IMAP "AUTHENTICATE" command in this way makes it syntactically legal to have a UTF-8 username or password, there is no guarantee that the user provisioning system utilized by the IMAP server will allow such identities. This is an implementation decision and may depend on what identity system the IMAP server is configured to use.
この方法でIMAPの「認証」コマンドを使用すると、UTF-8のユーザー名またはパスワードを持つことが構文的に合法的になりますが、IMAPサーバーが使用するユーザープロビジョニングシステムがそのようなアイデンティティを許可するという保証はありません。これは実装決定であり、IMAPサーバーが使用するように設定されているIDシステムに依存する場合があります。
[RFC9051], Section 7.5.2 treats message/global like message/rfc, which means that for some messages, the response to FETCH BODYSTRUCTURE varies depending on whether IMAP4rev1 or IMAP4rev2 is in use.
[RFC9051]、セクション7.5.2はメッセージ/グローバルのようなメッセージ/RFCを扱います。つまり、一部のメッセージでは、ボディ構造への応答はIMAP4REV1またはIMAP4REV2が使用されているかによって異なります。
[RFC6855] does not extend [RFC3501] in this respect. This document extends the media-message ABNF production to match [RFC9051].
[RFC6855]は、この点で[RFC3501]を拡張しません。このドキュメントは、メディアメサージABNFの生成を拡張して[RFC9051]と一致させます。
media-message = DQUOTE "MESSAGE" DQUOTE SP
DQUOTE ("RFC822" / "GLOBAL") DQUOTE
When IMAP4rev1 and UTF8=ACCEPT has been enabled, the server MAY treat message/global like message/rfc822 when computing the body structure, but MAY also treat it as described in [RFC3501]. Clients MUST accept both cases.
IMAP4REV1およびUTF8 = Acceptが有効になっている場合、サーバーはボディ構造を計算するときにメッセージ/グローバルのようなメッセージ/RFC822を扱うことができますが、[RFC3501]に記載されているように扱うこともあります。クライアントは両方のケースを受け入れる必要があります。
When IMAP4rev2 and UTF8=ACCEPT are in use, the server MUST behave as described in [RFC9051].
IMAP4REV2およびUTF8 = Acceptが使用されている場合、[RFC9051]で説明されているようにサーバーが動作する必要があります。
The "UTF8=ONLY" capability indicates that the server supports "UTF8=ACCEPT" (see Section 3) and that it requires support for UTF-8 from clients. In particular, this means that the server will send UTF-8 in quoted-strings, and it will not accept the older international mailbox name convention (modified UTF-7 [RFC3501]). Because these are incompatible changes to IMAP, explicit server announcement and client confirmation are necessary: clients MUST use the "ENABLE UTF8=ACCEPT" command before using this server. A server that advertises "UTF8=ONLY" will reject, with a "NO [CANNOT]" response [RFC5530], any command that might require UTF-8 support and is not preceded by an "ENABLE UTF8=ACCEPT" command.
「UTF8 = Only」機能は、サーバーが「UTF8 = Accept」をサポートしていることを示し（セクション3を参照）、クライアントからのUTF-8のサポートが必要であることを示します。特に、これは、サーバーが引用されたストリングでUTF-8を送信することを意味し、古い国際メールボックス名条約（修正UTF-7 [RFC3501]）を受け入れません。これらはIMAPへの互換性のない変更であるため、明示的なサーバーのアナウンスとクライアントの確認が必要です。クライアントは、このサーバーを使用する前に「UTF8 = Accept」コマンドを使用する必要があります。「utf8 = only」を宣伝するサーバーは、「no [can can when]」応答[rfc5530]を拒否します。これは、UTF-8サポートを必要とし、「UTF8 = Accept」コマンドが「enable utf8 = accept」コマンドが前に行われない可能性があります。
IMAP clients that find support for a server that announces "UTF8=ONLY" problematic are encouraged to at least detect the announcement and provide an informative error message to the end user.
「UTF8 = Only」という問題を発表するサーバーのサポートを見つけるIMAPクライアントは、少なくとも発表を検出し、エンドユーザーに有益なエラーメッセージを提供することをお勧めします。
Because the "UTF8=ONLY" server capability includes support for "UTF8=ACCEPT", the capability string will include, at most, one of those and never both. For the client, "ENABLE UTF8=ACCEPT" is always used -- never "ENABLE UTF8=ONLY".
「UTF8 = Only」サーバー機能には「UTF8 = Accept」のサポートが含まれているため、機能文字列にはせいぜい1つであり、その両方が含まれます。クライアントの場合、「UTF8 = Acceptを有効にする」が常に使用されます - 「UTF8 =のみを有効にする」ことはありません。
In most situations, it will be difficult or impossible for the implementer or operator of an IMAP (or POP) server to know whether all of the clients that might access it, or the associated mail store more generally, will be able to support the facilities defined in this document. In almost all cases, servers that conform to this specification will have to be prepared to deal with clients that do not enable the relevant capabilities. Unfortunately, there is no completely satisfactory way to do so other than for systems that wish to receive email that requires SMTPUTF8 capabilities to be sure that all components of those systems -- including IMAP and other clients selected by users -- are upgraded appropriately.
ほとんどの状況では、IMAP（またはPOP）サーバーの実装者またはオペレーターが、それにアクセスする可能性のあるすべてのクライアント、またはより一般的に関連するメールストアがこのドキュメントで障害のある施設をサポートできるかどうかを知ることは困難または不可能です。ほとんどすべての場合、この仕様に準拠するサーバーは、関連する機能を有効にしないクライアントに対処するために準備する必要があります。残念ながら、IMAPやユーザーが選択した他のクライアントを含むこれらのシステムのすべてのコンポーネントが適切にアップグレードされることを確認するために、SMTPUTF8機能を必要とする電子メールを受信したいシステム以外に、完全に満足のいく方法はありません。
When a message that requires SMTPUTF8 is encountered and the client does not enable UTF-8 capability, choices available to the server include hiding the problematic message(s), creating in-band or out-of-band notifications or error messages, or somehow trying to create a surrogate of the message with the intention of providing useful information to that client about what has occurred. Such surrogate messages cannot be actual substitutes for the original message: they will almost always be impossible to reply to (either at all or without loss of information) and the new header fields or specialized constructs for server-client communications may go beyond the requirements of current email specifications (e.g., [RFC5322]). Consequently, such messages may confuse some legacy mail user agents (including IMAP clients) or not provide expected information to users. There are also trade-offs in constructing surrogates of the original message between accepting complexity and additional computation costs in order to try to preserve as much information as possible (for example, in "Post-Delivery Message Downgrading for Internationalized Email Messages" [RFC6857]) and trying to minimize those costs while still providing useful information (for example, in "Simplified POP and IMAP Downgrading for Internationalized Email" [RFC6858]).
SMTPUTF8を必要とするメッセージが遭遇し、クライアントがUTF-8機能を有効にしない場合、サーバーが利用できる選択肢には、問題のあるメッセージを隠すこと、帯域または帯域外の通知またはエラーメッセージの作成、またはクライアントに有用な情報を提供することを目的としたメッセージのサロゲートを作成しようとする場合が含まれます。このようなサロゲートメッセージは、元のメッセージの実際の代替品にすることはできません。ほとんどの場合、（情報をまったくまたはまったくなしで）返信することは不可能であり、サーバークライアント通信の新しいヘッダーフィールドまたは特殊なコンストラクトは、現在の電子メール仕様の要件を超えている可能性があります（[RFC5322]）。したがって、そのようなメッセージは、いくつかのレガシーメールユーザーエージェント（IMAPクライアントを含む）を混乱させるか、ユーザーに期待される情報を提供しない場合があります。また、できるだけ多くの情報を保存するために、複雑さと追加の計算コストを受け入れることとの間の元のメッセージの代理を構築するトレードオフもあります（たとえば、「国際化された電子メールメッセージの格下げ後」[RFC6857]）と、それらのコストを最小限に抑えようとすると）
Implementations that choose to perform downgrading SHOULD use one of the standardized algorithms provided in [RFC6857] or [RFC6858]. Getting downgrade algorithms right, and minimizing the risk of operational problems and harm to the email system, is tricky and requires careful engineering. These two algorithms are well understood and carefully designed.
格下げを実行することを選択する実装は、[RFC6857]または[RFC6858]で提供される標準化されたアルゴリズムの1つを使用する必要があります。アルゴリズムを正しくダウングレードし、運用上の問題や電子メールシステムへの害のリスクを最小限に抑えることは難しく、慎重なエンジニアリングが必要です。これらの2つのアルゴリズムはよく理解されており、慎重に設計されています。
Because such messages are really surrogates of the original ones, not really "downgraded" ones (although that terminology is often used for convenience), they inevitably have relationships to the originals that the IMAP specification [RFC3501] did not anticipate. This brings up two concerns in particular: First, digital signatures computed over and intended for the original message will often not be applicable to the surrogate message, and will often fail signature verification. (It will be possible for some digital signatures to be verified, if they cover only parts of the original message that are not affected in the creation of the surrogate.) Second, servers that may be accessed by the same user with different clients or methods (e.g., POP or webmail systems in addition to IMAP or IMAP clients with different capabilities) will need to exert extreme care to be sure that UIDVALIDITY [RFC3501] behaves as the user would expect. Those issues may be especially sensitive if the server caches the surrogate message or computes and stores it when the message arrives with the intent of making either form available depending on client capabilities. Additionally, in order to cope with the case when a server compliant with this extension returns the same UIDVALIDITY to both legacy and "UTF8=ACCEPT"-aware clients, a client upgraded from being non-"UTF8=ACCEPT"-aware MUST discard its cache of messages downloaded from the server.
そのようなメッセージは、実際には元のメッセージの代理であり、実際には「格下げ」されたものではないため（その用語は便利なためによく使用されることがよくあります）、彼らは必然的にIMAP仕様[RFC3501]が予想していなかったオリジナルとの関係を持っています。これは特に2つの懸念をもたらします。最初に、元のメッセージを目的としたデジタル署名は、多くの場合、代理メッセージに適用されず、署名の検証に失敗することがよくあります。（いくつかのデジタル署名が検証される可能性があります。それらが代理の作成に影響を受けない元のメッセージの一部のみをカバーする場合。）2番目に、異なるクライアントまたは方法を持つ同じユーザーがアクセスできるサーバー（例：IMAPまたはIMAPクライアントに加えて、異なる機能を持つIMAPまたはIMAPクライアントなど）は、ユーザーが極端に繰り返される必要があります。サーバーがサロゲートメッセージをキャッシュするか、クライアント機能に応じていずれかのフォームを使用できるようにすることを目的としてメッセージが届いたときにそれを計算して保存する場合、これらの問題は特に敏感です。さらに、この拡張機能に準拠したサーバーがレガシーと「utf8 = accept」の両方に同じuidalivityを返す場合、ケースに対処するために、「UTF8 = accept」であることからアップグレードされたクライアントは、サーバーからダウンロードされたメッセージのキャッシュを破棄する必要があります。
The best (or "least bad") approach for any given environment will depend on local conditions, local assumptions about user behavior, the degree of control the server operator has over client usage and upgrading, the options that are actually available, and so on. It is impossible, at least at the time of publication of this specification, to give good advice that will apply to all situations, or even particular profiles of situations, other than "upgrade legacy clients as soon as possible".
特定の環境の最良の（または「最小」）アプローチは、ローカル条件、ユーザーの動作に関するローカルの仮定、サーバーオペレーターがクライアントの使用とアップグレードよりもコントロールの程度、実際に利用可能なオプションなどに依存します。少なくともこの仕様の公開時には、「できるだけ早くレガシークライアントをアップグレードする」以外のすべての状況、または特定の状況のプロファイルにも適用される良いアドバイスを提供することは不可能です。
When an IMAP server uses a mailbox format that supports UTF-8 headers and it permits selection or examination of that mailbox without issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the server to comply with the IMAP base specification [RFC3501] and the Internet Message Format [RFC5322] with respect to all header information transmitted over the wire. The issue of handling messages containing non-ASCII characters in legacy environments is discussed in Section 8.
IMAPサーバーがUTF-8ヘッダーをサポートするメールボックス形式を使用し、「UTF8 = Accept」を発行せずにそのメールボックスの選択または検査を許可する場合、IMAPベース仕様[RFC3501]およびインターネットメッセージフォーマット[RFC5322]に準拠するのはサーバーの責任です[RFC5322]。レガシー環境で非ASCII文字を含むメッセージを処理する問題については、セクション8で説明します。
the "IMAP Capabilities" registry contained a number of references to [RFC6855]. IANA has updated them point to this document instead. The affected references are:
「IMAP機能」レジストリには、[RFC6855]への多くの参照が含まれていました。IANAは、代わりにこのドキュメントのポイントを更新しました。影響を受ける参照は次のとおりです。
* UTF8=ACCEPT
* UTF8 = Accept
* UTF8=ALL (OBSOLETE)
* utf8 = all（時代遅れ）
* UTF8=APPEND (OBSOLETE)
* utf8 = append（時代遅れ）
* UTF8=ONLY
* UTF8 =のみ
* UTF8=USER (OBSOLETE)
* utf8 = user（時代遅れ）
The security considerations of UTF-8 [RFC3629] and PRECIS Usernames and Passwords [RFC8265] apply to this specification, particularly with respect to use of UTF-8 in usernames and passwords. Otherwise, this is not believed to alter the security considerations of IMAP.
UTF-8 [RFC3629]およびPRECISユーザー名とパスワード[RFC8265]のセキュリティ上の考慮事項は、特にユーザー名とパスワードでのUTF-8の使用に関して、この仕様に適用されます。それ以外の場合、これはIMAPのセキュリティ上の考慮事項を変更するとは考えられていません。
Special considerations, some of them with security implications, occur if a server that conforms to this specification is accessed by a client that does not, as well as in some more complex situations in which a given message is accessed by multiple clients that might use different protocols and/or support different capabilities. Those issues are discussed in Section 8.
特別な考慮事項、セキュリティに影響を与えるそれらのいくつかは、この仕様に準拠しているサーバーが、そうでないクライアントがアクセスする場合、および特定のメッセージが異なるプロトコルを使用したり、異なる機能をサポートする可能性のある複数のクライアントによってアクセスされるより複雑な状況でアクセスした場合に発生します。これらの問題については、セクション8で説明します。
[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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
2008, <https://www.rfc-editor.org/info/rfc5161>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>.
[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>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[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>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[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>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017,
<https://www.rfc-editor.org/info/rfc8265>.
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
DOI 10.17487/RFC2342, May 1998,
<https://www.rfc-editor.org/info/rfc2342>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, DOI 10.17487/RFC4314, December 2005,
<https://www.rfc-editor.org/info/rfc4314>.
[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530,
DOI 10.17487/RFC5530, May 2009,
<https://www.rfc-editor.org/info/rfc5530>.
[RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8",
RFC 5738, DOI 10.17487/RFC5738, March 2010,
<https://www.rfc-editor.org/info/rfc5738>.
[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>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
RFC 7888, DOI 10.17487/RFC7888, May 2016,
<https://www.rfc-editor.org/info/rfc7888>.
[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>.
[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>.
This non-normative section discusses the reasons behind some of the design choices in this specification.
この非規範的なセクションでは、この仕様のいくつかの設計の選択肢の背後にある理由について説明します。
The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability problems when legacy support goes away. In the situation where backwards compatibility is not working anyway, the non-conforming "just-send-UTF-8 IMAP" has the advantage that it might work with some legacy clients. However, the difficulty of diagnosing interoperability problems caused by a "just-send-UTF-8 IMAP" mechanism is the reason the "UTF8=ONLY" capability mechanism was chosen.
「UTF8 = Only」メカニズムは、レガシーサポートがなくなったときに相互運用性の問題の診断を簡素化します。とにかく後方互換性が機能していない状況では、不適合な「Just-Send-UTF-8 IMAP」は、いくつかのレガシークライアントで機能する可能性があるという利点があります。ただし、「Just-Send-UTF-8 IMAP」メカニズムによって引き起こされる相互運用性の問題を診断することの難しさが、「UTF8 = Only」機能メカニズムが選択された理由です。
This non-normative section describes the changes made since [RFC6855].
この非規範的なセクションでは、[RFC6855]以降の変更について説明しています。
This document removes APPEND's UTF8 data item, making the UTF8-related syntax compatible with IMAP4rev2 as defined by [RFC9051] and making it simpler for clients to support IMAP4rev1 and IMAP4rev2 with the same code.
このドキュメントは、[RFC9051]で定義されているように、UTF8関連の構文をIMAP4REV2と互換性のあるUTF8関連の構文を削除し、クライアントが同じコードでIMAP4REV1とIMAP4REV2をサポートすることをより簡単にします。
IMAP4rev2 [RFC9051] provides roughly the same abilities as [RFC6855] but does not include APPEND's UTF8 item. None of [RFC6855], IMAP4rev2, or JMAP [RFC8620] specify any way to learn whether a particular message was stored using the UTF8 data item. As of today, an IMAP client cannot learn whether a particular message was stored using the UTF8 data item, nor would it be able to trust that information even if IMAP4rev1 and 2 were extended to provide that information.
IMAP4REV2 [RFC9051]は[RFC6855]とほぼ同じ能力を提供しますが、AppendのUTF8アイテムは含まれていません。[RFC6855]、IMAP4REV2、またはJMAP [RFC8620]は、UTF8データ項目を使用して特定のメッセージが保存されているかどうかを学習する方法を指定していません。今日の時点で、IMAPクライアントは、特定のメッセージがUTF8データ項目を使用して保存されたかどうかを知ることも、IMAP4REV1と2がその情報を提供するために拡張されたとしても、その情報を信頼することもできません。
In July 2023, one of the authors found only one IMAP client that uses the UTF8 data item, and that client uses it incorrectly (it sends the data item for all messages if the server supports UTF8=ACCEPT, without regard to whether a particular message includes any UTF8 at all).
2023年7月、著者の1人は、UTF8データ項目を使用するIMAPクライアントのみを見つけ、クライアントはそれを誤って使用することを見つけました（サーバーがUTF8をサポートしている場合、特定のメッセージにはUTF8が含まれているかどうかに関係なく、すべてのメッセージのデータ項目を送信します）。
For these reasons, it was judged best to revise [RFC6855] and adopt the same syntax as IMAP4rev2.
これらの理由により、[RFC6855]を修正し、IMAP4REV2と同じ構文を採用することが最善と判断されました。
[RFC6532] defines a new media type, message/global, which is substantially like message/rfc822 except that the submessage may (also) use the syntax defined in [RFC6532]. [RFC3501] and [RFC9051] define a FETCH item to return the MIME structure of a message, which servers usually compute once and store.
[RFC6532]は、サブメッサージが[RFC6532]で定義されている構文を（また）使用することを除いて、メッセージ/RFC822に実質的に似ている新しいメディアタイプ/グローバルを定義します。[RFC3501]および[RFC9051]は、通常、サーバーが1回計算して保存するメッセージのmime構造を返すためのフェッチアイテムを定義します。
None of the RFCs point out to implementers that IMAP4rev1 and IMAP4rev2 are slightly different, so storing the BODYSTRUCTURE in the way servers and clients often do can easily lead to problems.
RFCSはいずれも、IMAP4REV1とIMAP4REV2がわずかに異なっているという実装者を指摘していないため、サーバーやクライアントがしばしば行う方法にボディストラクチャを保存することで、問題に簡単につながる可能性があります。
This document makes the syntax optional, making it simple for server authors to implement this extension correctly. This implies that clients need to parse and handle both varieties, which they need to do anyway if they want to support both IMAP4rev1 and IMAP4rev2.
このドキュメントにより、構文がオプションになるため、サーバーの著者がこの拡張機能を正しく実装できるようになります。これは、クライアントが両方の品種を解析して処理する必要があることを意味します。これは、IMAP4REV1とIMAP4REV2の両方をサポートしたい場合はとにかく行う必要があります。
This document is an almost unchanged copy of [RFC6855], which was written by Pete Resnick, Chris Newman, and Sean Shen. Sean has since changed jobs and the current authors do not have a new email address for him. We cannot be sure that he would approve of the changes in this document, so we did not list him as author, but do gratefully acknowledge his work on [RFC6855]. Jiankang Yao replaces him.
このドキュメントは、[RFC6855]のほとんど変わらないコピーであり、ピートレストニック、クリスニューマン、ショーンシェンによって書かれました。ショーンはその後ジョブを変更し、現在の著者は彼のための新しいメールアドレスを持っていません。彼がこのドキュメントの変更を承認するとは確信できないので、彼を著者としてリストしませんでしたが、[RFC6855]での彼の仕事を感謝して認めました。Jiankang Yaoは彼に取って代わります。
The next paragraph is a straight copy of the acknowledgments in [RFC6855]:
次の段落は、[RFC6855]の謝辞の直線コピーです。
The authors wish to thank the participants of the EAI working group for their contributions to this document, with particular thanks to Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen, Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and Joseph Yee for their specific contributions to the discussion.
The authors wish to thank the participants of the EAI working group for their contributions to this document, with particular thanks to Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen, Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and Joseph Yee for their議論への具体的な貢献。
Many of them also reread the document during this revision.
それらの多くは、この改訂中にドキュメントを読み直しました。
Pete Resnick
Episteme Technology Consulting LLC
503 West Indiana Avenue
Urbana, IL 61801-4941
United States of America
Email: resnick@episteme.net
Jiankang Yao
CNNIC
No.4 South 4th Zhongguancun Street
Beijing
100190
China
Email: yaojk@cnnic.cn
Arnt Gulbrandsen
ICANN
6 Rond Point Schumann, Bd. 1
1040 Brussels
Belgium
Email: arnt@gulbrandsen.priv.no