[要約] RFC 5804は、Sieveスクリプトをリモートで管理するためのプロトコルであり、要約すると以下のようになります。1. Sieveスクリプトのリモート管理を可能にするプロトコル。 2. クライアントとサーバー間でSieveスクリプトを送受信するための仕様。 3. Sieveスクリプトの効率的な管理と遠隔操作を目的としている。
Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 5804 Isode Limited
Category: Standards Track T. Martin
ISSN: 2070-1721 BeThereBeSquare, Inc.
July 2010
A Protocol for Remotely Managing Sieve Scripts
シーブスクリプトをリモートで管理するためのプロトコル
Abstract
概要
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts.
ふるいスクリプトを使用すると、ユーザーは着信電子メールをフィルタリングできます。メッセージストアは一般的に封印されたサーバーであるため、ユーザーはそれらにログインできませんが、ユーザーはスクリプトを更新できる必要があります。このドキュメントでは、リモートサーバーでシーブスクリプトを安全に管理するためのプロトコル「ManagESIEVE」について説明します。このプロトコルにより、ユーザーは複数のスクリプトを持つことができ、またユーザーにスクリプトを構文的に欠陥のあるように警告します。
Status of This Memo
本文書の位置付け
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5804.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5804で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Commands and Responses .....................................3
1.2. Syntax .....................................................3
1.3. Response Codes .............................................3
1.4. Active Script ..............................................6
1.5. Quotas .....................................................6
1.6. Script Names ...............................................6
1.7. Capabilities ...............................................7
1.8. Transport ..................................................9
1.9. Conventions Used in This Document .........................10
2. Commands .......................................................10
2.1. AUTHENTICATE Command ......................................11
2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16
2.2. STARTTLS Command ..........................................16
2.2.1. Server Identity Check ..............................17
2.3. LOGOUT Command ............................................20
2.4. CAPABILITY Command ........................................20
2.5. HAVESPACE Command .........................................20
2.6. PUTSCRIPT Command .........................................21
2.7. LISTSCRIPTS Command .......................................23
2.8. SETACTIVE Command .........................................24
2.9. GETSCRIPT Command .........................................25
2.10. DELETESCRIPT Command .....................................25
2.11. RENAMESCRIPT Command .....................................26
2.12. CHECKSCRIPT Command ......................................27
2.13. NOOP Command .............................................28
2.14. Recommended Extensions ...................................28
2.14.1. UNAUTHENTICATE Command ............................28
3. Sieve URL Scheme ...............................................29
4. Formal Syntax ..................................................31
5. Security Considerations ........................................37
6. IANA Considerations ............................................38
6.1. ManageSieve Capability Registration Template ..............39
6.2. Registration of Initial ManageSieve Capabilities ..........39
6.3. ManageSieve Response Code Registration Template ...........41
6.4. Registration of Initial ManageSieve Response Codes ........41
7. Internationalization Considerations ............................46
8. Acknowledgements ...............................................46
9. References .....................................................47
9.1. Normative References ......................................47
9.2. Informative References ....................................48
A ManageSieve connection consists of the establishment of a client/ server network connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result response.
ManageSieve接続は、クライアント/サーバーネットワーク接続の確立、サーバーからの最初の挨拶、およびクライアント/サーバーのインタラクションで構成されています。これらのクライアント/サーバーの相互作用は、クライアントコマンド、サーバーデータ、およびサーバー完了結果応答で構成されています。
All interactions transmitted by client and server are in the form of lines, that is, strings that end with a CRLF. The protocol receiver of a ManageSieve client or server is either reading a line or reading a sequence of octets with a known count followed by a line.
クライアントとサーバーによって送信されるすべてのインタラクションは、行の形、つまりCRLFで終わる文字列です。ManageSieveクライアントまたはサーバーのプロトコル受信者は、ラインを読み取るか、既知のカウントに続いて行が続くオクテットのシーケンスを読み取っています。
ManageSieve is a line-oriented protocol much like [IMAP] or [ACAP], which runs over TCP. There are three data types: atoms, numbers and strings. Strings may be quoted or literal. See [ACAP] for detailed descriptions of these types.
ManageSieveは、[IMAP]または[ACAP]によく似たライン指向のプロトコルであり、TCPを介して実行されます。3つのデータ型があります：原子、数字、文字列。文字列は引用されているか、文字通りです。これらのタイプの詳細な説明については、[ACAP]を参照してください。
Each command consists of an atom (the command name) followed by zero or more strings and numbers terminated by CRLF.
各コマンドは、Atom（コマンド名）で構成され、その後にCRLFによって終了したゼロ以上の文字列と数値が続きます。
All client queries are replied to with either an OK, NO, or BYE response. Each response may be followed by a response code (see Section 1.3) and by a string consisting of human-readable text in the local language (as returned by the LANGUAGE capability; see Section 1.7), encoded in UTF-8 [UTF-8]. The contents of the string SHOULD be shown to the user ,and implementations MUST NOT attempt to parse the message for meaning.
すべてのクライアントクエリは、OK、いいえ、またはBYE応答のいずれかで返信されます。各応答の後に、応答コード（セクション1.3を参照）と、ローカル言語の人間が読み取るテキストで構成される文字列（言語能力によって返されます。セクション1.7を参照）が、UTF-8 [UTF-8でエンコードされています。]。文字列の内容をユーザーに表示する必要があり、実装は意味のメッセージを解析しようとしてはなりません。
The BYE response SHOULD be used if the server wishes to close the connection. A server may wish to do this because the client was idle for too long or there were too many failed authentication attempts. This response can be issued at any time and should be immediately followed by a server hang-up of the connection. If a server has an inactivity timeout resulting in client autologout, it MUST be no less than 30 minutes after successful authentication. The inactivity timeout MAY be less before authentication.
サーバーが接続を閉じることを希望する場合は、BYE応答を使用する必要があります。サーバーは、クライアントがあまりにも長くアイドル状態であったか、認証の試みが多すぎたため、これを行うことをお勧めします。この応答はいつでも発行でき、すぐに接続のサーバーハングアップが続く必要があります。サーバーにクライアントの自動学的なタイムアウトが不活性なタイムアウトを搭載している場合、認証が成功してから30分以上経過する必要があります。非アクティブタイムアウトは、認証の前に少ない場合があります。
An OK, NO, or BYE response from the server MAY contain a response code to describe the event in a more detailed machine-parsable fashion. A response code consists of data inside parentheses in the form of an atom, possibly followed by a space and arguments.
サーバーからのOK、いいえ、またはBYE応答には、より詳細な機械型のファッションでイベントを説明するための応答コードが含まれている場合があります。応答コードは、原子の形で括弧内のデータで構成され、おそらくスペースと引数が続く可能性があります。
Response codes are defined when there is a specific action that a client can take based upon the additional information. In order to support future extension, the response code is represented as a slash-separated (Solidus, %x2F) hierarchy with each level of hierarchy representing increasing detail about the error. Response codes MUST NOT start with the Solidus character. Clients MUST tolerate additional hierarchical response code detail that they don't understand. For example, if the client supports the "QUOTA" response code, but doesn't understand the "QUOTA/MAXSCRIPTS" response code, it should treat "QUOTA/MAXSCRIPTS" as "QUOTA".
応答コードは、クライアントが追加情報に基づいて取ることができる特定のアクションがある場合に定義されます。将来の拡張をサポートするために、応答コードはスラッシュ分離された（Solidus、％x2F）階層として表され、各レベルの階層がエラーに関する詳細を増やすことを表します。応答コードは、Solidus文字から開始してはなりません。クライアントは、彼らが理解していない追加の階層的応答コードの詳細を容認する必要があります。たとえば、クライアントが「クォータ」応答コードをサポートしているが、「クォータ/マックススクリプト」応答コードを理解していない場合、「quota/maxscripts」を「クォータ」として扱う必要があります。
Client implementations MUST tolerate (ignore) response codes that they do not recognize.
クライアントの実装は、認識されていない応答コードを許容（無視）する必要があります。
The currently defined response codes are the following:
現在定義されている応答コードは次のとおりです。
AUTH-TOO-WEAK
auth-too-weak
This response code is returned in the NO or BYE response from an AUTHENTICATE command. It indicates that site security policy forbids the use of the requested mechanism for the specified authentication identity.
この応答コードは、認証コマンドからNOまたはBYE応答で返されます。これは、サイトのセキュリティポリシーが、指定された認証IDのために要求されたメカニズムの使用を禁止することを示しています。
ENCRYPT-NEEDED
暗号化されています
This response code is returned in the NO or BYE response from an AUTHENTICATE command. It indicates that site security policy requires the use of a strong encryption mechanism for the specified authentication identity and mechanism.
この応答コードは、認証コマンドからNOまたはBYE応答で返されます。サイトのセキュリティポリシーには、指定された認証アイデンティティとメカニズムに強力な暗号化メカニズムの使用が必要であることが示されています。
QUOTA
クォータ
If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined quota constraints. If this response code is returned in the OK response, it can mean that the user's storage is near its quota, or it can mean that the account exceeded its quota but that the condition is being allowed by the server (the server supports so-called soft quotas). The QUOTA response code has two more detailed variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user scripts) and "QUOTA/MAXSIZE" (the maximum script size).
この応答コードがno/bye応答で返される場合、コマンドがユーザーをサイト定義のクォータの制約の上に配置したことを意味します。この応答コードがOK応答で返された場合、ユーザーのストレージがクォータに近いことを意味するか、アカウントがクォータを超えたことを意味しますが、サーバーによって条件が許可されていることを意味します（サーバーはいわゆるサポートソフトクォータ）。クォータ応答コードには、「クォータ/マックススクリプト」（ユーザーごとのスクリプトの最大数）と「クォータ/マックスサイズ」（最大スクリプトサイズ）の2つの詳細なバリアントがあります。
REFERRAL
照会
This response code may be returned with a BYE result from any command, and includes a mandatory parameter that indicates what server to access to manage this user's Sieve scripts. The server will be specified by a Sieve URL (see Section 3). The scriptname portion of the URL MUST NOT be specified. The client should authenticate to the specified server and use it for all further commands in the current session.
この応答コードは、任意のコマンドからのバイの結果で返される場合があり、このユーザーのシーブスクリプトを管理するためにアクセスするサーバーを示す必須パラメーターが含まれています。サーバーは、ふるいURLによって指定されます（セクション3を参照）。URLのスクリプト名部分を指定してはなりません。クライアントは、指定されたサーバーに認証し、現在のセッションでさらにすべてのコマンドに使用する必要があります。
SASL
SASL
This response code can occur in the OK response to a successful AUTHENTICATE command and includes the optional final server response data from the server as specified by [SASL].
この応答コードは、成功した認証コマンドに対するOK応答で発生する可能性があり、[SASL]で指定されたサーバーからのオプションの最終サーバー応答データを含めることができます。
TRANSITION-NEEDED
トランジションが必要です
This response code occurs in a NO response of an AUTHENTICATE command. It indicates that the user name is valid, but the entry in the authentication database needs to be updated in order to permit authentication with the specified mechanism. This is typically done by establishing a secure channel using TLS, verifying server identity as specified in Section 2.2.1, and finally authenticating once using the [PLAIN] authentication mechanism. The selected mechanism SHOULD then work for authentications in subsequent sessions.
この応答コードは、認証コマンドのNO応答で発生します。これは、ユーザー名が有効であることを示していますが、指定されたメカニズムで認証を許可するために、認証データベースのエントリを更新する必要があります。これは通常、TLSを使用して安全なチャネルを確立し、セクション2.2.1で指定されているサーバーIDを確認し、[プレーン]認証メカニズムを使用して1回認証することによって行われます。選択したメカニズムは、後続のセッションで認証のために機能する必要があります。
This condition can happen if a user has an entry in a system authentication database such as Unix /etc/passwd, but does not have credentials suitable for use by the specified mechanism.
この条件は、ユーザーがUNIX /ETC /PASSWDなどのシステム認証データベースにエントリを持っているが、指定されたメカニズムで使用に適した資格情報を持っていない場合に発生する可能性があります。
TRYLATER
trylater
A command failed due to a temporary server failure. The client MAY continue using local information and try the command later. This response code only makes sense when returned in a NO/BYE response.
一時的なサーバーの障害によりコマンドが失敗しました。クライアントは、ローカル情報を引き続き使用し、後でコマンドを試すことができます。この応答コードは、NO/BYE応答で返された場合にのみ理にかなっています。
ACTIVE
アクティブ
A command failed because it is not allowed on the active script, for example, DELETESCRIPT on the active script. This response code only makes sense when returned in a NO/BYE response.
コマンドは、アクティブなスクリプトでアクティブなスクリプトで許可されていないために失敗しました。たとえば、アクティブなスクリプトで削除されます。この応答コードは、NO/BYE応答で返された場合にのみ理にかなっています。
NONEXISTENT
存在しない
A command failed because the referenced script name doesn't exist. This response code only makes sense when returned in a NO/BYE response.
参照されたスクリプト名が存在しないため、コマンドが失敗しました。この応答コードは、NO/BYE応答で返された場合にのみ理にかなっています。
ALREADYEXISTS
もう存在している
A command failed because the referenced script name already exists. This response code only makes sense when returned in a NO/BYE response.
参照されたスクリプト名がすでに存在するため、コマンドが失敗しました。この応答コードは、NO/BYE応答で返された場合にのみ理にかなっています。
TAG
鬼ごっこ
This response code name is followed by a string specified in the command. See Section 2.13 for a possible use case.
この応答コード名の後に、コマンドで指定された文字列が続きます。可能なユースケースについては、セクション2.13を参照してください。
WARNINGS
警告
This response code MAY be returned by the server in the OK response (but it might be returned with the NO/BYE response as well) and signals the client that even though the script is syntactically valid, it might contain errors not intended by the script writer. This response code is typically returned in response to PUTSCRIPT and/or CHECKSCRIPT commands. A client seeing such response code SHOULD present the returned warning text to the user.
この応答コードは、OK応答でサーバーによって返される場合があります（ただし、NO/BYE応答でも返される場合があります）。クライアントに、スクリプトが構文的に有効であるにもかかわらず、スクリプトによって意図されていないエラーが含まれている可能性があることをクライアントに通知します。作家。この応答コードは通常、PutScriptおよび/またはCheckscriptコマンドに応じて返されます。そのような応答コードを表示するクライアントは、返された警告テキストをユーザーに提示する必要があります。
A user may have multiple Sieve scripts on the server, yet only one script may be used for filtering of incoming messages. This is the active script. Users may have zero or one active script and MUST use the SETACTIVE command described below for changing the active script or disabling Sieve processing. For example, users may have an everyday script they normally use and a special script they use when they go on vacation. Users can change which script is being used without having to download and upload a script stored somewhere else.
ユーザーはサーバー上に複数のふるいスクリプトを持っている場合がありますが、着信メッセージのフィルタリングには1つのスクリプトのみを使用できます。これはアクティブなスクリプトです。ユーザーはゼロまたは1つのアクティブなスクリプトを持っている場合があり、アクティブなスクリプトを変更したり、ふるい処理を無効にしたりするために、以下に説明するSetactiveコマンドを使用する必要があります。たとえば、ユーザーは通常使用する日常のスクリプトと、休暇に行くときに使用する特別なスクリプトを持っている場合があります。ユーザーは、他の場所に保存されているスクリプトをダウンロードしてアップロードすることなく使用されているスクリプトを変更できます。
Servers SHOULD impose quotas to prevent malicious users from overflowing available storage. If a command would place a user over a quota setting, servers that impose such quotas MUST reply with a NO response containing the QUOTA response code. Client implementations MUST be able to handle commands failing because of quota restrictions.
サーバーは、悪意のあるユーザーが利用可能なストレージがあふれるのを防ぐためにクォータを課す必要があります。コマンドがユーザーをクォータ設定に配置する場合、そのようなクォータを押し付けるサーバーは、クォータ応答コードを含む応答なしで返信する必要があります。クライアントの実装は、クォータの制限のために失敗するコマンドを処理できる必要があります。
A Sieve script name is a sequence of Unicode characters encoded in UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition (Section 2 of [NET-UNICODE]), with the additional restriction of prohibiting the following Unicode characters:
ふるいスクリプト名は、UTF-8 [UTF-8]にエンコードされたユニコード文字のシーケンスです。スクリプト名は、次のUnicode文字を禁止する追加の制限があるため、ネットユニコード定義（[ネットユニコード]のセクション2）に準拠する必要があります。
o 0000-001F; [CONTROL CHARACTERS]
o 0000-001F;[文字をコントロール]
o 007F; DELETE
o 007f;消去
o 0080-009F; [CONTROL CHARACTERS] o 2028; LINE SEPARATOR
o 0080-009F;[コントロール文字] O 2028;ラインセパレーター
o 2029; PARAGRAPH SEPARATOR
o 2029;段落分離器
Sieve script names MUST be at least one octet (and hence Unicode character) long. Zero octets script name has a special meaning (see Section 2.8). Servers MUST allow names of up to 128 Unicode characters in length (which can take up to 512 bytes when encoded in UTF-8, not counting the terminating NUL), and MAY allow longer names. A server that receives a script name longer than its internal limit MUST reject the corresponding operation, in particular it MUST NOT truncate the script name.
ふるいスクリプト名は、少なくとも1つのオクテット（したがってユニコード文字）の長さでなければなりません。ゼロオクテットのスクリプト名には特別な意味があります（セクション2.8を参照）。サーバーは、長さが最大128個のユニコード文字の名前を許可する必要があります（UTF-8でエンコードされている場合は最大512バイト、終了したNULをカウントしない）、より長い名前を許可する場合があります。内部制限よりも長くスクリプト名を受信するサーバーは、対応する操作を拒否する必要があります。特に、スクリプト名を切り捨ててはなりません。
Server capabilities are sent automatically by the server upon a client connection, or after successful STARTTLS and AUTHENTICATE (which establishes a Simple Authentication and Security Layer (SASL)) commands. Capabilities may change immediately after a successfully completed STARTTLS command, and/or immediately after a successfully completed AUTHENTICATE command, and/or after a successfully completed UNAUTHENTICATE command (see Section 2.14.1). Capabilities MUST remain static at all other times.
サーバー機能は、クライアント接続時にサーバーによって自動的に送信されるか、StartTLSと認証（Simple認証およびセキュリティレイヤー（SASL）を確立する）コマンドを確立した後に自動的に送信されます。正常に完了したStartTLSコマンドの直後、および/または正常に完了した認証コマンドの直後、および/または正常に完了した非認証コマンドの直後に機能が変更される場合があります（セクション2.14.1を参照）。機能は、他のすべての時間で静的なままでなければなりません。
Clients MAY request the capabilities at a later time by issuing the CAPABILITY command described later. The capabilities consist of a series of lines each with one or two strings. The first string is the name of the capability, which is case-insensitive. The second optional string is the value associated with that capability. Order of capabilities is arbitrary, but each capability name can appear at most once.
クライアントは、後で説明する機能コマンドを発行することにより、後で機能を要求することができます。機能は、それぞれ1つまたは2つの文字列を持つ一連の線で構成されています。最初の文字列は機能の名前であり、これはケース非感受性です。2番目のオプション文字列は、その機能に関連付けられた値です。機能の順序は任意ですが、各機能名はせいぜい1回表示できます。
The following capabilities are defined in this document:
次の機能は、このドキュメントで定義されています。
IMPLEMENTATION - Name of implementation and version. This capability MUST always be returned by the server.
実装 - 実装とバージョンの名前。この機能は、サーバーによって常に返される必要があります。
SASL - List of SASL mechanisms supported by the server, each separated by a space. This list can be empty if and only if STARTTLS is also advertised. This means that the client must negotiate TLS encryption with STARTTLS first, at which point the SASL capability will list a non-empty list of SASL mechanisms.
SASL-サーバーがサポートするSASLメカニズムのリストは、それぞれスペースで区切られています。このリストは、startTLSも宣伝されている場合にのみ空にすることができます。これは、クライアントが最初にStartTLSとTLS暗号化を交渉する必要があることを意味します。その時点で、SASL機能はSASLメカニズムの空白のリストをリストします。
SIEVE - List of space-separated Sieve extensions (as listed in Sieve "require" action [SIEVE]) supported by the Sieve engine. This capability MUST always be returned by the server.
ふるい - ふるいエンジンでサポートされているスペース分離されたふるい拡張機能（ふるいに記載されている「必要」アクション[ふるい]にリストされています）のリスト。この機能は、サーバーによって常に返される必要があります。
STARTTLS - If TLS [TLS] is supported by this implementation. Before advertising this capability a server MUST verify to the best of its ability that TLS can be successfully negotiated by a client with common cipher suites. Specifically, a server should verify that a server certificate has been installed and that the TLS subsystem has successfully initialized. This capability SHOULD NOT be advertised once STARTTLS or AUTHENTICATE command completes successfully. Client and server implementations MUST implement the STARTTLS extension.
startTLS -TLS [TLS]がこの実装によってサポートされている場合。この機能を宣伝する前に、サーバーは、一般的な暗号スイートを持つクライアントによってTLSが正常にネゴシエートできることをその能力を最大限に確認する必要があります。具体的には、サーバーは、サーバー証明書がインストールされていること、およびTLSサブシステムが正常に初期化されていることを確認する必要があります。この機能は、startTlsまたは認証コマンドが正常に完了したら、宣伝しないでください。クライアントとサーバーの実装は、startTLS拡張機能を実装する必要があります。
MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" actions a script can perform during a single evaluation. Note that this is different from the total number of "redirect" actions a script can contain. The value is a non-negative number represented as a ManageSieve string.
maxredirects-単一の評価中にスクリプトが実行できるふるいの「リダイレクト」アクションの数の制限を指定します。これは、スクリプトに含めることができる「リダイレクト」アクションの総数とは異なることに注意してください。値は、manageSieve文字列として表される非陰性の数字です。
NOTIFY - A space-separated list of URI schema parts for supported notification methods. This capability MUST be specified if the Sieve implementation supports the "enotify" extension [NOTIFY].
NOTIFY-サポートされている通知方法のためのURIスキーマパーツのスペース分離リスト。Sieveの実装が「Enotify」拡張機能[Notify]をサポートする場合、この機能を指定する必要があります。
LANGUAGE - The language (<Language-Tag> from [RFC5646]) currently used for human-readable error messages. If this capability is not returned, the "i-default" [RFC2277] language is assumed. Note that the current language MAY be per-user configurable (i.e., it MAY change after authentication).
言語 - 人間が読み取るエラーメッセージに現在使用されている言語（[RFC5646]から<言語タグ>）。この機能が返されない場合、「i-default」[RFC2277]言語が想定されます。現在の言語は、ユーザーごとに構成可能である可能性があることに注意してください（つまり、認証後に変更される場合があります）。
OWNER - The canonical name of the logged-in user (SASL "authorization identity") encoded in UTF-8. This capability MUST NOT be returned in unauthenticated state and SHOULD be returned once the AUTHENTICATE command succeeds.
所有者 - UTF-8でエンコードされたログインドユーザー（SASL「認証ID」）の標準名。この能力は、認定されていない状態で返されてはならず、認証コマンドが成功したら返品する必要があります。
VERSION - This capability MUST be returned by servers compliant with this document or its successor. For servers compliant with this document, the capability value is the string "1.0". Lack of this capability means that the server predates this specification and thus doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT, and NOOP.
バージョン - この機能は、このドキュメントまたはその後継者に準拠したサーバーによって返される必要があります。このドキュメントに準拠したサーバーの場合、機能値は文字列「1.0」です。この機能がないということは、サーバーがこの仕様を前にしているため、次のコマンドをサポートしていないことを意味します：renamescript、checkscript、およびnoop。
Section 2.14 defines some additional ManageSieve extensions and their respective capabilities.
セクション2.14では、いくつかの追加のManagESIEMEESIEM拡張機能とそれぞれの機能を定義しています。
A server implementation MUST return SIEVE, IMPLEMENTATION, and VERSION capabilities.
サーバーの実装では、ふるい、実装、バージョンの機能を返す必要があります。
A client implementation MUST ignore any listed capabilities that it does not understand.
クライアントの実装では、理解できないリストされた機能を無視する必要があります。
Example:
例：
S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "fileinto vacation"
S: "StaRTTLS"
S: "NOTIFY" "xmpp mailto"
S: "MAXREdIRECTS" "5"
S: "VERSION" "1.0"
S: OK
After successful authentication, this might look like this:
認証が成功した後、これは次のようになる可能性があります。
Example:
例：
S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "fileinto vacation"
S: "NOTIFY" "xmpp mailto"
S: "OWNER" "alexey@example.com"
S: "MAXREdIRECTS" "5"
S: "VERSION" "1.0"
S: OK
The ManageSieve protocol assumes a reliable data stream such as that provided by TCP. When TCP is used, a ManageSieve server typically listens on port 4190.
ManageSieveプロトコルは、TCPが提供するような信頼できるデータストリームを想定しています。TCPを使用すると、ManageSieveサーバーは通常、ポート4190に耳を傾けます。
Before opening the TCP connection, the ManageSieve client first MUST resolve the Domain Name System (DNS) hostname associated with the receiving entity and determine the appropriate TCP port for communication with the receiving entity. The process is as follows:
TCP接続を開く前に、ManagESIEVEクライアントは、最初に受信エンティティに関連付けられたドメイン名システム（DNS）ホスト名を解決し、受信エンティティとの通信のために適切なTCPポートを決定する必要があります。プロセスは次のとおりです。
1. Attempt to resolve the hostname using a [DNS-SRV] Service of "sieve" and a Proto of "tcp" for the target domain (e.g., "example.net"), resulting in resource records such as "_sieve._tcp.example.net.". The result of the SRV lookup, if successful, will be one or more combinations of a port and hostname; the ManageSieve client MUST resolve the returned hostnames to IPv4/IPv6 addresses according to returned SRV record weight. IP addresses from the first successfully resolved hostname (with the corresponding port number returned by SRV lookup) are used to connect to the server. If connection using one of the IP addresses fails, the next resolved IP address is used to connect. If connection to all resolved IP addresses fails, then the resolution/connect is repeated for the next hostname returned by SRV lookup.
1. [DNS-SRV]サービスの[DNS-SRV]サービスを使用してホスト名を解決し、ターゲットドメインの「TCP」のプロト（「Example.Net」など）を使用して、「_sieve._tcp.exampleなどのリソースレコードを作成します。。ネット。"。成功した場合、SRVルックアップの結果は、ポートとホスト名の1つ以上の組み合わせになります。ManageSieveクライアントは、返されたSRVレコードの重量に従って、返されたホスト名をIPv4/IPv6アドレスに解決する必要があります。最初に正常に解決されたホスト名のIPアドレス（SRV Lookupによって返される対応するポート番号を使用）を使用してサーバーに接続します。IPアドレスのいずれかを使用して接続が失敗した場合、次に解決されたIPアドレスを使用して接続します。すべての解決されたIPアドレスへの接続が失敗した場合、SRV Lookupによって返される次のホスト名で解像度/接続が繰り返されます。
2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or IPv6 address record resolution to determine the IP address, where the port used is the default ManageSieve port of 4190.
2. SRVルックアップが失敗した場合、フォールバックは通常のIPv4またはIPv6アドレスレコード解像度である必要があります。これは、使用されるポートが4190のデフォルトのManageSieveポートであるIPアドレスを決定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されているように解釈されます。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Line breaks that do not start a new "C:" or "S:" exist for editorial reasons.
例では、「C：」と「S：」は、それぞれクライアントとサーバーによって送信された行を示します。編集上の理由から、新しい「C： "または「s：」を開始しないラインブレーク。
Examples of authentication in this document are using DIGEST-MD5 [DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms.
このドキュメントの認証の例は、Digest-MD5 [Digest-MD5]およびGSSAPI [GSSAPI] SASLメカニズムを使用することです。
This section and its subsections describe valid ManageSieve commands. Upon initial connection to the server, the client's session is in non-authenticated state. Prior to successful authentication, only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP (see Section 2.13) commands are valid. ManageSieve extensions MAY define other commands that are valid in non-authenticated state. Servers MUST reject all other commands with a NO response. Clients may pipeline commands (send more than one command at a time without waiting for completion of the first command). However, a group of commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS, or a HAVESPACE command anywhere but the last command in the list.
このセクションとそのサブセクションは、有効なManageSieveコマンドについて説明しています。サーバーへの最初の接続時に、クライアントのセッションは認識されていない状態になります。認証が成功する前に、認証、機能、startTLS、ログアウト、およびNOOPのみが有効です。ManageESIEVE拡張機能は、認識されていない状態で有効な他のコマンドを定義する場合があります。サーバーは、応答なしで他のすべてのコマンドを拒否する必要があります。クライアントはパイプラインコマンドを使用できます（最初のコマンドの完了を待つことなく、一度に複数のコマンドを送信します）。ただし、一緒に送信されるコマンドのグループには、リスト内の最後のコマンド以外のAuthenticate（*）、StartTLS、またはHavespaceコマンドを持たないでください。
(*) - The only exception to this rule is when the AUTHENTICATE command contains an initial response for a SASL mechanism that allows clients to send data first, the mechanism is known to complete in one round trip, and the mechanism doesn't negotiate a SASL security layer. Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL].
（*） - このルールの唯一の例外は、認証コマンドに、クライアントが最初にデータを送信できるようにするSASLメカニズムの初期応答を含む場合です。SASLセキュリティレイヤー。このようなSASLメカニズムの2つの例は、プレーン[プレーン]と外部[SASL]です。
Arguments: String - mechanism String - initial data (optional)
引数：文字列 - メカニズム文字列 - 初期データ（オプション）
The AUTHENTICATE command indicates a SASL [SASL] authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to identify and authenticate the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTHENTICATE command by sending the NO response.
認証コマンドは、サーバーに対するSASL [SASL]認証メカニズムを示します。サーバーが要求された認証メカニズムをサポートする場合、ユーザーを識別および認証するための認証プロトコル交換を実行します。オプションでは、後続のプロトコル相互作用のセキュリティレイヤーも交渉します。要求された認証メカニズムがサポートされていない場合、サーバーはNO応答を送信することにより認証コマンドを拒否します。
The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the selected authentication mechanism. A server challenge consists of a string (quoted or literal) followed by a CRLF. The contents of the string is a base-64 encoding [BASE64] of the SASL data. A client response consists of a string (quoted or literal) with the base-64 encoding of the SASL data followed by a CRLF. If the client wishes to cancel the authentication exchange, it issues a string containing a single "*". If the server receives such a response, it MUST reject the AUTHENTICATE command by sending a NO reply.
認証プロトコル交換は、選択した認証メカニズムに固有の一連のサーバーの課題とクライアント応答で構成されています。サーバーチャレンジは、文字列（引用またはリテラル）で構成され、その後にCRLFが続きます。文字列の内容は、SASLデータのベース64エンコード[base64]です。クライアントの応答は、SASLデータのベース64エンコードに続いてCRLFを使用した文字列（引用またはリテラル）で構成されています。クライアントが認証交換をキャンセルしたい場合、単一の「*」を含む文字列を発行します。サーバーがそのような応答を受信した場合、返信なしで認証コマンドを拒否する必要があります。
Note that an empty challenge/response is sent as an empty string. If the mechanism dictates that the final response is sent by the server, this data MAY be placed within the data portion of the SASL response code to save a round trip.
空の課題/応答は空の文字列として送信されることに注意してください。メカニズムがサーバーによって最終応答が送信されることを指示する場合、このデータは往復を保存するためにSASL応答コードのデータ部分内に配置される場合があります。
The optional initial-response argument to the AUTHENTICATE command is used to save a round trip when using authentication mechanisms that are defined to send no data in the initial challenge. When the initial-response argument is used with such a mechanism, the initial empty challenge is not sent to the client and the server uses the data in the initial-response argument as if it were sent in response to the empty challenge. If the initial-response argument to the AUTHENTICATE command is used with a mechanism that sends data in the initial challenge, the server MUST reject the AUTHENTICATE command by sending the NO response.
認証コマンドに対するオプションの初期応答引数は、最初の課題でデータを送信しないように定義された認証メカニズムを使用する場合、往復を保存するために使用されます。このようなメカニズムで初期応答の引数が使用される場合、最初の空の課題はクライアントに送信されず、サーバーは空の課題に応じて送信されたかのように初期応答引数でデータを使用します。認証コマンドに対する初期応答の引数が、初期チャレンジでデータを送信するメカニズムで使用される場合、サーバーはNO応答を送信することにより認証コマンドを拒否する必要があります。
The service name specified by this protocol's profile of SASL is "sieve".
このプロトコルのSASLのプロファイルによって指定されたサービス名は「ふるい」です。
Reauthentication is not supported by ManageSieve protocol's profile of SASL. That is, after a successfully completed AUTHENTICATE command, no more AUTHENTICATE commands may be issued in the same session. After a successful AUTHENTICATE command completes, a server MUST reject any further AUTHENTICATE commands with a NO reply.
再認証は、ManagESIEVEプロトコルのSASLのプロファイルによってサポートされていません。つまり、正常に完了したAuthenticate Commandの後、同じセッションでAuthenticateコマンドを発行することはできません。認証コマンドが完了した後、サーバーは返信なしでさらに認証コマンドを拒否する必要があります。
However, note that a server may implement the UNAUTHENTICATE extension described in Section 2.14.1.
ただし、サーバーはセクション2.14.1で説明されている非認証拡張機能を実装できることに注意してください。
If a security layer is negotiated through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the successful authentication exchange for the client, and the CRLF of the OK response for the server.
SASL認証交換を通じてセキュリティレイヤーが交渉された場合、クライアントの認証交換の成功とサーバーのOK応答のCRLFを締めくくるCRLFの直後に有効になります。
When a security layer takes effect, the ManageSieve protocol is reset to the initial state (the state in ManageSieve after a client has connected to the server). The server MUST discard any knowledge obtained from the client that was not obtained from the SASL (or TLS) negotiation itself. Likewise, the client MUST discard any knowledge obtained from the server, such as the list of ManageSieve extensions, that was not obtained from the SASL (and/or TLS) negotiation itself. (Note that a client MAY compare the advertised SASL mechanisms before and after authentication in order to detect an active down-negotiation attack. See below.)
セキュリティレイヤーが有効になると、ManagESIEVEプロトコルは初期状態にリセットされます（クライアントがサーバーに接続した後、ManagESIEVEの状態）。サーバーは、SASL（またはTLS）交渉自体から取得されなかったクライアントから取得した知識を廃棄する必要があります。同様に、クライアントは、SASL（および/またはTLS）のネゴシエーション自体から得られなかったManageSieve拡張機能のリストなど、サーバーから取得した知識を廃棄する必要があります。（アクティブな減少攻撃を検出するために、認証の前後に広告されたSASLメカニズムを比較することができることに注意してください。以下を参照してください。）
Once a SASL security layer is established, the server MUST re-issue the capability results, followed by an OK response. This is necessary to protect against man-in-the-middle attacks that alter the capabilities list prior to SASL negotiation. The capability results MUST include all SASL mechanisms the server was capable of negotiating with that client. This is done in order to allow the client to detect an active down-negotiation attack. If a user-oriented client detects such a down-negotiation attack, it SHOULD either notify the user (it MAY give the user the opportunity to continue with the ManageSieve session in this case) or close the transport connection and indicate that a down-negotiation attack might be in progress. If an automated client detects a down-negotiation attack, it SHOULD return or log an error indicating that a possible attack might be in progress and/or SHOULD close the transport connection.
SASLセキュリティレイヤーが確立されると、サーバーは機能の結果を再発行し、その後OK応答が続く必要があります。これは、SASLの交渉前に機能リストを変更する中間の攻撃から保護するために必要です。機能の結果には、サーバーがそのクライアントと交渉できるすべてのSASLメカニズムを含める必要があります。これは、クライアントがアクティブな減少攻撃を検出できるようにするために行われます。ユーザー指向のクライアントがこのような低交渉攻撃を検出した場合、ユーザーに通知する（この場合、ユーザーにManagESIEVEセッションを継続する機会を与える）か、トランスポート接続を閉じて、ダウンネゴシエーションを示す必要があります。攻撃が進行中である可能性があります。自動化されたクライアントがネゴシエーションダウン攻撃を検出した場合、可能な攻撃が進行中である可能性があることを示すエラーを返したり、ログにしたりする必要があります。
When both [TLS] and SASL security layers are in effect, the TLS encoding MUST be applied (when sending data) after the SASL encoding.
[TLS]とSASLセキュリティレイヤーの両方が有効な場合、SASLエンコード後にTLSエンコードを適用する必要があります（データを送信するとき）。
Server implementations SHOULD support SASL proxy authentication so that an administrator can administer a user's scripts. Proxy authentication is when a user authenticates as herself/himself but requests the server to act (authorize) as another user.
サーバーの実装は、管理者がユーザーのスクリプトを管理できるように、SASLプロキシ認証をサポートする必要があります。プロキシ認証とは、ユーザーが自分自身/自分自身として認証するが、サーバーに別のユーザーとして行動する（承認）することを要求する場合です。
The authorization identity generated by this [SASL] exchange is a "simple username" (in the sense defined in [SASLprep]), and both client and server MUST use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
この[SASL] Exchangeによって生成された認証IDは「単純なユーザー名」（[SASLPrep]で定義されている意味）であり、クライアントとサーバーの両方が[StringPrep]アルゴリズムの[SASLPrep]プロファイルを使用してこれらの名前を準備する必要があります。送信または比較。承認IDの準備が失敗するか、空の文字列になった場合（空の文字列として送信されない限り）、サーバーは認証に失敗する必要があります。
If an AUTHENTICATE command fails with a NO response, the client MAY try another authentication mechanism by issuing another AUTHENTICATE command. In other words, the client may request authentication types in decreasing order of preference.
認証コマンドがNO応答で失敗した場合、クライアントは別の認証コマンドを発行することにより、別の認証メカニズムを試すことができます。つまり、クライアントは、優先順位を減らす際に認証タイプを要求する場合があります。
Note that a failed (NO) response to the AUTHENTICATE command may contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-NEEDED, or TRANSITION-NEEDED. See Section 1.3 for detailed description of the relevant conditions.
認証コマンドに対する失敗した（NO）応答には、次の応答コードのいずれかが含まれている場合があります。関連する条件の詳細な説明については、セクション1.3を参照してください。
To ensure interoperability, both client and server implementations of the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL mechanism, as well as [PLAIN] over [TLS].
相互運用性を確保するために、ManagESIEVEプロトコルのクライアントとサーバーの実装の両方が、[TLS]を介した[プレーン]と同様に、SCRAM-SHA-1 [SCRAM] SASLメカニズムを実装する必要があります。
Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in other email-related protocols; however, a longer-term goal is to migrate email-related protocols from using PLAIN over TLS to SCRAM-SHA-1 mechanism.
注：Plane over TLSの使用は、他の電子メール関連のプロトコルでのTLSを超えるPlaneの現在の使用を反映しています。ただし、長期的な目標は、電子メール関連のプロトコルを、TLSを超えてScram-Sha-1メカニズムにPlainを使用することから移行することです。
Examples (Note that long lines are folded for readability and are not part of protocol exchange):
例（読みやすくするために長い線が折りたたまれ、プロトコル交換の一部ではないことに注意してください）：
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: "VERSION" "1.0"
S: OK
C: Authenticate "DIGEST-MD5"
S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
cyxjaGFyc2V0PXV0Zi04"
C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
A9YXV0aA=="
S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
mZmZA==")
A slightly different variant of the same authentication exchange is:
同じ認証交換のわずかに異なるバリアントは次のとおりです。
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "VERSION" "1.0"
S: "STARTTLS"
S: OK
C: Authenticate "DIGEST-MD5"
S: {136}
S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
cyxjaGFyc2V0PXV0Zi04
C: {300+}
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
A9YXV0aA==
S: {56}
S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
C: ""
S: OK
Another example demonstrating use of SASL PLAIN mechanism under TLS follows. This example also demonstrate use of SASL "initial response" (the second parameter to the Authenticate command):
TLSの下でのSASLプレーンメカニズムの使用を示す別の例が続きます。この例は、SASLの「初期応答」（認証コマンドの2番目のパラメーター）の使用も示しています。
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" ""
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: OK
C: STARTTLS
S: OK
<TLS negotiation, further commands are under TLS layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN"
S: "SIEVE" "fileinto vacation"
S: OK
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
S: NO
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
S: NO
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
S: BYE "Too many failed authentication attempts"
<Server closes connection>
The following example demonstrates use of SASL "initial response". It also demonstrates that an empty response can be sent as a literal and that negotiating a SASL security layer results in the server re-issuing server capabilities:
次の例は、SASLの「初期応答」の使用を示しています。また、空の応答が文字通りとして送信され、SASLセキュリティレイヤーを交渉するとサーバーがサーバー機能を再発行することができることも示しています。
C: AUTHENTICATE "GSSAPI" {1488+}
C: YIIE[...1480 octets here ...]dA==
S: {208}
S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
[...114 octets here ...]
/yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
C: {0+}
C:
S: {44}
S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
C: {44+}
C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
S: OK
<Further commands/responses are under SASL security layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "LANGUAGE" "ru"
S: "MAXREDIRECTS" "3"
S: ok
This section is normative for ManageSieve client implementations that support SASL [PLAIN] over [TLS].
このセクションは、[TLS]よりもSASL [Plain]をサポートするクライアントの実装をManageSiveの規範です。
If a ManageSieve client is willing to use SASL PLAIN over TLS to authenticate to the ManageSieve server, the client MUST verify the server identity (see Section 2.2.1). If the server identity can't be verified (e.g., the server has not provided any certificate, or if the certificate verification fails), the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism.
ManageSieveクライアントがTLSを介してSASLプレーンを使用してManageSieveサーバーに認証することをいとわない場合、クライアントはサーバーIDを確認する必要があります（セクション2.2.1を参照）。サーバーのIDを検証できない場合（たとえば、サーバーが証明書を提供していない、または証明書の確認が失敗した場合）、クライアントはSASLプレーンメカニズムを使用して認証を試みてはなりません。
Support for STARTTLS command in servers is optional. Its availability is advertised with "STARTTLS" capability as described in Section 1.7.
サーバー内のstartTLSコマンドのサポートはオプションです。その可用性は、セクション1.7で説明されている「StartTLS」機能で宣伝されています。
The STARTTLS command requests commencement of a TLS [TLS] negotiation. The negotiation begins immediately after the CRLF in the OK response. After a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete.
StartTLSコマンドは、TLS [TLS]ネゴシエーションの開始を要求します。交渉は、OK応答でCRLFの直後に始まります。クライアントがStartTLSコマンドを発行した後、サーバーの応答が見られ、TLS交渉が完了するまで、コマンドをさらに発行しないでください。
The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism.
StartTLSコマンドは、認識されていない状態でのみ有効です。サーバーは、TLS交渉中にクライアントの資格情報が提供されたとしても、非認識状態のままです。SASL [SASL]外部メカニズムは、TLSクライアント資格情報が正常に交換されると認証するために使用できますが、StartTLSコマンドをサポートするサーバーは、外部メカニズムをサポートするために必要ありません。
After the TLS layer is established, the server MUST re-issue the capability results, followed by an OK response. This is necessary to protect against man-in-the-middle attacks that alter the capabilities list prior to STARTTLS. This capability result MUST NOT include the STARTTLS capability.
TLSレイヤーが確立された後、サーバーは機能の結果を再発行し、その後OK応答が続く必要があります。これは、StartTLSの前に機能リストを変更する中間の攻撃から保護するために必要です。この機能の結果には、startTLS機能を含めてはなりません。
The client MUST discard cached capability information and replace it with the new information. The server MAY advertise different capabilities after STARTTLS.
クライアントは、キャッシュされた機能情報を破棄し、新しい情報に置き換える必要があります。サーバーは、startTLS後にさまざまな機能を宣伝する場合があります。
Example:
例：
C: StartTls
S: oK
<TLS negotiation, further commands are under TLS layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "VERSION" "1.0"
S: "LANGUAGE" "fr"
S: ok
During the TLS negotiation, the ManageSieve client MUST check its understanding of the server hostname/IP address against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. In this section, the client's understanding of the server's identity is called the "reference identity".
TLS交渉中、ManagESIEVEクライアントは、中間の攻撃を防ぐために、サーバー証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名/IPアドレスの理解を確認する必要があります。このセクションでは、サーバーのアイデンティティに対するクライアントの理解は「参照ID」と呼ばれます。
Checking is performed according to the following rules:
チェックは、次のルールに従って実行されます。
o If the reference identity is a hostname:
o 参照IDがホスト名の場合：
1. If a subjectAltName extension of the SRVName [X509-SRV], dNSName [X509] (in that order of preference) type is present in the server's certificate, then it SHOULD be used as the source of the server's identity. Matching is performed as described in Section 2.2.1.1, with the exception that no wildcard matching is allowed for SRVName type. If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
1. srvname [x509-srv]のsubjectaltname拡張機能がサーバーの証明書にdnsname [x509]（その順序で）タイプが存在する場合、サーバーのIDのソースとして使用する必要があります。セクション2.2.1.1で説明されているようにマッチングは実行されます。証明書に複数の名前（たとえば、複数のDNSNAMEフィールドなど）が含まれている場合、フィールドのいずれかと一致すると、受け入れられると見なされます。
2. The client MAY use other types of subjectAltName for performing comparison.
2. クライアントは、比較を実行するために他のタイプのsumberaltnameを使用する場合があります。
3. The server's identity MAY also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 2.2.1.1, below. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention.
3. サーバーのIDは、サーバーの証明書の主題フィールドの葉の相対識別名（RDN）の共通名（CN）[RFC4519]値と参照ID [RFC4519]値を比較することにより、検証することもできます。この比較は、以下のセクション2.2.1.1のDNS名を比較するためのルールを使用して実行されます。一般名値の使用は既存の慣行ですが、それは非推奨であり、認定当局は代わりにsubjectaltname値を提供することを奨励されています。TLS実装は、X.500またはその他の規則に従って証明書のDNSを表す場合があることに注意してください。たとえば、一部のX.500実装は、LDAPの左から左右の条約ではなく、左から右（最も重要なものから最も重要な）条約を使用してDNでRDNを注文します。
o When the reference identity is an IP address, the iPAddress subjectAltName SHOULD be used by the client for comparison. The comparison is performed as described in Section 2.2.1.2.
o 参照IDがIPアドレスである場合、iPaddressのsubjectaltnameをクライアントが比較するために使用する必要があります。比較は、セクション2.2.1.2で説明されているように実行されます。
If the server identity check fails, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the ManageSieve session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD return or log an error indicating that the server's identity is suspect and/or SHOULD close the transport connection. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it.
サーバーIDのチェックが失敗した場合、ユーザー指向のクライアントはユーザー（クライアントにユーザーにManagESIEVEセッションを継続する機会を与えてもらうか）か、トランスポート接続を閉じて、サーバーのIDが疑わしいことを示します。自動化されたクライアントは、サーバーのIDが疑わしい、または輸送接続を閉じる必要があることを示すエラーを返したりログにしたりする必要があります。自動化されたクライアントは、このチェックを無効にする構成設定を提供する場合がありますが、それを有効にする設定を提供する必要があります。
Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination.
このセクションで説明されているサーバーIDチェックを超えて、クライアントは、提供するように要求されるサービスを提供することをサーバーが許可されていることを確認するために、さらにチェックする準備をする必要があります。クライアントは、この決定を行う際にローカルポリシー情報を利用する必要がある場合があります。
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of [RFC3490] as follows:
参照IDが国際化されたドメイン名である場合、適合実装は、タイプDNSNAMEのsumbuctAltName値と比較する前に、RFC 3490 [RFC3490]のセクション4で指定されているように、ASCII互換エンコード（ACE）形式に変換する必要があります。具体的には、[RFC3490]のセクション4で指定された変換操作を次のように実行する必要があります。
o in step 1, the domain name SHALL be considered a "stored string";
o ステップ1では、ドメイン名は「保存された文字列」と見なされます。
o in step 3, set the flag called "UseSTD3ASCIIRules";
o ステップ3では、「uesestd3asciirules」と呼ばれるフラグを設定します。
o in step 4, process each label with the "ToASCII" operation; and
o ステップ4では、各ラベルを「Toascii」操作で処理します。と
o in step 5, change all label separators to U+002E (full stop).
o ステップ5では、すべてのラベルセパレーターをU 002E（フルストップ）に変更します。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of [RFC3490]; i.e., once all label separators are replaced with U+002E (dot) they are compared in the case-insensitive manner.
「to-ascii」変換を実行した後、[RFC3490]のセクション3で指定されたルールに従って、DNSラベルと名前を平等と比較する必要があります。つまり、すべてのラベルセパレータがu 002e（dot）に置き換えると、ケース非感受性の方法で比較されます。
The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
'*'（ASCII 42）ワイルドカード文字は、タイプDNSNameのsubjectaltname値で許可され、次にその値の左端（最小重要な）DNSラベルとしてのみ許可されます。このワイルドカードは、サーバー名の左端のDNSラベルと一致します。つまり、件名 *.example.comはサーバー名A.example.comおよびB.Example.comと一致しますが、example.comまたはA.B.example.comと一致しません。
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP Version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
参照IDがIPアドレスである場合、IDは「ネットワークバイトの順序」Octet String表現[RFC791] [RFC2460]に変換する必要があります。IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列には正確に4オクテットが含まれます。IPバージョン6の場合、RFC 2460で指定されているように、オクテット文字列には正確に16のオクテットが含まれます。次に、このOctet文字列は、iPaddressのタイプのsubjectaltname値と比較されます。参照IDオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
Client implementations MAY support matching against subjectAltName values of other types as described in other documents.
クライアントの実装は、他のドキュメントで説明されているように、他のタイプのsumberaltaltname値との一致をサポートする場合があります。
The client sends the LOGOUT command when it is finished with a connection and wishes to terminate it. The server MUST reply with an OK response. The server MUST ignore commands issued by the client after the LOGOUT command.
クライアントは、接続が完了したときにログアウトコマンドを送信し、終了したいと考えます。サーバーはOK応答で返信する必要があります。サーバーは、ログアウトコマンドの後にクライアントが発行したコマンドを無視する必要があります。
The client SHOULD wait for the OK response before closing the connection. This avoids the TCP connection going into the TIME_WAIT state on the server. In order to avoid going into the TIME_WAIT TCP state, the server MAY wait for a short while for the client to close the TCP connection first. Whether or not the server waits for the client to close the connection, it MUST then close the connection itself.
クライアントは、接続を閉じる前にOK応答を待つ必要があります。これにより、TCP接続がサーバー上のtime_wait状態に移動することを回避します。Time_Wait TCP状態に入ることを避けるために、サーバーはクライアントが最初にTCP接続を閉じるのを少し待つことができます。サーバーがクライアントが接続を閉じるのを待つかどうかにかかわらず、接続自体を閉じる必要があります。
Example:
例：
C: Logout
S: Ok
<connection is terminated>
The CAPABILITY command requests the server capabilities as described earlier in this document. It has no parameters.
機能コマンドは、このドキュメントの前述のようにサーバー機能を要求します。パラメーターはありません。
Example:
例：
C: CAPABILITY
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: OK
Arguments: String - name Number - script size
引数：文字列 - 名前番号 - スクリプトサイズ
The HAVESPACE command is used to query the server for available space. Clients specify the name they wish to save the script as and its size in octets. Both parameters can be used by the server to see if the script with the specified name and size is within a user's quota(s). For example, the server MAY use the script name to check if a script would be replaced or a new one would be created. Servers respond with a NO if storing a script with that name and size would fail or OK otherwise. Clients SHOULD issue this command before attempting to place a script on the server.
Havespaceコマンドは、使用可能なスペースをサーバーに照会するために使用されます。クライアントは、スクリプトを保存したい名前とそのサイズをオクテットに指定します。両方のパラメーターをサーバーで使用して、指定された名前とサイズのスクリプトがユーザーの割り当て内にあるかどうかを確認できます。たとえば、サーバーはスクリプト名を使用して、スクリプト名が交換されるか、新しいものが作成されるかを確認できます。サーバーは、その名前とサイズを使用してスクリプトを保存すると、それ以外の場合は故障するかOKで応答します。クライアントは、サーバーにスクリプトを配置しようとする前に、このコマンドを発行する必要があります。
Note that the OK response from the HAVESPACE command does not constitute a guarantee of success as server disk space conditions could change between the client issuing the HAVESPACE and the client issuing the PUTSCRIPT commands. A QUOTA response code (see Section 1.3) remains a possible (albeit unlikely) response to a subsequent PUTSCRIPT with the same name and size.
HavespaceコマンドからのOK応答は、サーバーディスクのスペース条件がHavespaceを発行するクライアントとPutScriptコマンドを発行するクライアントとの間で変化する可能性があるため、成功の保証を構成しないことに注意してください。クォータ応答コード（セクション1.3を参照）は、同じ名前とサイズを持つ後続のPutScriptに対する（可能性は低いとはいえ）可能性のある（可能性は低い）可能性があります。
Example:
例：
C: HAVESPACE "myscript" 999999
S: NO (QUOTA/MAXSIZE) "Quota exceeded"
C: HAVESPACE "foobar" 435
S: OK
Arguments: String - Script name String - Script content
引数：文字列 - スクリプト名文字列 - スクリプトコンテンツ
The PUTSCRIPT command is used by the client to submit a Sieve script to the server.
PutScriptコマンドは、クライアントがサーバーにシーブスクリプトを送信するために使用されます。
If the script already exists, upon success the old script will be overwritten. The old script MUST NOT be overwritten if PUTSCRIPT fails in any way. A script of zero length SHOULD be disallowed.
スクリプトが既に存在する場合、成功すると古いスクリプトが上書きされます。PutScriptが何らかの方法で失敗した場合、古いスクリプトを上書きしないでください。ゼロの長さのスクリプトを許可する必要があります。
This command places the script on the server. It does not affect whether the script is processed on incoming mail, unless it replaces the script that is already active. The SETACTIVE command is used to mark a script as active.
このコマンドは、スクリプトをサーバーに配置します。すでにアクティブなスクリプトを置き換えない限り、スクリプトが着信メールで処理されているかどうかは影響しません。Setactiveコマンドは、スクリプトをアクティブとしてマークするために使用されます。
When submitting large scripts, clients SHOULD use the HAVESPACE command beforehand to query if the server is willing to accept a script of that size.
大規模なスクリプトを送信するとき、クライアントは、サーバーがそのサイズのスクリプトを受け入れる意思がある場合、事前にHavespaceコマンドを使用してクエリする必要があります。
The server MUST check the submitted script for validity, which includes checking that the script complies with the Sieve grammar [SIEVE] and that all Sieve extensions mentioned in the script's "require" statement(s) are supported by the Sieve interpreter. (Note that if the Sieve interpreter supports the Sieve "ihave" extension [I-HAVE], any unrecognized/unsupported extension mentioned in the "ihave" test MUST NOT cause the validation failure.) Other checks such as validating the supplied command arguments for each command MAY be performed. Essentially, the performed validation SHOULD be the same as performed when compiling the script for execution. Implementations that use a binary representation to store compiled scripts can extend the validation to a full compilation, in order to avoid validating uploaded scripts multiple times.
サーバーは、提出されたスクリプトの有効性を確認する必要があります。これには、スクリプトがふるい文法[ふるい]に準拠していること、スクリプトの「要求」ステートメントに記載されているすべてのふるい拡張がシーブ通訳者によってサポートされていることを確認することが含まれます。（ふるいインタープリターがふるいの「ihave」拡張[i-have]をサポートしている場合、「ihave」テストで言及されている認識されていない/サポートされていない拡張機能が検証障害を引き起こしてはならないことに注意してください。）各コマンドを実行できます。基本的に、実行された検証は、実行のためにスクリプトをコンパイルするときに実行されたものと同じでなければなりません。バイナリ表現を使用してコンパイルされたスクリプトを保存する実装は、アップロードされたスクリプトの検証を複数回回避するために、検証を完全なコンパイルに拡張できます。
If the script fails the validation, the server MUST reply with a NO response. Any script that fails the validity test MUST NOT be stored on the server. The message given with a NO response MUST be human readable and SHOULD contain a specific error message giving the line number of the first error. Implementors should strive to produce helpful error messages similar to those given by programming language compilers. Client implementations should note that this may be a multiline literal string with more than one error message separated by CRLFs. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8].
スクリプトが検証に失敗した場合、サーバーは応答なしで返信する必要があります。有効性テストに失敗したスクリプトは、サーバーに保存されてはなりません。応答なしで指定されたメッセージは、人間の読み取り可能である必要があり、最初のエラーの行番号を与える特定のエラーメッセージを含める必要があります。実装者は、プログラミング言語コンパイラによって与えられたものと同様の有用なエラーメッセージを作成するよう努力する必要があります。クライアントの実装は、これがCRLFによって区切られた複数のエラーメッセージを備えたマルチラインリテラル文字列である可能性があることに注意する必要があります。人間の読み取り可能なメッセージは、UTF-8 [UTF-8]にエンコードされた最新の言語能力（または「i-default」、セクション1.7を参照）で返される言語にあります。
An OK response MAY contain the WARNINGS response code. In such a case the human-readable message that follows the OK response SHOULD contain a specific warning message (or messages) giving the line number(s) in the script that might contain errors not intended by the script writer. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a response code SHOULD present the message to the user.
OK応答には、警告応答コードが含まれる場合があります。そのような場合、OK応答に続く人間の読み取り可能なメッセージには、スクリプトライターによって意図されていないエラーが含まれている可能性がある特定の警告メッセージ（またはメッセージ）をスクリプト内に与える特定の警告メッセージ（またはメッセージ）を含める必要があります。人間の読み取り可能なメッセージは、UTF-8 [UTF-8]にエンコードされた最新の言語能力（または「i-default」、セクション1.7を参照）で返される言語にあります。そのような応答コードを見るクライアントは、ユーザーにメッセージを提示する必要があります。
Examples:
例：
C: Putscript "foo" {31+}
C: #comment
C: InvalidSieveCommand
C:
S: NO "line 2: Syntax error"
C: Putscript "mysievescript" {110+}
C: require ["fileinto"];
C:
C: if envelope :contains "to" "tmartin+sent" {
C: fileinto "INBOX.sent";
C: }
S: OK
C: Putscript "myforwards" {190+}
C: redirect "111@example.net";
C:
C: if size :under 10k {
C: redirect "mobile@cell.example.com";
C: }
C:
C: if envelope :contains "to" "tmartin+lists" {
C: redirect "lists@groups.example.com";
C: }
S: OK (WARNINGS) "line 8: server redirect action
limit is 2, this redirect might be ignored"
This command lists the scripts the user has on the server. Upon success, a list of CRLF-separated script names (each represented as a quoted or literal string) is returned followed by an OK response. If there exists an active script, the atom ACTIVE is appended to the corresponding script name. The atom ACTIVE MUST NOT appear on more than one response line.
このコマンドは、ユーザーがサーバー上に持っているスクリプトをリストします。成功すると、CRLF分離されたスクリプト名（それぞれが引用符または文字通りの文字列として表される）のリストが返され、その後OK応答が続きます。アクティブなスクリプトが存在する場合、Atom Activeが対応するスクリプト名に追加されます。アクティブな原子は、複数の応答ラインに表示されてはなりません。
Example:
例：
C: Listscripts
S: "summer_script"
S: "vacation_script"
S: {13}
S: clever"script
S: "main_script" ACTIVE
S: OK
C: listscripts
S: "summer_script"
S: "main_script" active
S: OK
Arguments: String - script name
引数：文字列 - スクリプト名
This command sets a script active. If the script name is the empty string (i.e., ""), then any active script is disabled. Disabling an active script when there is no script active is not an error and MUST result in an OK reply.
このコマンドは、スクリプトをアクティブに設定します。スクリプト名が空の文字列（つまり、 ""）である場合、アクティブなスクリプトはすべて無効になります。アクティブなスクリプトを無効にするスクリプトがアクティブでない場合は、エラーではなく、OK応答になる必要があります。
If the script does not exist on the server, then the server MUST reply with a NO response. Such a reply SHOULD contain the NONEXISTENT response code.
スクリプトがサーバーに存在しない場合、サーバーは応答なしで返信する必要があります。このような返信には、存在しない応答コードが含まれている必要があります。
Examples:
例：
C: Setactive "vacationscript"
S: Ok
C: Setactive ""
S: Ok
C: Setactive "baz"
S: No (NONEXISTENT) "There is no script by that name"
C: Setactive "baz"
S: No (NONEXISTENT) {31}
S: There is no script by that name
Arguments: String - script name
引数：文字列 - スクリプト名
This command gets the contents of the specified script. If the script does not exist, the server MUST reply with a NO response. Such a reply SHOULD contain the NONEXISTENT response code.
このコマンドは、指定されたスクリプトの内容を取得します。スクリプトが存在しない場合、サーバーは応答なしで返信する必要があります。このような返信には、存在しない応答コードが含まれている必要があります。
Upon success, a string with the contents of the script is returned followed by an OK response.
成功すると、スクリプトの内容を含む文字列が返され、その後OK応答が続きます。
Example:
例：
C: Getscript "myscript"
S: {54}
S: #this is my wonderful script
S: reject "I reject all";
S:
S: OK
Arguments: String - script name
引数：文字列 - スクリプト名
This command is used to delete a user's Sieve script. Servers MUST reply with a NO response if the script does not exist. Such responses SHOULD include the NONEXISTENT response code.
このコマンドは、ユーザーのふるいスクリプトを削除するために使用されます。スクリプトが存在しない場合、サーバーは応答なしで返信する必要があります。そのような応答には、存在しない応答コードを含める必要があります。
The server MUST NOT allow the client to delete an active script, so the server MUST reply with a NO response if attempted. Such a response SHOULD contain the ACTIVE response code. If a client wishes to delete an active script, it should use the SETACTIVE command to disable the script first.
サーバーは、クライアントがアクティブなスクリプトを削除することを許可してはならないため、サーバーは試行された場合は応答なしで返信する必要があります。このような応答には、アクティブな応答コードが含まれている必要があります。クライアントがアクティブなスクリプトを削除することを希望する場合、Setactiveコマンドを使用して最初にスクリプトを無効にする必要があります。
Example:
例：
C: Deletescript "foo"
S: Ok
C: Deletescript "baz"
S: No (ACTIVE) "You may not delete an active script"
Arguments: String - Old Script name String - New Script name
引数：文字列 - 古いスクリプト名文字列 - 新しいスクリプト名
This command is used to rename a user's Sieve script. Servers MUST reply with a NO response if the old script does not exist (in which case the NONEXISTENT response code SHOULD be included), or a script with the new name already exists (in which case the ALREADYEXISTS response code SHOULD be included). Renaming the active script is allowed; the renamed script remains active.
このコマンドは、ユーザーのふるいスクリプトの名前を変更するために使用されます。サーバーは、古いスクリプトが存在しない場合（この場合は存在しない応答コードを含める必要がある）、または新しい名前を持つスクリプトが既に存在する場合（この場合、既に除外の応答コードを含める必要がある）、応答なしで返信する必要があります。アクティブなスクリプトの名前の変更は許可されています。名前変更されたスクリプトはアクティブのままです。
Example:
例：
C: Renamescript "foo" "bar"
S: Ok
C: Renamescript "baz" "bar"
S: No "bar already exists"
If the server doesn't support the RENAMESCRIPT command, the client can emulate it by performing the following steps:
サーバーがrenamescriptコマンドをサポートしていない場合、クライアントは次の手順を実行することでそれをエミュレートできます。
1. List available scripts with LISTSCRIPTS. If the script with the new script name exists, then the client should ask the user whether to abort the operation, to replace the script (by issuing the DELETESCRIPT <newname> after that), or to choose a different name.
1. リストスクリプトを含む利用可能なスクリプトをリストします。新しいスクリプト名が付いたスクリプトが存在する場合、クライアントはユーザーに操作を中止するか、スクリプトを置き換えるか（その後削除<NewName>を発行するか）、または別の名前を選択するかどうかを尋ねる必要があります。
2. Download the old script with GETSCRIPT <oldname>.
2. GetScript <OldName>を使用して古いスクリプトをダウンロードします。
3. Upload the old script with the new name: PUTSCRIPT <newname>.
3. 古いスクリプトを新しい名前でアップロードします：putscript <NewName>。
4. If the old script was active (as reported by LISTSCRIPTS in step 1), then make the new script active: SETACTIVE <newname>.
4. 古いスクリプトがアクティブである場合（ステップ1のListScriptsで報告されているように）、新しいスクリプトをアクティブにします：Setactive <NewName>。
5. Delete the old script: DELETESCRIPT <oldname>.
5. 古いスクリプトを削除：削除<OldName>。
Note that these steps don't describe how to handle various other error conditions (for example, NO response containing QUOTA response code in step 3). Error handling is left as an exercise for the reader.
これらの手順は、他のさまざまなエラー条件を処理する方法を説明していないことに注意してください（たとえば、ステップ3にクォータ応答コードを含む応答はありません）。エラー処理は、読者の演習として残されています。
Arguments: String - Script content
引数：文字列 - スクリプトコンテンツ
The CHECKSCRIPT command is used by the client to verify Sieve script validity without storing the script on the server.
CheckScriptコマンドは、サーバーにスクリプトを保存せずにシーブスクリプトの妥当性を確認するためにクライアントによって使用されます。
The server MUST check the submitted script for syntactic validity, which includes checking that all Sieve extensions mentioned in Sieve script "require" statement(s) are supported by the Sieve interpreter. (Note that if the Sieve interpreter supports the Sieve "ihave" extension [I-HAVE], any unrecognized/unsupported extension mentioned in the "ihave" test MUST NOT cause the syntactic validation failure.) If the script fails this test, the server MUST reply with a NO response. The message given with a NO response MUST be human readable and SHOULD contain a specific error message giving the line number of the first error. Implementors should strive to produce helpful error messages similar to those given by programming language compilers. Client implementations should note that this may be a multiline literal string with more than one error message separated by CRLFs. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8].
サーバーは、提出されたスクリプトに構文の妥当性を確認する必要があります。これには、シーブスクリプトに記載されているすべてのふるい拡張機能が「必要」ステートメントがシーブインタープリターによってサポートされていることを確認することが含まれます。（ふるいインタープリターがふるいの「ihave」拡張[i-have]をサポートしている場合、「ihave」テストで言及されている認識されていない/サポートされていない拡張機能が構文検証障害を引き起こしてはならないことに注意してください。）スクリプトがこのテストに失敗した場合、サーバーはサーバーです。応答なしで返信する必要があります。応答なしで指定されたメッセージは、人間の読み取り可能である必要があり、最初のエラーの行番号を与える特定のエラーメッセージを含める必要があります。実装者は、プログラミング言語コンパイラによって与えられたものと同様の有用なエラーメッセージを作成するよう努力する必要があります。クライアントの実装は、これがCRLFによって区切られた複数のエラーメッセージを備えたマルチラインリテラル文字列である可能性があることに注意する必要があります。人間の読み取り可能なメッセージは、UTF-8 [UTF-8]にエンコードされた最新の言語能力（または「i-default」、セクション1.7を参照）で返される言語にあります。
Examples:
例：
C: CheckScript {31+}
C: #comment
C: InvalidSieveCommand
C:
S: NO "line 2: Syntax error"
A ManageSieve server supporting this command MUST NOT check if the script will put the current user over its quota limit.
このコマンドをサポートするManageSiveサーバーは、スクリプトが現在のユーザーをクォータの制限に及ぼすかどうかを確認してはなりません。
An OK response MAY contain the WARNINGS response code. In such a case, the human-readable message that follows the OK response SHOULD contain a specific warning message (or messages) giving the line number(s) in the script that might contain errors not intended by the script writer. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a response code SHOULD present the message to the user.
OK応答には、警告応答コードが含まれる場合があります。そのような場合、OK応答に続く人間の読み取り可能なメッセージには、スクリプトライターによって意図されていないエラーが含まれている可能性がある特定の警告メッセージ（またはメッセージ）をスクリプト内に与える特定の警告メッセージ（またはメッセージ）を含める必要があります。人間の読み取り可能なメッセージは、UTF-8 [UTF-8]にエンコードされた最新の言語能力（または「i-default」、セクション1.7を参照）で返される言語にあります。そのような応答コードを見るクライアントは、ユーザーにメッセージを提示する必要があります。
Arguments: String - tag to echo back (optional)
引数：文字列 - エコーバックへのタグ（オプション）
The NOOP command does nothing, beyond returning a response to the client. It may be used by clients for protocol re-synchronization or to reset any inactivity auto-logout timer on the server.
NOOPコマンドは、クライアントへの応答を返す以外に何もしません。これは、クライアントがプロトコルの再同期に使用するか、サーバー上の不活性自動ログアウトタイマーをリセットするために使用する場合があります。
The response to the NOOP command is always OK, followed by the TAG response code together with the supplied string. If no string was supplied in the NOOP command, the TAG response code MUST NOT be included.
NOOPコマンドへの応答は常に問題であり、その後に付属の文字列と一緒にタグ応答コードが続きます。NOOPコマンドに文字列が提供されていない場合、タグ応答コードを含めてはなりません。
Examples:
例：
C: NOOP
S: OK "NOOP completed"
C: NOOP "STARTTLS-SYNC-42"
S: OK (TAG {16}
S: STARTTLS-SYNC-42) "Done"
The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" capability with no parameters) defines a new UNAUTHENTICATE command, which allows a client to return the server to non-authenticated state. Support for this extension is RECOMMENDED.
Unauthenticate拡張機能（パラメーターなしの「非認証」機能として宣伝されている）は、クライアントがサーバーを認証状態に戻すことができる新しいUnauthenticateコマンドを定義します。この拡張機能のサポートをお勧めします。
The UNAUTHENTICATE command returns the server to the non-authenticated state. It doesn't affect any previously established TLS [TLS] or SASL (Section 2.1) security layer.
Unauthenticateコマンドは、サーバーを認証されていない状態に戻します。以前に確立されたTLS [TLS]またはSASL（セクション2.1）セキュリティレイヤーには影響しません。
The UNAUTHENTICATE command is only valid in authenticated state. If issued in a wrong state, the server MUST reject it with a NO response.
Unauthenticateコマンドは、認証された状態でのみ有効です。間違った状態で発行された場合、サーバーは応答なしでそれを拒否する必要があります。
The UNAUTHENTICATE command has no parameters.
Unauthenticateコマンドにはパラメーターがありません。
When issued in the authenticated state, the UNAUTHENTICATE command MUST NOT fail (i.e., it must never return anything other than OK or BYE).
認証された状態で発行された場合、Unauthenticateコマンドは失敗してはなりません（つまり、OKまたはさようなら以外のものを返してはいけません）。
URI scheme name: sieve
URIスキーム名：ふるい
Status: permanent
ステータス：永続的
URI scheme syntax: Described using ABNF [ABNF]. Some ABNF productions not defined below are from [URI-GEN].
URIスキーム構文：ABNF [ABNF]を使用して説明します。以下に定義されていない一部のABNFプロダクションは[URI-Gen]からです。
sieveurl = sieveurl-server / sieveurl-list-scripts / sieveurl-script
sieveurl = sieveurl-server / sieveurl-list-scripts / sieveurl-script
sieveurl-server = "sieve://" authority
Sieveurl-Server = "Sieve：//" Authority
sieveurl-list-scripts = "sieve://" authority ["/"]
sieveurl-list-scripts = "Sieve：//" Authority ["/"]
sieveurl-script = "sieve://" authority "/" [owner "/"] scriptname
Sieveurl-Script = "Sieve：//" Authority "/" [所有者 "/"] ScriptName
authority = <defined in [URI-GEN]>
owner = *ochar
;; %-encoded version of [SASL] authorization
;; identity (script owner) or "userid".
;;
;; Empty owner is used to reference
;; global scripts.
;;
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" must be %-encoded
;; as per rule specified in [URI-GEN].
scriptname = 1*ochar
;; %-encoded version of UTF-8 representation
;; of the script name.
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" must be %-encoded
;; as per rule specified in [URI-GEN].
ochar = unreserved / pct-encoded / sub-delims-sh /
":" / "@"
;; Same as [URI-GEN] 'pchar',
;; but without ";", "&" and "=".
unreserved = <defined in [URI-GEN]>
pct-encoded = <defined in [URI-GEN]>
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
"*" / "+" / ","
;; Same as [URI-GEN] sub-delims,
;; but without ";", "&" and "=".
URI scheme semantics:
URIスキームセマンティクス：
A Sieve URL identifies a Sieve server or a Sieve script on a Sieve server. The latter form is associated with the application/sieve MIME type defined in [SIEVE]. There is no MIME type associated with the former form of Sieve URI.
シーブURLは、ふるいサーバーまたはシーブサーバー上のシーブスクリプトを識別します。後者の形式は、[ふるい]で定義されたアプリケーション/ふるいマイムタイプに関連付けられています。Sieve Uriの以前の形に関連するMimeタイプはありません。
The server form is used in the REFERRAL response code (see Section 1.3) in order to designate another server where the client should perform its operations.
サーバーフォームは、クライアントが操作を実行する必要がある別のサーバーを指定するために、紹介応答コード（セクション1.3を参照）で使用されます。
The script form allows to retrieve (GETSCRIPT), update (PUTSCRIPT), delete (DELETESCRIPT), or activate (SETACTIVE) the named script; however, the most typical action would be to retrieve the script. If the script name is empty (omitted), the URI requests that the client lists available scripts using the LISTSCRIPTS command.
スクリプト形式では、名前付きスクリプトを取得（getScript）、update（putscript）、削除（削除）、またはアクティブ化（setactive）を取得できます。ただし、最も典型的なアクションは、スクリプトを取得することです。スクリプト名が空の場合（省略）、URIはクライアントがListScriptsコマンドを使用して利用可能なスクリプトをリストすることを要求します。
Encoding considerations:
考慮事項のエンコード：
The script name and/or the owner, if present, is in UTF-8. Non-- US-ASCII UTF-8 octets MUST be percent-encoded as described in [URI-GEN]. US-ASCII characters such as " " (space), ";", "&", "=", "/" and "?" MUST be %-encoded as described in [URI-GEN]. Note that "&" and "?" are in this list in order to allow for future extensions.
スクリプト名および/または所有者は、存在する場合、UTF-8にあります。非us-ascii utf-8オクテットは、[uri-gen]で説明されているようにパーセントエンコードされている必要があります。"" "（space）、"、 "、"＆ "、" = "、"/"、"？ "などのus-ascii文字[uri-gen]で説明されているように、％エンコードでなければなりません。「＆」と「？」に注意してください将来の拡張を可能にするために、このリストにあります。
Note that the empty owner (e.g., sieve://example.com//script) is different from the missing owner (e.g., sieve://example.com/script) and is reserved for referencing global scripts.
空の所有者（Sive：//example.com//scriptなど）は、行方不明の所有者（Sive：//example.com/scriptなど）とは異なり、グローバルスクリプトを参照するために予約されていることに注意してください。
The user name (in the "authority" part), if present, is in UTF-8. Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in [URI-GEN].
ユーザー名（「権限」部分）は、存在する場合、UTF-8にあります。非us-ascii utf-8オクテットは、[uri-gen]で説明されているようにパーセントエンコードされている必要があります。
Applications/protocols that use this URI scheme name: ManageSieve [RFC5804] clients and servers. Clients that can store user preferences in protocols such as [LDAP] or [ACAP].
このURIスキームを使用するアプリケーション/プロトコル名：ManageSieve [RFC5804]クライアントとサーバー。[LDAP]や[ACAP]などのプロトコルにユーザー設定を保存できるクライアント。
Interoperability considerations: None.
相互運用性の考慮事項：なし。
Security considerations: The <scriptname> part of a ManageSieve URL might potentially disclose some confidential information about the author of the script or, depending on a ManageSieve implementation, about configuration of the mail system. The latter might be used to prepare for a more complex attack on the mail system.
セキュリティ上の考慮事項：ManageSieve URLの<ScriptName>の一部は、スクリプトの著者に関する機密情報を開示する可能性があります。後者は、メールシステムに対するより複雑な攻撃の準備に使用される場合があります。
Clients resolving ManageSieve URLs that wish to achieve data confidentiality and/or integrity SHOULD use the STARTTLS command (if supported by the server) before starting authentication, or use a SASL mechanism, such as GSSAPI, that provides a confidentiality security layer.
データの機密性および/または整合性を達成したいManageSieve URLを解決するクライアントは、認証を開始する前にStartTLSコマンド（サーバーでサポートされている場合）を使用するか、GSSAPIなどのSASLメカニズムを使用して、機密保持セキュリティレイヤーを提供する必要があります。
Contact: Alexey Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG.
著者/変更コントローラー：IESG。
References: This document and RFC 5228 [SIEVE].
参考文献：このドキュメントとRFC 5228 [ふるい]。
The following syntax specification uses the Augmented Backus-Naur Form (BNF) notation as specified in [ABNF]. This uses the ABNF core rules as specified in Appendix A of the ABNF specification [ABNF]. "UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [UTF-8].
次の構文仕様では、[ABNF]で指定されているように、拡張されたBackus-Naurフォーム（BNF）表記を使用します。これは、ABNF仕様[ABNF]の付録Aで指定されているABNFコアルールを使用します。「UTF8-2」、「UTF8-3」、および「UTF8-4」非末端は[UTF-8]で定義されています。
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. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために上位または小文字の文字を使用することは、編集の明確さのみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
%x5D-7F
;; any TEXT-CHAR except QUOTED-SPECIALS
QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTEDスペシャル
QUOTED-SPECIALS = DQUOTE / "\"
QUOTEDスペシャル= dquote / "\"
SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 ;; <UTF8-2>, <UTF8-3>, and <UTF8-4> ;; are defined in [UTF-8].
SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 ;;<utf8-2>、<utf8-3>、および<utf8-4> ;;[UTF-8]で定義されています。
ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
;; Any CHAR except ATOM-SPECIALS
ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
NZDIGIT = %x31-39
;; 1-9
atom = 1*1024ATOM-CHAR
iana-token = atom ;; MUST be registered with IANA
iana-token = atom ;;IANAに登録する必要があります
auth-type = DQUOTE auth-type-name DQUOTE
auth-type-name = iana-token ;; as defined in SASL [SASL]
auth-type-name = iana-token ;;SASL [SASL]で定義されているように
command = (command-any / command-auth /
command-nonauth) CRLF
;; Modal based on state
command-any = command-capability / command-logout /
command-noop
;; Valid in all states
command-auth = command-getscript / command-setactive /
command-listscripts / command-deletescript /
command-putscript / command-checkscript /
command-havespace /
command-renamescript /
command-unauthenticate
;; Valid only in Authenticated state
command-nonauth = command-authenticate / command-starttls
;; Valid only when in Non-Authenticated
;; state
command-authenticate = "AUTHENTICATE" SP auth-type [SP string] *(CRLF string)
command-authenticate = "Authenticate" sp auth-type [sp string] *（crlf string）
command-capability = "CAPABILITY"
command-deletescript = "DELETESCRIPT" SP sieve-name
command-deletescript = "deletescript" sp sieve-name
command-getscript = "GETSCRIPT" SP sieve-name
command-getScript = "getScript" sp sieve-name
command-havespace = "HAVESPACE" SP sieve-name SP number
command-havespace = "Havespace" SP SIVE-NAME SP番号
command-listscripts = "LISTSCRIPTS"
command-noop = "NOOP" [SP string] command-logout = "LOGOUT"
command-noop = "noop" [sp string] command-logout = "logout"
command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
command-putscript = "putscript" sp sive-name sp sieve-script
command-checkscript = "CHECKSCRIPT" SP sieve-script
command-checkscript = "checkscript" sp sieve-script
sieve-script = string
command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP new-sieve-name
command-renamescript = "renamescript" sp old-sieve-name sp new-sieve-name
old-sieve-name = sieve-name
new-sieve-name = sieve-name
command-setactive = "SETACTIVE" SP active-sieve-name
command-setactive = "setactive" sp active-sieve-name
command-starttls = "STARTTLS"
command-unauthenticate= "UNAUTHENTICATE"
command-unauthenticated = "unauthenticated"
extend-token = atom
;; MUST be defined by a Standards Track or
;; IESG-approved experimental protocol
;; extension
extension-data = extension-item *(SP extension-item)
extension-data = extension-item *（SP拡張項目）
extension-item = extend-token / string / number /
"(" [extension-data] ")"
literal-c2s = "{" number "+}" CRLF *OCTET
;; The number represents the number of
;; octets.
;; This type of literal can only be sent
;; from the client to the server.
literal-s2c = "{" number "}" CRLF *OCTET
;; Almost identical to literal-c2s,
;; but with no '+' character.
;; The number represents the number of
;; octets.
;; This type of literal can only be sent
;; from the server to the client.
number = (NZDIGIT *DIGIT) / "0"
;; A 32-bit unsigned number
;; with no extra leading zeros.
;; (0 <= n < 4,294,967,296)
number-str = string ;; <number> encoded as a <string>.
number-str = string ;;<number> a <string>としてエンコードされています。
quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
;; limited to 1024 octets between the <">s
resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
["/" ("MAXSCRIPTS" / "MAXSIZE")] /
resp-code-sasl /
resp-code-referral /
"TRANSITION-NEEDED" / "TRYLATER" /
"ACTIVE" / "NONEXISTENT" /
"ALREADYEXISTS" / "WARNINGS" /
"TAG" SP string /
resp-code-ext
resp-code-referral = "REFERRAL" SP sieveurl
resp-code-referral = "referral" sp sieveurl
resp-code-sasl = "SASL" SP string
resp-code-sasl = "sasl" sp string
resp-code-name = iana-token
;; The response code name is hierarchical,
;; separated by '/'.
;; The response code name MUST NOT start
;; with '/'.
resp-code-ext = resp-code-name [SP extension-data] ;; unknown response codes MUST be tolerated ;; by the client.
resp-code-ext = resp-code-name [sp extension-data] ;;不明な応答コードは許容する必要があります;;クライアントによって。
response = response-authenticate / response-logout / response-getscript / response-setactive / response-listscripts / response-deletescript / response-putscript / response-checkscript / response-capability / response-havespace / response-starttls / response-renamescript / response-noop / response-unauthenticate
Response = Response-Authenticate / Response-Logout / Response-GetScript / Response-Setactive / Response-Listscripts / Response-Deletescript / Response-Putscript / Response-Checkscript / Response-Capability / Response-Havespace / Response-Starttls / Response-Renamescript /Response-noop / response-unauthenticate
response-authenticate = *(string CRLF)
((response-ok [response-capability]) /
response-nobye)
;; <response-capability> is REQUIRED if a
;; SASL security layer was negotiated and
;; MUST be omitted otherwise.
response-capability = *(single-capability) response-oknobye
single-capability = capability-name [SP string] CRLF
単一キャピール= capability-name [sp string] crlf
capability-name = string
;; Note that literal-s2c is allowed.
;;文字通りS2Cが許可されていることに注意してください。
initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
DQUOTE "SASL" DQUOTE SP sasl-mechs /
DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
DQUOTE "STARTTLS" DQUOTE /
DQUOTE "LANGUAGE" DQUOTE SP language /
DQUOTE "VERSION" DQUOTE SP version /
DQUOTE "OWNER" DQUOTE SP string
;; Each capability conforms to
;; the syntax for single-capability.
;; Also, note that the capability name
;; can be returned as either literal-s2c
;; or quoted, even though only "quoted"
;; string is shown above.
version = ( DQUOTE "1.0" DQUOTE ) / version-ext
version-ext = DQUOTE ver-major "." ver-minor DQUOTE
; Future versions specified in updates
; to this document. An increment to
; the ver-major means a backward-incompatible
; change to the protocol, e.g., "3.5" (ver-major "3")
; is not backward-compatible with any "2.X" version.
; Any version "Z.W" MUST be backward compatible
; with any version "Z.Q", where Q < W.
; For example, version "2.4" is backward compatible
; with version "2.0", "2.1", "2.2", and "2.3".
ver-major = number ver-minor = number
ver-major = number ver-minor = number
sasl-mechs = string
; Space-separated list of SASL mechanisms,
; each SASL mechanism name complies with rules
; specified in [SASL].
; Can be empty.
sieve-extensions = string ; Space-separated list of supported SIEVE extensions. ; Can be empty.
Sieve-Extensions = string;サポートされているふるい拡張のスペース分離リスト。;空にすることができます。
language = string ; Contains <Language-Tag> from [RFC5646].
言語=文字列;[RFC5646]から<言語タグ>が含まれています。
notify-mechs = string
; Space-separated list of URI schema parts
; for supported notification [NOTIFY] methods.
; MUST NOT be empty.
response-deletescript = response-oknobye
response-getscript = (sieve-script CRLF response-ok) /
response-nobye
response-havespace = response-oknobye
response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
response-oknobye
;; ACTIVE may only occur with one sieve-name
response-logout = response-oknobye
response-unauthenticate= response-oknobye
;; "NO" response can only be returned when
;; the command is issued in a wrong state
;; or has a wrong number of parameters
response-ok = "OK" [SP "(" resp-code ")"] [SP string] CRLF ;; The string contains human-readable text ;; encoded as UTF-8.
response-ok = "ok" [sp "（" resp-code "）"] [sp string] crlf ;;文字列には、人間の読み取り可能なテキストが含まれています;;UTF-8としてエンコード。
response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
[SP string] CRLF
;; The string contains human-readable text
;; encoded as UTF-8.
response-oknobye = response-ok / response-nobye
response-noop = response-ok
response-putscript = response-oknobye
response-checkscript = response-oknobye
response-renamescript = response-oknobye
response-setactive = response-oknobye
response-starttls = (response-ok response-capability) /
response-nobye
sieve-name = string
;; See Section 1.6 for the full list of
;; prohibited characters.
;; Empty string is not allowed.
active-sieve-name = string
;; See Section 1.6 for the full list of
;; prohibited characters.
;; This is similar to <sieve-name>, but
;; empty string is allowed and has a special
;; meaning.
string = quoted / literal-c2s / literal-s2c
;; literal-c2s is only allowed when sent
;; from the client to the server.
;; literal-s2c is only allowed when sent
;; from the server to the client.
;; quoted is allowed in either direction.
The AUTHENTICATE command uses SASL [SASL] to provide authentication and authorization services. Integrity and privacy services can be provided by [SASL] and/or [TLS]. When a SASL mechanism is used, the security considerations for that mechanism apply.
Authenticateコマンドは、SASL [SASL]を使用して、認証と承認サービスを提供します。整合性およびプライバシーサービスは、[SASL]および/または[TLS]によって提供できます。SASLメカニズムを使用すると、そのメカニズムのセキュリティに関する考慮事項が適用されます。
This protocol's transactions are susceptible to passive observers or man-in-the-middle attacks that alter the data, unless the optional encryption and integrity services of the SASL (via the AUTHENTICATE command) and/or [TLS] (via the STARTTLS command) are enabled, or an external security mechanism is used for protection. It may be useful to allow configuration of both clients and servers to refuse to transfer sensitive information in the absence of strong encryption.
このプロトコルのトランザクションは、SASLのオプションの暗号化と整合性サービス（認証コマンドを介して）および/または[TLS]（StartTLSコマンドを介して）を除き、データを変更するパッシブオブザーバーまたは中間攻撃の影響を受けやすいです有効になっているか、外部セキュリティメカニズムが保護に使用されます。クライアントとサーバーの両方の構成が、強力な暗号化がない場合に機密情報の転送を拒否できるようにすることが役立つ場合があります。
If an implementation supports SASL mechanisms that are vulnerable to passive eavesdropping attacks (such as [PLAIN]), then the implementation MUST support at least one configuration where these SASL mechanisms are not advertised or used without the presence of an external security layer such as [TLS].
実装が受動的な盗聴攻撃（[Plain]など）に対して脆弱なSASLメカニズムをサポートする場合、実装は、これらのSASLメカニズムが外部セキュリティレイヤーの存在なしに宣伝または使用されない少なくとも1つの構成をサポートする必要があります。TLS]。
Some response codes returned on failed AUTHENTICATE command may disclose whether or not the username is valid (e.g., TRANSITION-NEEDED), so server implementations SHOULD provide the ability to disable these features (or make them not conditional on a per-user basis) for sites concerned about such disclosure. In the case of ENCRYPT-NEEDED, if it is applied to all identities then no extra information is disclosed, but if it is applied on a per-user basis it can disclose information.
故障した認証コマンドで返された一部の応答コードは、ユーザー名が有効であるかどうか（トランジションが必要な場合）かどうかを開示する可能性があるため、サーバーの実装はこれらの機能を無効にする機能を提供する必要があります（または、ユーザーごとに条件付きではないようにします）そのような開示を懸念するサイト。暗号化の場合、すべてのアイデンティティに適用される場合、追加の情報は開示されませんが、ユーザーごとに適用されると情報を開示できます。
A compromised or malicious server can use the TRANSITION-NEEDED response code to force the client that is configured to use a mechanism that does not disclose the user's password to the server (e.g., Kerberos), to send the bare password to the server. Clients SHOULD have the ability to disable the password transition feature, or disclose that risk to the user and offer the user an option of how to proceed.
侵害されたサーバーまたは悪意のあるサーバーは、トランジションが必要な応答コードを使用して、ユーザーのパスワードをサーバーに開示していないメカニズム（Kerberosなど）を使用するように構成されているクライアントを強制的に使用して、ベアパスワードをサーバーに送信することができます。クライアントは、パスワードトランジション機能を無効にする機能を持つか、ユーザーにそのリスクを開示し、ユーザーに進行方法のオプションを提供することができます。
IANA has reserved TCP port number 4190 for use with the ManageSieve protocol described in this document.
IANAは、このドキュメントで説明されているManagESIEVEプロトコルで使用するためにTCPポート番号4190を予約しています。
IANA has registered the "sieve" URI scheme defined in Section 3 of this document.
IANAは、このドキュメントのセクション3で定義されている「ふるい」URIスキームを登録しました。
IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service Names" registry.
IANAは、「GSSAPI/Kerberos/SASLサービス名」レジストリに「ふるい」を登録しています。
IANA has created a new registry for ManageSieve capabilities. The registration template for ManageSieve capabilities is specified in Section 6.1. ManageSieve protocol capabilities MUST be specified in a Standards-Track or IESG-approved Experimental RFC.
IANAは、ManagESIEVE機能のための新しいレジストリを作成しました。ManagESIEVE機能の登録テンプレートは、セクション6.1で指定されています。ManagESIEVEプロトコル機能は、標準トラックまたはIESGが承認した実験RFCで指定する必要があります。
IANA has created a new registry for ManageSieve response codes. The registration template for ManageSieve response codes is specified in Section 6.3. ManageSieve protocol response codes MUST be specified in a Standards-Track or IESG-approved Experimental RFC.
IANAは、ManagESIEVE Responseコードの新しいレジストリを作成しました。ManagESIEVE応答コードの登録テンプレートは、セクション6.3で指定されています。ManagESIEVEプロトコル応答コードは、標準トラックまたはIESGが承認した実験RFCで指定する必要があります。
To: iana@iana.org Subject: ManageSieve Capability Registration
宛先：iana@iana.org件名：ManageSieve Capability登録
Please register the following ManageSieve capability:
次のManageSieve機能を登録してください。
Capability name: Description: Relevant publications: Person & email address to contact for further information: Author/Change controller:
能力名：説明：関連する出版物：連絡先への個人と電子メールアドレス詳細情報：著者/変更コントローラー：
To: iana@iana.org Subject: ManageSieve Capability Registration
宛先：iana@iana.org件名：ManageSieve Capability登録
Please register the following ManageSieve capabilities:
次のManageSieve機能を登録してください。
Capability name: IMPLEMENTATION Description: Its value contains the name of the server implementation and its version. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
機能名：実装説明：その値には、サーバーの実装とそのバージョンの名前が含まれています。関連する出版物：このRFC、セクション1.7。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: SASL Description: Its value contains a space-separated list of SASL mechanisms supported by the server. Relevant publications: this RFC, Sections 1.7 and 2.1. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
機能名：SASL説明：その値には、サーバーがサポートするSASLメカニズムのスペース分離リストが含まれています。関連する出版物：このRFC、セクション1.7および2.1。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: SIEVE Description: Its value contains a space-separated list of supported SIEVE extensions. Relevant publications: this RFC, Section 1.7. Also [SIEVE]. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
能力名：ふるいの説明：その値には、サポートされているふるい拡張のスペース分離リストが含まれています。関連する出版物：このRFC、セクション1.7。また[ふるい]。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: STARTTLS Description: This capability is returned if the server supports TLS (STARTTLS command). Relevant publications: this RFC, Sections 1.7 and 2.2. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
機能名：StartTLS説明：サーバーがTLS（startTLSコマンド）をサポートすると、この機能が返されます。関連する出版物：このRFC、セクション1.7および2.2。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: NOTIFY Description: This capability is returned if the server supports the 'enotify' [NOTIFY] Sieve extension. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
機能名：通知説明：サーバーが「Enotify」[Notify] Sieve Extensionをサポートしている場合、この機能は返されます。関連する出版物：このRFC、セクション1.7。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: MAXREDIRECTS Description: This capability returns the limit on the number of Sieve "redirect" actions a script can perform during a single evaluation. The value is a non-negative number represented as a ManageSieve string. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
機能名：MaxRedirects説明：この機能は、単一の評価中にスクリプトが実行できる「リダイレクト」アクションの数の制限を返します。値は、manageSieve文字列として表される非陰性の数字です。関連する出版物：このRFC、セクション1.7。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: LANGUAGE Description: The language (<Language-Tag> from [RFC5646]) currently used for human-readable error messages. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
能力名：言語説明：人間が読み取れるエラーメッセージに現在使用されている言語（<言語タグ> [RFC5646]）。関連する出版物：このRFC、セクション1.7。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: OWNER Description: Its value contains the UTF-8-encoded name of the currently logged-in user ("authorization identity" according to RFC 4422). Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
能力名：所有者の説明：その値には、現在ログインしているユーザー（RFC 4422に従って「承認ID」）のUTF-8エンコードされた名前が含まれています。関連する出版物：このRFC、セクション1.7。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
Capability name: VERSION Description: This capability is returned if the server is compliant with RFC 5804; i.e., that it supports RENAMESCRIPT, CHECKSCRIPT, and NOOP commands. Relevant publications: this RFC, Sections 2.11, 2.12, and 2.13. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
機能名：バージョンの説明：サーバーがRFC 5804に準拠している場合、この機能は返されます。つまり、renamescript、checkscript、およびnoopコマンドをサポートしています。関連する出版物：このRFC、セクション2.11、2.12、および2.13。詳細については、個人とメールアドレスをお問い合わせください：Alexey Melnikov <alexey.melnikov@isode.com>著者/Change Controller：iesg。
To: iana@iana.org Subject: ManageSieve Response Code Registration
宛先：iana@iana.org件名：ManageSieve Response Code登録
Please register the following ManageSieve response code:
次のManagESIEVE応答コードを登録してください。
Response Code: Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): Purpose: Published Specification(s): Person & email address to contact for further information: Author/Change controller:
応答コード：引数（ABNFを使用して構文を指定します。または、NONTが指定できない場合はなし）：目的：公開された仕様：人とメールアドレスへの連絡先詳細情報：著者/変更コントローラー：
To: iana@iana.org Subject: ManageSieve Response Code Registration
宛先：iana@iana.org件名：ManageSieve Response Code登録
Please register the following ManageSieve response codes:
次のManagESIEVE応答コードを登録してください。
Response Code: AUTH-TOO-WEAK Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code is returned in the NO response from an AUTHENTICATE command. It indicates that site security policy forbids the use of the requested mechanism for the specified authentication identity. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：Auth-Too-Weak引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなし）：なし目的：この応答コードは、認証コマンドからNO応答で返されます。これは、サイトのセキュリティポリシーが、指定された認証IDのために要求されたメカニズムの使用を禁止することを示しています。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: ENCRYPT-NEEDED Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code is returned in the NO response from an AUTHENTICATE command. It indicates that site security policy requires the use of a strong encryption mechanism for the specified authentication identity and mechanism. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：暗号化されている引数（ABNFを使用して構文を指定する、または単語を指定できない場合はなし）：なし目的：この応答コードは、認証コマンドからNO応答で返されます。サイトのセキュリティポリシーには、指定された認証アイデンティティとメカニズムに強力な暗号化メカニズムの使用が必要であることが示されています。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: QUOTA Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined quota constraints. If this response code is returned in the OK response, it can mean that the user is near its quota or that the user exceeded its quota, but the server supports soft quotas. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：quota引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなし）：なし目的：この応答コードがNO/BYE応答で返される場合、コマンドがユーザーを上に配置したことを意味します。サイト定義のクォータの制約。この応答コードがOK応答で返された場合、ユーザーがクォータに近いか、ユーザーがクォータを超えていることを意味しますが、サーバーはソフトクォータをサポートしています。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: QUOTA/MAXSCRIPTS Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined limit on the number of Sieve scripts. If this response code is returned in the OK response, it can mean that the user is near its quota or that the user exceeded its quota, but the server supports soft quotas. This response code is a more specific version of the QUOTA response code. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：quota/maxscripts引数（ABNFを使用して構文を指定するか、NONTを指定できない場合はなし）：なし目的：この応答コードがNO/BYE応答で返される場合、コマンドが配置されたことを意味します。Sieveスクリプトの数のサイト定義制限を超えるユーザー。この応答コードがOK応答で返された場合、ユーザーがクォータに近いか、ユーザーがクォータを超えていることを意味しますが、サーバーはソフトクォータをサポートしています。この応答コードは、クォータ応答コードのより具体的なバージョンです。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: QUOTA/MAXSIZE Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined maximum script size. If this response code is returned in the OK response, it can mean that the user is near its quota or that the user exceeded its quota, but the server supports soft quotas. This response code is a more specific version of the QUOTA response code. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：Quota/Maxsize引数（ABNFを使用して構文を指定するか、NONEが指定できない場合はなしを指定します）：なし目的：この応答コードがNO/BYE応答で返される場合、コマンドが配置されたことを意味します。サイト定義の最大スクリプトサイズの上のユーザー。この応答コードがOK応答で返された場合、ユーザーがクォータに近いか、ユーザーがクォータを超えていることを意味しますが、サーバーはソフトクォータをサポートしています。この応答コードは、クォータ応答コードのより具体的なバージョンです。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: REFERRAL Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): <sieveurl> Purpose: This response code may be returned with a BYE result from any command, and includes a mandatory parameter that indicates what server to access to manage this user's Sieve scripts. The server will be specified by a Sieve URL (see Section 3). The scriptname portion of the URL MUST NOT be specified. The client should authenticate to the specified server and use it for all further commands in the current session. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：紹介引数（ABNFを使用して構文を指定するか、NONEが指定できない場合はなしを指定します）：<Sieveurl>目的：この応答コードは、任意のコマンドからのBYE結果で返される場合があり、何を示す必須パラメーターを含むことができますこのユーザーのふるいスクリプトを管理するためのサーバー。サーバーは、ふるいURLによって指定されます（セクション3を参照）。URLのスクリプト名部分を指定してはなりません。クライアントは、指定されたサーバーに認証し、現在のセッションでさらにすべてのコマンドに使用する必要があります。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: SASL Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): <string> Purpose: This response code can occur in the OK response to a successful AUTHENTICATE command and includes the optional final server response data from the server as specified by [SASL]. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：SASL引数（ABNFを使用して構文を指定するか、NONEが指定できない場合はなし）：<String>目的：この応答コードは、成功した認証コマンドに対するOK応答で発生し、オプションの最終サーバー応答データを含めることができます[SASL]で指定されているサーバーから。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: TRANSITION-NEEDED Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code occurs in a NO response of an AUTHENTICATE command. It indicates that the user name is valid, but the entry in the authentication database needs to be updated in order to permit authentication with the specified mechanism. This is typically done by establishing a secure channel using TLS, followed by authenticating once using the [PLAIN] authentication mechanism. The selected mechanism SHOULD then work for authentications in subsequent sessions. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：トランジションが必要な引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなし）：なし目的：この応答コードは、認証コマンドのNO応答で発生します。これは、ユーザー名が有効であることを示していますが、指定されたメカニズムで認証を許可するために、認証データベースのエントリを更新する必要があります。これは通常、TLSを使用して安全なチャネルを確立し、[プレーン]認証メカニズムを使用して認証することによって行われます。選択したメカニズムは、後続のセッションで認証のために機能する必要があります。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: TRYLATER Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed due to a temporary server failure. The client MAY continue using local information and try the command later. This response code only make sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：TryLater引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなしを指定します）：なし目的：一時的なサーバー障害のためにコマンドが失敗しました。クライアントは、ローカル情報を引き続き使用し、後でコマンドを試すことができます。この応答コードは、NO/BYE応答で返された場合にのみ意味があります。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: ACTIVE Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed because it is not allowed on the active script, for example, DELETESCRIPT on the active script. This response code only makes sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：アクティブな引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなしを指定します）：なし目的：アクティブスクリプトで許可されていないため、コマンドが失敗しました。たとえば、アクティブスクリプトで削除します。この応答コードは、NO/BYE応答で返された場合にのみ理にかなっています。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: NONEXISTENT Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed because the referenced script name doesn't exist. This response code only makes sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：存在しない引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はありません）：なし目的：参照されるスクリプト名が存在しないためにコマンドが失敗しました。この応答コードは、NO/BYE応答で返された場合にのみ理にかなっています。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: ALREADYEXISTS Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed because the referenced script name already exists. This response code only makes sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：既に既存の引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなし）：なし目的：参照されたスクリプト名が既に存在するためにコマンドが失敗しました。この応答コードは、NO/BYE応答で返された場合にのみ理にかなっています。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: WARNINGS Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code MAY be returned by the server in the OK response (but it might be returned with the NO/ BYE response as well) and signals the client that even though the script is syntactically valid, it might contain errors not intended by the script writer. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：警告引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなし）：なし目的：この応答コードは、OK応答でサーバーによって返される場合があります（ただし、NO/ BYEで返される場合があります応答）およびクライアントに、スクリプトが構文的に有効である場合でも、スクリプトライターが意図していないエラーが含まれている可能性があることをクライアントに通知します。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
Response Code: TAG Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): string Purpose: This response code name is followed by a string specified in the command that caused this response. It is typically used for client state synchronization. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
応答コード：タグ引数（ABNFを使用して構文を指定するか、NONTが指定できない場合はなし）：文字列目的：この応答コード名の後に、この応答を引き起こしたコマンドで指定された文字列が続きます。通常、クライアント状態の同期に使用されます。公開された仕様：[RFC5804]詳細については、連絡先への個人およびメールアドレス：Alexey Melnikov <alexey.melnikov@isode.com>著者/変更コントローラー：IESG。
The LANGUAGE capability (see Section 1.7) allows a client to discover the current language used in all human-readable responses that might be returned at the end of any OK/NO/BYE response. Human-readable text in OK responses typically doesn't need to be shown to the user, unless it is returned in response to a PUTSCRIPT or CHECKSCRIPT command that also contains the WARNINGS response code (Section 1.3). Human-readable text from NO/BYE responses is intended be shown to the user, unless the client can automatically handle failure of the command that caused such a response. Clients SHOULD use response codes (Section 1.3) for automatic error handling. Response codes MAY also be used by the client to present error messages in a language understood by the user, for example, if the LANGUAGE capability doesn't return a language understood by the user.
言語能力（セクション1.7を参照）を使用すると、クライアントは、OK/NO/BYE応答の最後に返される可能性のあるすべての人間読み取り可能な応答で使用されている現在の言語を発見できます。OK応答のヒューマン読み取り可能なテキストは、通常、警告応答コード（セクション1.3）を含むPutScriptまたはCheckscriptコマンドに応答して返されない限り、ユーザーに表示する必要はありません。クライアントがそのような応答を引き起こしたコマンドの障害を自動的に処理できない限り、NO/BYE応答からの人間の読み取り可能なテキストは、ユーザーに表示されます。クライアントは、自動エラー処理のために応答コード（セクション1.3）を使用する必要があります。応答コードは、クライアントがユーザーが理解している言語でエラーメッセージを提示するために使用することもできます。たとえば、言語機能がユーザーが理解した言語を返しない場合。
Note that the human-readable text from OK (WARNINGS) or NO/BYE responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced users that understand Sieve language. Such advanced users are often sophisticated enough to be able to handle whatever language the server is using, even if it is not their preferred language, and will want to see error/warning text no matter what language the server puts it in.
PutScript/CheckscriptコマンドのOK（警告）またはNO/BYE応答からの人間の読み取り可能なテキストは、ふるい言語を理解する上級ユーザーを対象としていることに注意してください。このような高度なユーザーは、たとえそれが好ましい言語でなくても、サーバーが使用しているあらゆる言語を処理できるほど洗練されていることが多く、サーバーがどの言語を入れてもエラー/警告テキストを表示したいと思うでしょう。
A client that generates Sieve script automatically, for example, if the script is generated without user intervention or from a UI that presents an abstract list of conditions and corresponding actions, SHOULD NOT present warning/error messages to the user, because the user might not even be aware that the client is using Sieve underneath. However, if the client has a debugging mode, such warnings/errors SHOULD be available in the debugging mode.
たとえば、ユーザーの介入なしでスクリプトが生成された場合、または条件と対応するアクションの抽象リストを提示するUIからスクリプトが生成された場合、ユーザーがユーザーに警告/エラーメッセージを提示しないでください。クライアントが下にふるいを使用していることに注意してください。ただし、クライアントにデバッグモードがある場合、そのような警告/エラーがデバッグモードで利用できるようにする必要があります。
Note that this document doesn't provide a way to modify the currently used language. It is expected that a future extension will address that.
このドキュメントは、現在使用されている言語を変更する方法を提供していないことに注意してください。将来の拡張がそれに対処することが期待されています。
Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus Westerlund, Tim Polk, and Julien Coloos for help with this document. Special thank you to Phil Pennock for providing text for the NOOP command, as well as finding various bugs in the document.
サイモン・ジョセフソン、ラリー・グリーンフィールド、アレン・ジョンソン、クリス・ニューマン、リンドン・ネレンバーグ、ティム・ショールーター、サラ・ロベソン、ウォルター・ウォン、バリー・レイバ、アルント・ガルブランドセン、ステファン・ボッシュ、ケン・マーチソン、フィル・ペノック、ネッド・フリードマレット、ダイヤン・パラウゾフ、デイブ・クライドランド、アーロン・ストーン、ロバート・バレル・ドンキン、パトリック・ベン・ケッター、Bジョーン・ホーマン、マーティン・デュエルスト、パシ・エロネン、マグナス・ウェスターランド、ティム・ポーク、ジュリアン・コロウがこの文書を支援しています。NOOPコマンドにテキストを提供してくれたPhil Pennockに特別に感謝し、ドキュメント内のさまざまなバグを見つけてくれてありがとう。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[Base64] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、2006年10月。
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNS-SRV] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[Net-Unicode] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
[Notify] Melnikov、A.、Leiba、B.、Segmuller、W。、およびT. Martin、「Sieve Emailフィルタリング：通知の拡張」、RFC 5435、2009年1月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A。、「Lightweight Directory Access Protocol（LDAP）：ユーザーアプリケーションのスキーマ」、RFC 4519、2006年6月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[Saslprep] Zeilenga、K。、「Saslprep：ユーザー名とパスワードのStringPrepプロファイル」、RFC 4013、2005年2月。
[SCRAM] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[SCRAM] Menon-Sen、A.、Melnikov、A.、Newman、C。、およびN. Williams、「Salted Challenge Response認証メカニズム（SCRAM）SASLおよびGSS-APIメカニズム」、RFC 5802、2010年7月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[Sieve] Guenther、P。and T. Showalter、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[StringPrep] Hoffman、P。and M. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[Uri-Gen] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[X509] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、「Internet X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[X509-SRV] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[X509-SRV] Santesson、S。、「インターネットX.509公開キーインフラストラクチャの主題サービス名の代替名」、RFC 4985、2007年8月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[Digest-MD5] Leach、P。and C. Newman、「SASLメカニズムとして消化認証を使用」、RFC 2831、2000年5月。
[GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[GSSAPI] Melnikov、A。、「Kerberos V5（ "GSSAPI"）シンプルな認証とセキュリティ層（SASL）メカニズム」、RFC 4752、2006年11月。
[I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", RFC 5463, March 2009.
[i-have] Freed、N。、「Sieve Emailフィルタリング：Ihave Extension」、RFC 5463、2009年3月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[LDAP] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[LDAP] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[Plain] Zeilenga、K。、「プレーンシンプルな認証およびセキュリティレイヤー（SASL）メカニズム」、RFC 4616、2006年8月。
Authors' Addresses
著者のアドレス
Alexey Melnikov (editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov（編集者）Isode Limited 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Tim Martin BeThereBeSquare, Inc. 672 Haight st. San Francisco, CA 94117 USA
Tim Martin Betherebesquare、Inc。672 Haight St。カリフォルニア州サンフランシスコ94117 USA
Phone: +1 510 260-4175
EMail: timmartin@alumni.cmu.edu