[要約] RFC 5530はIMAP応答コードに関する仕様であり、IMAPサーバーからの応答を表すコードの定義と使用方法を提供しています。このRFCの目的は、IMAPクライアントとサーバー間の通信を効率的かつ正確に行うための共通の基準を確立することです。
Network Working Group A. Gulbrandsen
Request for Comments: 5530 Oryx Mail Systems GmbH
Category: Standards Track May 2009
IMAP Response Codes
IMAP応答コード
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.
IMAP応答は、応答タイプ（OK、いいえ、悪い）、オプションのマシン読み取り可能な応答コード、および人間の読み取り可能なテキストで構成されています。
This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting.
このドキュメントは、より良い相互操作とエラーの報告を得るために、さまざまな機械読み取り可能な応答コードを収集およびドキュメントします。
Section 7.1 of [RFC3501] defines a number of response codes that can help tell an IMAP client why a command failed. However, experience has shown that more codes are useful. For example, it is useful for a client to know that an authentication attempt failed because of a server problem as opposed to a password problem.
[RFC3501]のセクション7.1は、コマンドが故障した理由をIMAPクライアントに伝えるのに役立つ多くの応答コードを定義しています。ただし、経験により、より多くのコードが役立つことが示されています。たとえば、パスワードの問題とは対照的に、サーバーの問題のために認証試行が失敗したことをクライアントが知ることは有用です。
Currently, many IMAP servers use English-language, human-readable text to describe these errors, and a few IMAP clients attempt to translate this text into the user's language.
現在、多くのIMAPサーバーは、これらのエラーを説明するために英語の人間の読み取り可能なテキストを使用しており、いくつかのIMAPクライアントがこのテキストをユーザーの言語に翻訳しようとしています。
This document names a variety of errors as response codes. It is based on errors that have been checked and reported on in some IMAP server implementations, and on the needs of some IMAP clients.
このドキュメントは、さまざまなエラーを応答コードとして名前を付けます。これは、一部のIMAPサーバーの実装でチェックおよび報告されたエラーと、一部のIMAPクライアントのニーズに基づいています。
This document doesn't require any servers to test for these errors or any clients to test for these names. It only names errors for better reporting and handling.
このドキュメントは、これらのエラーまたはクライアントをテストするためにサーバーをテストするためにサーバーを必要としません。より良い報告と取り扱いのためにエラーのみに名前を付けます。
Formal syntax is defined by [RFC5234] as modified by [RFC3501].
正式な構文は、[RFC3501]によって変更された[RFC5234]によって定義されます。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision.
「c：」で前巻かれたラインの例は、クライアントによって送信され、「s：」がサーバーによってメリットされたものが送信されます。「[...]」は排除を意味します。
This section defines all the new response codes. Each definition is followed by one or more examples.
このセクションでは、すべての新しい応答コードを定義します。各定義の後に1つ以上の例が続きます。
UNAVAILABLE Temporary failure because a subsystem is down. For example, an IMAP server that uses a Lightweight Directory Access Protocol (LDAP) or Radius server for authentication might use this response code when the LDAP/Radius server is down.
サブシステムがダウンしているため、利用できない一時的な障害。たとえば、LDAP/RADIUSサーバーがダウンしているときに、認証にLightWeight Directory Access Protocol（LDAP）またはRADIUSサーバーを使用するIMAPサーバーまたはRADIUSサーバーがこの応答コードを使用する場合があります。
C: a LOGIN "fred" "foo"
S: a NO [UNAVAILABLE] User's backend down for maintenance
AUTHENTICATIONFAILED Authentication failed for some reason on which the server is unwilling to elaborate. Typically, this includes "unknown user" and "bad password".
AuthenticationFailed認証は、何らかの理由でサーバーが詳しく説明したくないという理由で失敗しました。通常、これには「不明なユーザー」と「悪いパスワード」が含まれます。
This is the same as not sending any response code, except that when a client sees AUTHENTICATIONFAILED, it knows that the problem wasn't, e.g., UNAVAILABLE, so there's no point in trying the same login/password again later.
これは、クライアントがAuthenticationFailedが表示されていると表示された場合、問題が利用できないことを知っていることを除いて、応答コードを送信しないことと同じです。
C: b LOGIN "fred" "foo"
S: b NO [AUTHENTICATIONFAILED] Authentication failed
AUTHORIZATIONFAILED Authentication succeeded in using the authentication identity, but the server cannot or will not allow the authentication identity to act as the requested authorization identity. This is only applicable when the authentication and authorization identities are different.
AuthorizationFailed Authenticationは認証IDの使用に成功しましたが、サーバーは、認証IDが要求された承認IDとして機能することはできません。これは、認証と承認のアイデンティティが異なる場合にのみ適用されます。
C: c1 AUTHENTICATE PLAIN
[...]
S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
C: c2 AUTHENTICATE PLAIN
[...]
S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
EXPIRED Either authentication succeeded or the server no longer had the necessary data; either way, access is no longer permitted using that passphrase. The client or user should get a new passphrase.
認証が成功したか、サーバーに必要なデータがなかったかのいずれかの期限が切れました。いずれにせよ、そのパスフレーズを使用してアクセスは許可されなくなりました。クライアントまたはユーザーは、新しいパスフレーズを取得する必要があります。
C: d login "fred" "foo"
S: d NO [EXPIRED] That password isn't valid any more
PRIVACYREQUIRED The operation is not permitted due to a lack of privacy. If Transport Layer Security (TLS) is not in use, the client could try STARTTLS (see Section 6.2.1 of [RFC3501]) and then repeat the operation.
プライバシーが操作されたプライバシーが不足しているため、操作は許可されていません。輸送層のセキュリティ（TLS）が使用されていない場合、クライアントはstartTLSを試してから（[RFC3501]セクション6.2.1を参照）、操作を繰り返すことができます。
C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C: d select inbox
S: d NO [PRIVACYREQUIRED] Connection offers no privacy
CONTACTADMIN The user should contact the system administrator or support desk.
ContactAdminユーザーは、システム管理者またはサポートデスクに連絡する必要があります。
C: e login "fred" "foo"
S: e OK [CONTACTADMIN]
NOPERM The access control system (e.g., Access Control List (ACL), see [RFC4314]) does not permit this user to carry out an operation, such as selecting or creating a mailbox.
nopermアクセス制御システム（アクセス制御リスト（ACL）、[RFC4314]を参照）は、このユーザーがメールボックスの選択や作成などの操作を実行することを許可していません。
C: f select "/archive/projects/experiment-iv"
S: f NO [NOPERM] Access denied
INUSE An operation has not been carried out because it involves sawing off a branch someone else is sitting on. Someone else may be holding an exclusive lock needed for this operation, or the operation may involve deleting a resource someone else is using, typically a mailbox.
Inuseは、他の誰かが座っている枝を磨くことを伴うため、操作が実行されていません。他の誰かがこの操作に必要な排他的ロックを保持している可能性があります。または、操作には、他の誰かが使用しているリソース、通常はメールボックスを削除することが含まれます。
The operation may succeed if the client tries again later.
クライアントが後で再び試みた場合、操作は成功する可能性があります。
C: g delete "/archive/projects/experiment-iv"
S: g NO [INUSE] Mailbox in use
EXPUNGEISSUED Someone else has issued an EXPUNGE for the same mailbox. The client may want to issue NOOP soon. [RFC2180] discusses this subject in depth.
obungeissed他の誰かが同じメールボックスの抹消を発行しました。クライアントはすぐにNOOPを発行したいかもしれません。[RFC2180]この主題について詳しく説明します。
C: h search from fred@example.com
S: * SEARCH 1 2 3 5 8 13 21 42
S: h OK [EXPUNGEISSUED] Search completed
CORRUPTION The server discovered that some relevant data (e.g., the mailbox) are corrupt. This response code does not include any information about what's corrupt, but the server can write that to its logfiles.
汚職サーバーは、関連するデータ（メールボックスなど）が破損していることを発見しました。この応答コードには、腐敗したものに関する情報は含まれていませんが、サーバーはそれをログファイルに書き込むことができます。
C: i select "/archive/projects/experiment-iv"
S: i NO [CORRUPTION] Cannot open mailbox
SERVERBUG The server encountered a bug in itself or violated one of its own invariants.
サーバーバグサーバーは、それ自体でバグに遭遇するか、独自の不変剤の1つに違反しました。
C: j select "/archive/projects/experiment-iv"
S: j NO [SERVERBUG] This should not happen
CLIENTBUG The server has detected a client bug. This can accompany all of OK, NO, and BAD, depending on what the client bug is.
クライアントバグサーバーはクライアントのバグを検出しました。これは、クライアントのバグとは何かに応じて、OK、いいえ、および悪いすべてに付随する可能性があります。
C: k1 select "/archive/projects/experiment-iv"
[...]
S: k1 OK [READ-ONLY] Done
C: k2 status "/archive/projects/experiment-iv" (messages)
[...]
S: k2 OK [CLIENTBUG] Done
CANNOT The operation violates some invariant of the server and can never succeed.
操作はサーバーの不変型に違反し、成功することはできません。
C: l create "///////"
S: l NO [CANNOT] Adjacent slashes are not supported
LIMIT The operation ran up against an implementation limit of some kind, such as the number of flags on a single message or the number of flags used in a mailbox.
制限操作は、単一のメッセージのフラグの数やメールボックスで使用されるフラグの数など、何らかの種類の実装制限に対して実行されました。
C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
S: m NO [LIMIT] At most 32 flags in one mailbox supported
OVERQUOTA The user would be over quota after the operation. (The user may or may not be over quota already.)
Overquota操作後、ユーザーはクォータを超えています。（ユーザーはすでにクォータを超えている場合とそうでない場合があります。）
Note that if the server sends OVERQUOTA but doesn't support the IMAP QUOTA extension defined by [RFC2087], then there is a quota, but the client cannot find out what the quota is.
サーバーがOverquotaを送信するが、[RFC2087]で定義されたIMAPクォータ拡張機能をサポートしていない場合、クォータがありますが、クライアントはクォータとは何かを見つけることができないことに注意してください。
C: n1 uid copy 1:* oldmail
S: n1 NO [OVERQUOTA] Sorry
C: n2 uid copy 1:* oldmail
S: n2 OK [OVERQUOTA] You are now over your soft quota
ALREADYEXISTS The operation attempts to create something that already exists, such as when the CREATE or RENAME directories attempt to create a mailbox and there is already one of that name.
既に既存の操作は、作成または名前を変更したディレクトリがメールボックスを作成しようとする場合など、すでに存在するものを作成しようとしますが、その名前の1つはすでにあります。
C: o RENAME this that
S: o NO [ALREADYEXISTS] Mailbox "that" already exists
NONEXISTENT The operation attempts to delete something that does not exist. Similar to ALREADYEXISTS.
存在しない操作は、存在しないものを削除しようとします。既に既存のものに似ています。
C: p RENAME this that
S: p NO [NONEXISTENT] No such mailbox
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminal "resp-text-code".
次の構文仕様では、[RFC5234]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。[RFC3501]は、非末端の「Resp-Text-Code」を定義します。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lowercase characters to define token strings is for editorial clarity only.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために上位または小文字の文字を使用することは、編集の明確性のみを目的としています。
resp-text-code =/ "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
"AUTHORIZATIONFAILED" / "EXPIRED" /
"PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
"INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
"SERVERBUG" / "CLIENTBUG" / "CANNOT" /
"LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
"NONEXISTENT"
Revealing information about a passphrase to unauthenticated IMAP clients causes bad karma.
無許可のIMAPクライアントへのパスフレーズに関する情報を明らかにすると、悪いカルマが発生します。
Response codes are easier to parse than human-readable text. This can amplify the consequences of an information leak. For example, selecting a mailbox can fail because the mailbox doesn't exist, because the user doesn't have the "l" right (right to know the mailbox exists) or "r" right (right to read the mailbox). If the server sent different responses in the first two cases in the past, only malevolent clients would discover it. With response codes it's possible, perhaps probable, that benevolent clients will forward the leaked information to the user. Server authors are encouraged to be particularly careful with the NOPERM and authentication-related responses.
応答コードは、人間の読み取り可能なテキストよりも解析が簡単です。これにより、情報リークの結果が増幅できます。たとえば、ユーザーが「l」権利（メールボックスを知る権利）または「r」権（メールボックスを読む権利）を持っていないため、メールボックスが存在しないため、メールボックスの選択が失敗する可能性があります。サーバーが過去に最初の2つのケースで異なる応答を送信した場合、悪意のあるクライアントのみがそれを発見します。応答コードを使用すると、おそらく慈悲深いクライアントが漏れた情報をユーザーに転送する可能性があります。サーバーの著者は、NOPERMおよび認証関連の応答に特に注意することをお勧めします。
The IANA has created the IMAP Response Codes registry. The registry has been populated with the following codes:
IANAは、IMAP応答コードレジストリを作成しました。レジストリには、次のコードが入力されています。
NEWNAME RFC 2060 (obsolete)
REFERRAL RFC 2221
ALERT RFC 3501
BADCHARSET RFC 3501
PARSE RFC 3501
PERMANENTFLAGS RFC 3501
READ-ONLY RFC 3501
READ-WRITE RFC 3501
TRYCREATE RFC 3501
UIDNEXT RFC 3501
UIDVALIDITY RFC 3501
UNSEEN RFC 3501
UNKNOWN-CTE RFC 3516
UIDNOTSTICKY RFC 4315
APPENDUID RFC 4315
COPYUID RFC 4315
URLMECH RFC 4467
TOOBIG RFC 4469
BADURL RFC 4469
HIGHESTMODSEQ RFC 4551
NOMODSEQ RFC 4551
MODIFIED RFC 4551
COMPRESSIONACTIVE RFC 4978
CLOSED RFC 5162
NOTSAVED RFC 5182
BADCOMPARATOR RFC 5255
ANNOTATE RFC 5257
ANNOTATIONS RFC 5257
TEMPFAIL RFC 5259
MAXCONVERTMESSAGES RFC 5259
MAXCONVERTPARTS RFC 5259
NOUPDATE RFC 5267
METADATA RFC 5464
NOTIFICATIONOVERFLOW RFC 5465
BADEVENT RFC 5465
UNDEFINED-FILTER RFC 5466
UNAVAILABLE RFC 5530
AUTHENTICATIONFAILED RFC 5530
AUTHORIZATIONFAILED RFC 5530
EXPIRED RFC 5530
PRIVACYREQUIRED RFC 5530
CONTACTADMIN RFC 5530
NOPERM RFC 5530
INUSE RFC 5530
EXPUNGEISSUED RFC 5530
CORRUPTION RFC 5530
SERVERBUG RFC 5530
CLIENTBUG RFC 5530
CANNOT RFC 5530
LIMIT RFC 5530
OVERQUOTA RFC 5530
ALREADYEXISTS RFC 5530
NONEXISTENT RFC 5530
The new registry can be extended by sending a registration request to IANA. IANA will forward this request to a Designated Expert, appointed by the responsible IESG Area Director, CCing it to the IMAP Extensions mailing list at <ietf-imapext@imc.org> (or a successor designated by the Area Director). After either allowing 30 days for community input on the IMAP Extensions mailing list or a successful IETF Last Call, the expert will determine the appropriateness of the registration request and either approve or disapprove the request by sending a notice of the decision to the requestor, CCing the IMAP Extensions mailing list and IANA. A denial notice must be justified by an explanation, and, in cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
新しいレジストリは、IANAに登録要求を送信することで拡張できます。IANAは、責任あるIESGエリアディレクターによって任命された指定された専門家にこのリクエストを転送し、<ietf-imapext@imc.org>（またはエリアディレクターが指定した後継者）のIMAP拡張メーリングリストにccします。IMAP拡張メーリングリストのコミュニティ入力またはIETFの最後の電話でのコミュニティ入力に30日を許可した後、専門家は登録要求の適切性を決定し、決定の通知をリクエスターに送信してリクエストを承認または不承認にします。IMAP拡張メーリングリストとIANA。拒否通知は説明によって正当化されなければならず、可能な場合は、受け入れられるようにリクエストをどのように変更できるかについての具体的な提案を提供する必要があります。
For each response code, the registry contains a list of relevant RFCs that describe (or extend) the response code and an optional response code status description, such as "obsolete" or "reserved to prevent collision with deployed software". (Note that in the latter case, the RFC number can be missing.) Presence of the response code status description means that the corresponding response code is NOT RECOMMENDED for widespread use.
各応答コードについて、レジストリには、応答コードを記述（または拡張）する関連RFCのリストと、「展開されたソフトウェアとの衝突を防ぐために「廃止」または「予約された」などのオプションの応答コードステータス説明が含まれています。（後者の場合、RFC数は欠落する可能性があることに注意してください。）応答コードステータスの説明は、対応する応答コードが広範囲にわたる使用に推奨されないことを意味します。
The intention is that any future allocation will be accompanied by a published RFC (including direct submissions to the RFC Editor). But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published, for example, before requesting IETF LC for the document.
意図は、将来の割り当てには公開されたRFC（RFCエディターへの直接の提出を含む）が伴うことです。しかし、RFCが公開される前に値の割り当てを許可するために、指定された専門家は、たとえば、文書にIETF LCをリクエストする前にRFCが公開されることが明らかになると思われる場合、割り当てを承認できます。
The Designated Expert can also approve registrations for response codes used in deployed software when no RFC exists. Such registrations must be marked as "reserved to prevent collision with deployed software".
指定された専門家は、RFCが存在しない場合、展開されたソフトウェアで使用される応答コードの登録を承認することもできます。このような登録は、「展開されたソフトウェアとの衝突を防ぐために予約されている」とマークする必要があります。
Response code registrations may not be deleted; response codes that are no longer believed appropriate for use (for example, if there is a problem with the syntax of said response code or if the specification describing it was moved to Historic) should be marked "obsolete" in the registry, clearly marking the lists published by IANA.
応答コード登録は削除されない場合があります。使用に適していると考えられていない応答コード（たとえば、上記の応答コードの構文に問題がある場合、またはそれを説明する仕様が歴史に移動された場合）は、レジストリで「時代遅れ」とマークされ、明確にマークを付ける必要があります。IANAが発行したリスト。
Peter Coates, Mark Crispin, Philip Guenther, Alexey Melnikov, Ken Murchison, Chris Newman, Timo Sirainen, Philip Van Hoof, Dale Wiggins, and Sarah Wilkin helped with this document.
ピーター・コーツ、マーク・クリスピン、フィリップ・グンテル、アレクセイ・メルニコフ、ケン・マーチソン、クリス・ニューマン、ティモ・シランエン、フィリップ・ヴァン・ホーフ、デール・ウィギンズ、サラ・ウィルキンがこの文書を手伝いました。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[RFC2087] Myers、J。、「IMAP4クォータエクステンション」、RFC 2087、1997年1月。
[RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[RFC2180] Gahrns、M。、「IMAP4マルチアクセスメールボックスプラクティス」、RFC 2180、1997年7月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314] Melnikov、A。、「IMAP4アクセス制御リスト（ACL）拡張機能」、RFC 4314、2005年12月。
Author's Address
著者の連絡先
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr。8 D-81671ミューンチェンドイツ
Fax: +49 89 4502 9758
EMail: arnt@oryx.com