Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6134 Isode Limited
Category: Standards Track B. Leiba
ISSN: 2070-1721 Huawei Technologies
July 2011
Sieve Extension: Externally Stored Lists
Abstract
抽象
The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.
ふるいのメールフィルタリング言語は、電子メールのホワイトリスト、ブラックリスト、個人用配布リスト、およびリストマッチングの他の種類を実装するために使用することができます。現在、このようなリストのすべてのメンバーがスクリプト自体にハードコーディングされたされている必要があります。リストのメンバーを追加または削除されるたびに、スクリプトが更新され、おそらくメールサーバーにアップロードする必要があります。
This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases.
この文書では、外部に保存されたリストにアクセスするためのふるいの拡張を定義する - などのWebDAVへのLDAP（Lightweight Directory Access Protocol）、アプリケーション設定アクセスプロトコル（ACAP）、vCardの拡張機能を使用するなど、そのメンバーがスクリプトに外部に保存されているリスト、（CardDAVの）、またはリレーショナルデータベース。
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/rfc6134.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6134で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Extlists Extension . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Capability Identifier . . . . . . . . . . . . . . . . . . 3
2.2. :list Match Type for Supported Tests . . . . . . . . . . . 3
2.3. :list Tagged Argument to the "redirect" Action . . . . . . 5
2.4. Other Uses for External Lists . . . . . . . . . . . . . . 5
2.5. Syntax of an Externally Stored List Name . . . . . . . . . 5
2.6. Definition of "addrbook" URN Parameter . . . . . . . . . . 7
2.7. Test valid_ext_list . . . . . . . . . . . . . . . . . . . 9
2.8. Interaction with ManageSieve . . . . . . . . . . . . . . . 9
2.9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 10
2.9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 10
2.9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 11
2.9.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 11
2.9.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. Registration of Sieve Extension . . . . . . . . . . . . . 14
4.2. Registration of ManageSieve Capability . . . . . . . . . . 14
4.3. Creation of Sieve URN Parameters Registry . . . . . . . . 15
4.4. Registration of the "addrbook" URN parameter . . . . . . . 16
4.5. Registration of "sieve" URN sub-namespace . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 17
This document specifies an extension to the Sieve language [RFC5228] for checking membership in an external list or for redirecting messages to an external list of recipients. An "external list" is a list whose members are stored externally to the Sieve script, such as using LDAP [RFC4510], ACAP [RFC2244], CardDAV [CardDAV], or relational databases.
この文書は、外部リストのメンバーシップを確認するためか、受信者の外部リストにメッセージをリダイレクトするためのふるい言語[RFC5228]に拡張子を指定します。 「外部リスト」とは、そのメンバーなLDAPを使用して、Sieveスクリプトを外部に保存されているリスト[RFC4510]、ACAP [RFC2244]、CardDAVの[CardDAVの]、またはリレーショナルデータベースです。
This extension adds a new match type to apply to supported tests and a new tagged argument to the "redirect" action.
この拡張は、サポートされているテストと「リダイレクト」アクションに新しいタグ付けされた引数に適用する新しいマッチタイプを追加します。
Conventions for notations are as in [RFC5228], Section 1.1, including the use of ABNF [RFC5234].
表記の規則は、[RFC5228]のようにABNF [RFC5234]の使用を含むセクション1.1です。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The capability string associated with the extension defined in this document is "extlists".
この文書で定義された拡張子に関連付けられた機能文字列は「extlists」です。
ABNF:
ABNF：
MATCH-TYPE =/ ":list"
; only valid for supported tests
The new ":list" match type changes the interpretation of the "key-list" parameter (the second parameter) in supported tests. When the match type is ":list", the key-list becomes a list of names of externally stored lists. The external lists are queried, perhaps through a list-specific mechanism, and the test evaluates to "true" if any of the specified values matches any member of one or more of the lists.
新しい「：リスト」マッチタイプは、サポートされているテストで、「キー・リスト」パラメータ（第2パラメータ）の解釈を変更します。マッチタイプがある場合は、「：リスト」、キー・リストが外部に保存されたリストの名前のリストになります。外部リストは、おそらくリスト固有のメカニズムを介して、照会、および指定された値のいずれかのリストのうちの1つまたは複数の任意のメンバーと一致した場合、テストは「真」と評価されます。
Comparators are not allowed together with the ":list" match type, so if both are specified in a test, that MUST result in an error. Queries done through list-specific mechanisms might have the effect of built-in comparators; for example, queries to certain lists might be case-sensitive, while queries to other lists might be done without regard to case.
両方がエラーをもたらさなければなりませんテストに指定されているので、もし、マッチタイプ：「リスト」コンパレータは、一緒に許可されていません。リスト固有のメカニズムを介して行わ問合せは、内蔵のコンパレータの影響を与える可能性があります。他のリストへのクエリが大文字小文字を区別せずに行なわれるかもしれないが、たとえば、特定のリストへのクエリは、大文字と小文字を区別している可能性があります。
Implementations MUST support the use of ":list" in "address", "envelope", and "header" tests. Implementations that include the Variables extension [RFC5229] MUST also support its use in "string" tests.
「住所」、「封筒」、および「ヘッダ」テスト中：「リスト」実装はの使用をサポートしなければなりません。変数の拡張[RFC5229]を含んまた、実装は「文字列」テストでの使用をサポートしなければなりません。
Implementations MAY support other tests than the ones in this document. Implementations MUST report an error when a script uses ":list" with a test that does not support ":list". This error SHOULD be reported at compile-time but MAY be reported at run-time. To maintain interoperability, other tests that can be used with ":list" SHOULD be documented in a specification that defines a capability string that can be tested (in a "require" statement or using "ihave" [RFC5463]).
実装は、この文書に記載されているもの以外のテストをサポートするかもしれません。 「：リスト」をサポートしていないテストで「：リストを」スクリプトを使用する場合、実装は、エラーを報告しなければなりません。このエラーはコンパイル時に報告されるべきではなく、実行時に報告されてもよいです。相互運用性を維持するために、一緒に使用することができ、他のテスト「：リストは、」（「必要」ステートメントまたは「IHAVE」[RFC5463]を使用して）テストすることができる機能文字列を定義する仕様に文書化する必要があります。
For example, testing 'header ["to", "cc"]' against a list would cause each "to" and "cc" value, ignoring leading and trailing whitespace, to be queried. If any value is found to belong to the list, the test returns "true". If no value belongs to the list, the test returns "false". Once a value is found in the list, there is no need for the query mechanism to look further.
例えば、試験「ヘッダ[ 『に』、 『CC』]」リストに対して照会すべき先頭と末尾の空白を無視して各「に」と「CC」の値を、引き起こします。任意の値がリストに属することが判明した場合、テストは「true」を返します。何も値がリストに属していない場合、テストは「偽」を返します。値がリストに見つかると、クエリメカニズムをさらに見てするための必要はありません。
For some lists, the Sieve engine might directly retrieve the list and make its own comparison. Other lists might not work that way -- they might provide a way to ask if a value is in the list, but not permit retrieval of the list itself. It is up to the Sieve implementation to understand how to interact with any supported list. If the Sieve engine is permanently unable to query the list (perhaps because the list doesn't support the required operation), the test MUST result in a runtime error in the Sieve script.
一部のリストについては、ふるいエンジンは、直接リストを取得し、独自の比較を行うことがあります。他のリストには、そのように動作しない可能性があります - 彼らは値がリストにあるかどうか尋ねるが、リスト自体の検索を許可しないための方法を提供するかもしれません。これは、サポートされている任意のリストと対話する方法を理解するためにふるいの実装に任されています。ふるいエンジンは（おそらくリストが必要な操作をサポートしていないので）リストを照会することが永久にできない場合、テストはSieveスクリプトで実行時エラーをもたらさなければなりません。
See Section 2.5 for the detailed description of syntax used for naming externally stored lists.
外部に保存リストに名前を付けるために使用する構文の詳細については、セクション2.5を参照してください。
The ":list" match type uses the concept of "match variables" as defined in Section 3.2 of the Variables extension [RFC5229]. Implementations that also support that extension MUST set the ${0} match variable to the value in the list that matched the query. Other numbered match variables (${1}, ${2}, and so on) MAY be set with list-specific information that might be of use to the script.
「：リスト」変数の拡張[RFC5229]のセクション3.2で定義されたマッチタイプが「一致変数」という概念を使用しています。また、その拡張機能をサポートする実装は、クエリと一致リスト内の値に$ {0}一致変数を設定する必要があります。他の番号の一致変数（$ {1}、$ {2}、など）は、スクリプトに有用であるかもしれないリスト固有情報が設定されるかもしれません。
Usage: redirect :list <ext-list-name: string>
使用法：リダイレクト：リスト<EXT-リスト名：文字列>
The "redirect" action with the ":list" argument is used to send the message to the set of email addresses in the externally stored list named by the ext-list-name string. This variant of the redirect command can be used to implement a personal distribution list.
「：リスト」と「リダイレクト」アクションの引数がext-リスト名の文字列で指定された外部記憶されたリスト内の電子メールアドレスのセットにメッセージを送信するために使用されます。リダイレクトコマンドのこの変形は、個人用配布リストを実装するために使用することができます。
For this feature to work, one of the following conditions has to be true:
この機能が動作するには、次のいずれかの条件が真であることがあります。
1. The list resolves to a list of email addresses, and the Sieve engine is able to enumerate those addresses.
1.リストは、電子メールアドレスのリストに解決し、ふるいエンジンは、これらのアドレスを列挙することができます。
2. The list handler is able to take care of the redirection on behalf of the Sieve engine.
2.リスト・ハンドラーは、ふるいエンジンの代わりに、リダイレクトの世話をすることができます。
In cases where, for example, a list contains hashed email address values or an email address pattern ("sz*@example.com", "*+ietf@example.net"), the Sieve engine will not be able to redirect to that list, and responsibility must pass to the list handler.
例えば、リストは、ハッシュ化された電子メールアドレス値または電子メールアドレスパターン（「sz*@example.com」、「*+ietf@example.net」）を含む場合には、ふるいエンジンはにリダイレクトすることができませんそのリスト、および責任は、リストのハンドラに渡す必要があります。
If neither the Sieve engine nor the list handler can enumerate (or iterate) the list, or the list does not resolve to email addresses, the situation MUST result in a runtime error in the Sieve script.
ふるいエンジンやリスト・ハンドラーのいずれも列挙（または反復）のリストを、またはリストは、電子メールアドレスに解決されない場合は、状況はSieveスクリプトで実行時エラーをもたらさなければなりません。
See Section 2.5 for the detailed description of syntax used for naming externally stored lists.
外部に保存リストに名前を付けるために使用する構文の詳細については、セクション2.5を参照してください。
The uses for external lists specified here represent known cases and situations at the time of this writing. Other uses for external lists, employing other Sieve features, might be devised in the future, and such uses can be described in extensions to this document.
ここで指定した外部リストの用途は、この記事の執筆時点で知られている例や状況を表しています。外部リストの他の用途は、他のふるい機能を採用し、将来考案される可能性があります、そして、そのような用途は、この文書への拡張に記述することができます。
A name of an externally stored list is always an absolute URI [RFC3986]. Implementations might find URIs such as LDAP [RFC4510], CardDAV [CardDAV], or "tag" [RFC4151] to be useful for naming external lists.
外部に格納されたリストの名前は、常に絶対URI [RFC3986]です。実装は、このようなLDAP [RFC4510]、CardDAVの[CardDAVの]、または「タグ」[RFC4151]などのURIが外部リストに名前を付けるために有用であることが見つけるかもしれません。
The "tag" URI scheme [RFC4151] can be used to represent opaque, but more user-friendly identifiers. Resolution of such identifiers is going to be implementation specific and it can help in hiding the complexity of an implementation from end users. For example, an implementation can provide a web interface for managing lists of users stored in LDAP. Requiring users to know generic LDAP URI syntax might not be very practical, due to its complexity. An implementation can instead use a fixed tag URI prefix such as "tag: example.com,<date>:" (where <date> can be, for example, a date generated once on installation of the web interface and left untouched upon upgrades), and the prefix doesn't even need to be shown to end users.
「タグ」URIスキーム[RFC4151]は不透明であるが、よりユーザーフレンドリーな識別子を表すために使用することができます。そのような識別子の解像度は、実装固有になるだろう、それはエンドユーザーからの実装の複雑さを隠すのに役立ちます。例えば、実装は、LDAPに保存されているユーザーのリストを管理するためのWebインターフェイスを提供することができます。一般的なLDAP URIの構文は、その複雑さのために非常に実用的ではないかもしれません知っているユーザーを必要とします。 <日付>とすることができる場合（例えば、日付は、ウェブインタフェースのインストールで一度生成され、アップグレードの際に放置実装ではなく、そのような「：example.com、<日付>タグ」として固定タグURI接頭辞を使用することができ）、および接頭辞でも、エンドユーザーに表示されている必要はありません。
The "addrbook" URNs defined in Section 2.6 (in particular, the reserved URI "urn:ietf:params:sieve:addrbook:default") MUST be supported. To make it easier to use registered Sieve URN parameters, we define a shorthand way to specify them in a Sieve script: a list name that begins with ":" is taken as referencing a Sieve URN parameter, with the initial ":" expanding to "urn:ietf:params:sieve:". So we have the following equivalences:
セクション2.6で定義された "addrbook" のURN（特に、予約URI "URN：IETF：paramsは：ふるい：addrbook：デフォルト"）がサポートされなければなりません。始まるリスト名：それは登録ふるいURNパラメータを使用して、我々はSieveスクリプトでそれらを指定する簡単な方法を定義しやすくするために「：」「：」に拡大した初期に、ふるいURNパラメータを参照するとしています"URN：IETF：のparams：ふるい："。だから我々は、以下の等価を持っています：
:addrbook:default == urn:ietf:params:sieve:addrbook:default
：addrbook：デフォルト== URN：IETF：のparams：ふるい：addrbook：デフォルト
:addrbook:personal == urn:ietf:params:sieve:addrbook:personal
：addrbook：個人==骨壷：IETF：のparams：ふるい：addrbook：個人
and so on.
等々。
The mandatory-to-implement URI
実装に必須のURI
urn:ietf:params:sieve:addrbook:default
URN：IETF：のparams：ふるい：addrbook：デフォルト
gives access to the user's default address book (usually the user's personal address book). Note that these are URIs, subject to normal URI encoding rules, including percent-encoding. The reserved name "default" MUST be considered case-insensitive after decoding. That means that the following URIs are all equivalent:
ユーザーのデフォルトのアドレス帳（通常はユーザーの個人アドレス帳）へのアクセスを提供します。これらはパーセントエンコーディングを含む通常のURIエンコード規則、対象のURIであることに留意されたいです。予約名「デフォルトは」復号後の大文字と小文字を区別しない考えなければなりません。それは、次のURIはすべて同等であることを意味します。
:addrbook:default
：addrbook：デフォルト
:ADDRBOOK:DEFAULT
：ADDRBOOK：DEFAULT
:aDdRbOOk:DeFauLt
：aDdRbOOk：デフォルト
:AddrBook:%44%65%66ault
：AddrBook：％44％65％66ault
Address book names other than "default" MAY be case-sensitive, depending upon the implementation, so their case (after URI decoding) MUST be maintained.
「デフォルト」以外のアドレス帳の名前は実装に応じて、大文字と小文字を区別してもよいし、そう（URIデコード後の）その場合は、維持しなければなりません。
It's possible that a server will have no access to anything resembling an address book (perhaps in an implementation where address books are only client-side things), but the server can still provide access to other sorts of lists -- consider the list of dates in Example 2 (Section 2.9.2), or lists of important keywords and the like. It might sometimes make sense to map ":addrbook:default" into some available list, but that might not always be reasonable. If there really is no concept of an address book in a particular server implementation, the server MAY support ":addrbook:default" by having all matches to it fail. Such an implementation SHOULD NOT be done except as a last resort.
これは、（アドレス帳のみをクライアント側のものがどこにあるか、おそらく実装で）サーバがアドレス帳に似たものにアクセスできないということは可能ですが、サーバーは、まだリストの他の種類へのアクセスを提供することができます - 日付のリストを考えます実施例2の（セクション2.9.2）、または重要なキーワードなどのリスト。 「：addrbook：デフォルト」それは時々マップするために意味をなさないかもしれないいくつかの利用可能なリストに、それは常に合理的ではないかもしれません。実際に、特定のサーバの実装でアドレス帳の概念がない場合は、サーバがサポートしていてもよい（MAY）「：addrbook：デフォルトは」それは失敗にすべての一致を持つこと。このような実装では、最後の手段として以外に行うべきではありません。
Queries against address books SHOULD be done without regard to case.
アドレス帳に対するクエリは大文字小文字を区別せずに行われるべきです。
This section gives the details of the "addrbook" Sieve URN parameter that's registered in Section 4.4. URIs that use this parameter begin with "urn:ietf:params:sieve:addrbook:".
このセクションでは、4.4節で登録されます「addrbook」ふるいURNパラメータの詳細を示します。 "：IETF：のparams：ふるい：addrbook：URN" このパラメータを使用するURIで始まります。
URN parameter name: addrbook
URNパラメータ名：addrbook
URN parameter syntax: The "addrbook" parameter is defined by the <addrbook-urn> rule, defined using ABNF [RFC5234]:
URNパラメータ構文： "addrbook" パラメータは、<addrbook-URN>ルールによって定義され、ABNF [RFC5234]を使用して定義しました
addrbook-urn = "addrbook:" addrbook [ "?" extensions ]
addrbook = segment
; <segment> defined in [RFC3986]
extensions = query
; <query> defined in [RFC3986]
Intended usage: "addrbook" URNs are used for designating references to address books. An address book is a concept used by different applications (such as Sieve interpreters) for describing a list of named entries, and may be translated into other types of address books, such as LDAP groups. Address books may be private or shared; they may be personal, organizational, or perhaps even "crowdsourced".
意図している用法：「addrbook」のURNは、ブックに対処するための参照を指定するために使用されています。アドレス帳は、名前のエントリのリストを記述するための（例えばふるい通訳など）の異なるアプリケーションで使用される概念であり、そのようなLDAPグループとしてアドレス帳の他のタイプ、に変換することができます。アドレス帳は、プライベートまたは共有できます。彼らは、個人、組織、またはおそらく「クラウドソーシング」であってもよいです。
The address book name (the "addrbook" element in the ABNF above) refers to a specifically named address book, as defined by the implementation. A user might, for example, have access to a number of different address books, such as a personal one, a family one, a company one, and one for the town where the user lives.
実装によって定義されるアドレス帳の名前（上記ABNFで「addrbook」要素）は、具体的に名付けられたアドレス帳を指します。ユーザは、例えば、パーソナル1、家族1、会社1、およびユーザーが住んでいる町に1つとして、別のアドレス帳の数へのアクセス権を持っているかもしれません。
The extension information (the "extensions" element in the ABNF above) is available for use in future extensions. It might allow for things such as dynamic subsets of an address book -- for example, something such as this might be defined in the future:
拡張情報（上記ABNFで「拡張」エレメント）は、将来の拡張に使用可能です。このようなアドレス帳の動的なサブセットとして物事を可能とするかもしれません - 例えば、このような何かが将来定義されることがあります。
urn:ietf:params:sieve:addrbook:personal?name.contains=fred
URN：IETF：のparams：ふるい：addrbook：個人name.contains =フレッド？
There are no extensions defined at this time.
この時点で定義された拡張はありません。
An "addrbook" URN is designed to be used by applications for referencing address books. Each URN is intended to represent a grouping of addresses that can be logically thought of as one "book". Any given address can belong to more than one book -- that is, can be referred to by more than one URN.
「addrbook」URNは、アドレス帳を参照するためのアプリケーションで使用するように設計されています。各URNは、論理的に一つの「ブック」と考えることができるアドレスのグループを表すことを意図しています。任意の指定されたアドレスは、複数のブックに属することができます - つまり、複数のURNによって参照することができます。
The URI "urn:ietf:params:sieve:addrbook" has no meaning in itself. It MUST be used with sub-parameters representing the address book name and extension information, as shown in the ABNF above.
URI "URN：IETF：のparams：ふるい：addrbook" は、それ自体では意味がありません。上記ABNFに示すような、アドレス帳の名前と拡張子情報を表すサブパラメータで使用しなければなりません。
The sub-parameter "default" (creating the URN "urn:ietf:params:sieve:addrbook:default") is a reserved (case-insensitive) name that MUST be implemented, representing a default grouping (book) of addresses. Other names, representing the same or other groupings MAY be implemented. For example, an implementation might use the following sub-parameters:
サブパラメータ「デフォルト」（URNを作成「URN：IETF：paramsは：ふるい：addrbook：デフォルト」）がアドレスのデフォルトのグループ（ブック）を表す、実施されなければならない（大文字と小文字を区別しない）予約名です。同じまたは他のグループを表すその他の名称は、実装されてもよいです。例えば、実装は次のサブパラメータを使用する場合があります。
* personal -- a book representing the user's personal address book.
*個人 - ユーザーの個人アドレス帳を表すブック。
* friends -- a subset of urn:ietf:params:sieve:addrbook:personal, defined by the user.
*友人 - 壷のサブセット：IETF：のparams：ふるい：addrbook：個人、ユーザーによって定義されました。
* family -- a subset of urn:ietf:params:sieve:addrbook:personal, defined by the user.
*家族 - 壷のサブセット：IETF：のparams：ふるい：addrbook：個人、ユーザーによって定義されました。
* company -- a book representing the user's company's address book.
*会社 - ユーザーの会社のアドレス帳を表すブック。
* department -- a subset of urn:ietf:params:sieve:addrbook:company, defined by the company.
*部門 - 壷のサブセット：IETF：のparams：ふるい：addrbook：会社、会社によって定義されます。
* co-workers -- a subset of urn:ietf:params:sieve:addrbook:company, defined by the user.
*同僚 - URNの一部：IETF：のparams：ふるい：addrbook：会社、ユーザーによって定義されました。
* default -- the default address book, a reference to urn:ietf:params:sieve:addrbook:personal.
*デフォルト - デフォルトのアドレス帳、URNへの参照：IETF：のparams：ふるい：addrbook：個人的な。
Interoperability considerations: Applications are only REQUIRED to support "addrbook:default", where all cases and encodings of "default" are considered equivalent. Address book names other than "default" MAY be case-sensitive, depending upon the implementation, so their case (after URI decoding) MUST be maintained.
相互運用性に関する注意事項：すべてのケースと「デフォルト」のエンコーディングが同等であると考えられる：「デフォルトaddrbook」を、アプリケーションのみをサポートしている必要があります。 「デフォルト」以外のアドレス帳の名前は実装に応じて、大文字と小文字を区別してもよいし、そう（URIデコード後の）その場合は、維持しなければなりません。
Security considerations: Applications SHOULD ensure appropriate restrictions are in place to protect sensitive information that might be revealed by "addrbook" URNs from access or modification by untrusted sources.
セキュリティに関する注意事項：アプリケーションは、適切な制限は信頼できないソースからのアクセスや変更から「addrbook」のURNによって明らかにされるかもしれない機密情報を保護するための場所であることを確認すべきです。
Contact: Sieve mailing list <sieve@ietf.org>
連絡先：ふるいメーリングリスト<sieve@ietf.org>
Usage: valid_ext_list <ext-list-names: string-list>
使用法：valid_ext_list <EXT-リスト名：文字列のリスト>
The "valid_ext_list" test is true if all of the external list names in the ext-list-names argument are supported, and they are valid both syntactically (including URI parameters) and semantically (including implementation-specific semantic restrictions). Otherwise, the test returns false.
EXT-リスト-names引数で外部リスト名のすべてがサポートされている場合は、「valid_ext_list」テストが真である、と彼らは（URIパラメータを含む）と意味的（実装固有の意味上の制限を含む）は構文的に有効の両方です。そうでなければ、テストはfalseを返します。
This test MUST perform exactly the same validation of an external list name as would be performed by the "header :list" test.
試験：「リストヘッダ」によって実行されるように、この試験は、外部リストの名前の正確に同じ検証を実行しなければなりません。
This extension defines the following new capability for ManageSieve (see [RFC5804], Section 1.7):
この拡張は、ManageSieveのため、以下の新機能を（[RFC5804]、セクション1.7を参照）を定義します：
EXTLISTS - A space-separated list of URI schema parts [RFC3986] for supported externally stored list types. This capability MUST be returned if the corresponding Sieve implementation supports the "extlists" extension defined in this document.
EXTLISTS - サポートされている外部記憶されたリスト・タイプのURIスキーマパーツ[RFC3986]のスペースで区切られたリスト。対応するふるいの実装は、この文書で定義された「extlists」の拡張子をサポートしている場合、この機能は返さなければなりません。
This also extends the ManageSieve ABNF as follows:
これは次のようにもManageSieve ABNFを拡張します。
single-capability =/ DQUOTE "EXTLISTS" DQUOTE SP ext-list-types CRLF ; single-capability is defined in [RFC5804]
シングル機能= / DQUOTE "EXTLISTS" DQUOTE SPのEXT-リストタイプCRLF;単機能は[RFC5804]で定義されています
ext-list-types = string ; space separated list of URI schema parts ; for supported externally stored list types. ; MUST NOT be empty.
EXT-リストのタイプ=文字列。スペースは、URIスキーマ部品のリストを分離しました。サポート外部に格納されているリストの種類について。 ;空にすることはできません。
This example uses a personal address book, along with the Spamtest [RFC5235] and Relational [RFC5231] extensions to give a different level of spam tolerance to known senders.
この例では、既知の送信者へのスパムの許容範囲の異なるレベルを与えるためにはspamtest [RFC5235]とリレーショナル[RFC5231]の拡張に伴い、個人アドレス帳を使用しています。
require ["envelope", "extlists", "fileinto", "spamtest",
"relational", "comparator-i;ascii-numeric"];
if envelope :list "from" ":addrbook:default"
{ /* Known: allow high spam score */
if spamtest :value "ge" :comparator "i;ascii-numeric" "8"
{
fileinto "spam";
}
}
elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3"
{ /* Unknown: less tolerance in spam score */
fileinto "spam";
}
The same example can also be written another way, if the Variables extension [RFC5229] is also supported:
変数拡張[RFC5229]をもサポートされている場合、同じ実施例はまた、別の方法を書くことができます。
require ["envelope", "extlists", "fileinto", "spamtest",
"variables", "relational", "comparator-i;ascii-numeric"];
if envelope :list "from" ":addrbook:default" {
set "lim" "8"; /* Known: allow high spam score */
} else {
set "lim" "3"; /* Unknown: less tolerance in spam score */
}
if spamtest :value "ge" :comparator "i;ascii-numeric" "${lim}" {
fileinto "spam";
}
This example uses the "currentdate" test [RFC5260] and a list containing the dates of local holidays. If today is a holiday, the script will notify (as described in [RFC5435]) the user via the Extensible Messaging and Presence Protocol (XMPP) [RFC5437] about the message.
この例では、「CURRENTDATE」テスト[RFC5260]と地元の休日の日付を含むリストを使用しています。今日は休日である場合、スクリプトは（[RFC5435]で説明したように）、メッセージに関する拡張メッセージおよびプレゼンスプロトコル（XMPP）を介してユーザ[RFC5437]を通知します。
require ["extlists", "date", "enotify"];
if currentdate :list "date"
"tag:example.com,2011-01-01:localHolidays" {
notify "xmpp:romeo@im.example.com";
}
This example also uses the "envelope" option [RFC5228] and the Subaddress extension [RFC5233]. If mail is sent with the list name as a subaddress of the recipient (to, say, "alexey+mylist"), and the message comes from a member of the list, it will be redirected to all members of the list. Variants of this technique might be useful for creating private mailing lists.
また、この例では、「エンベロープ」オプション[RFC5228]およびサブアドレス拡張[RFC5233]を使用しています。メールは（たとえば、「アレクセイ+マイリスト」への）受信者のサブアドレスとしてリスト名で送信され、メッセージがリストのメンバーから来て、それはリストのすべてのメンバーにリダイレクトされます。場合この技術の変種は、プライベートメーリングリストを作成する場合に便利かもしれません。
require ["extlists", "envelope", "subaddress"];
[ "extlists"、 "封筒"、 "サブアドレス"]が必要です。
# Submission from list members is sent to all members if allof (envelope :detail "to" "mylist", header :list "from" "tag:example.com,2010-05-28:mylist") { redirect :list "tag:example.com,2010-05-28:mylist"; }
＃リストのメンバーからの申込は、すべてのメンバーに送信される場合ALLOF（エンベロープ：詳細「を」「マイリスト：「example.com、2010-05-28：マイリストタグ」」から「ヘッダリスト」）{リダイレクト：リスト "タグ：example.com、2010年5月28日：mylistという "; }
This example uses variable matching [RFC5229] to extract the IP address from the last "Received" header field. It then checks that against a "block list" of undesirable IP addresses, and rejects the message if there's a match.
この例では、最後の「受信」ヘッダフィールドからIPアドレスを抽出する可変整合[RFC5229]を使用します。その後、望ましくないIPアドレスの「ブロックリスト」に対することを確認し、一致があるかどうメッセージを拒否します。
require ["variables", "extlists", "index", "reject"];
if header :index 1 :matches "received" "*(* [*.*.*.*])*" {
set "ip" "${3}.${4}.${5}.${6}";
if string :list "${ip}"
"tag:example.com,2011-04-10:DisallowedIPs" {
reject "Message not allowed from this IP address";
}
}
This example uses several features of the MIME parts extension [RFC5703] to scan for unsafe attachment types. To make it easily extensible, the unsafe types are kept in an external list, which would be shared among all users and all scripts, avoiding the need to change scripts when the list changes.
この例では、安全でない添付ファイルの種類をスキャンするMIME部分の拡張[RFC5703]のいくつかの機能を使用します。それは簡単に拡張させるために、危険なタイプは、リストが変化したときに、スクリプトを変更する必要がなくなり、すべてのユーザーとすべてのスクリプト間で共有されるだろう、外部のリストに保存されています。
[Note that this is an illustrative example, and more rigorous malware filtering is advisable. It is insufficient to base email security on checks of filenames alone.]
【これは例示的な例であり、より厳密なマルウェアフィルタリングが賢明であることに留意されたいです。それだけでは、ファイル名のチェックにベースの電子メールのセキュリティには不十分です。]
require [ "extlists", "foreverypart", "mime", "enclose" ];
必要[ "extlists"、 "foreverypart"、 "MIME"、 "囲み"]。
foreverypart { if header :mime :param "filename" :list ["Content-Type", "Content-Disposition"] "tag:example.com,2011-04-10:BadFileNameExts" { # these attachment types are executable enclose :subject "Warning" :text WARNING! The enclosed message has attachments that might be unsafe. These attachment types may contain a computer virus program that can infect your computer and potentially damage your data.
foreverypart {ヘッダ場合：MIME：PARAM "ファイル名"：リスト[ "のContent-Type"、 "コンテンツの廃棄"] "タグ：example.com、2011-04-10：BadFileNameExtsは" {＃これらの添付ファイルの種類は、実行可能な囲みです。件名 "警告"：テキストWARNING！囲まれたメッセージは、安全でないかもしれない添付ファイルがあります。これらの添付ファイルの種類は、お使いのコンピュータに感染し、潜在的にあなたのデータに損傷を与えることができるコンピュータウイルスプログラムが含まれていてもよいです。
Before clicking on these message attachments, you should verify
with the sender that this message was sent intentionally, and
that the attachments are safe to open.
.
;
break;
}
}
Security considerations related to the "address"/"envelope"/"header" tests and "redirect" action discussed in Sieve [RFC5228] also apply to this document.
「アドレス」/「エンベロープ」/「ヘッダ」試験篩[RFC5228]で説明した「リダイレクトする」アクションに関連するセキュリティの考慮事項は、この文書に適用されます。
External list memberships ought to be treated as if they are an integral part of the script, so a temporary failure to access an external list SHOULD be handled in the same way as a temporary failure to retrieve the Sieve script itself.
外部リストのメンバーシップは、彼らは、スクリプトの不可欠な一部であるかのように扱われるべきであるので、外部リストにアクセスするための一時的な障害は、Sieveスクリプト自体を取得するための一時的な障害と同じように処理しなければなりません。
For example, if the Sieve script is stored in the Lightweight Directory Access Protocol [RFC4510] and the script can't be retrieved when a message is processed (perhaps the LDAP server is unavailable), then the Sieve engine might delay message delivery until the script can be retrieved successfully. Similarly, if an external list is stored in LDAP and that LDAP server is unavailable, the Sieve engine would take the same action -- delay message delivery and try again later.
Sieveスクリプトを（おそらくLDAPサーバが利用できない）、ライトウェイトディレクトリアクセスプロトコル[RFC4510]に格納され、メッセージが処理されるときに、スクリプトが取得できない場合、例えば、次にふるいエンジンがされるまでメッセージの配信が遅れる可能性がありますスクリプトが正常に取得することができます。外部リストは、LDAPに格納されているLDAPサーバが使用できないされている場合同様に、ふるいエンジンは同じ行動取るだろう - 遅延メッセージの配信を、後で再試行してください。
Protocols/APIs used to retrieve/verify external list membership MUST provide an appropriate level of confidentiality and authentication. Usually, that will be at least the same level of confidentiality as protocols/APIs used to retrieve Sieve scripts, but only the implementation (or deployment) will know what is appropriate. There's a difference, for example, between making an LDAP request on a closed LAN that's only used for trusted servers (it may be that neither encryption nor authentication is needed), on a firewalled LAN internal to a company (it might be OK to skip encryption, depending upon policy), and on the open Internet (encryption and authentication are probably both required). It also matters whether the list being accessed is private or public (no encryption or authentication may be needed for public data, even on the Internet).
検証/外部リストのメンバーシップを取得するために使用されるプロトコル/ APIは、機密性と認証の適切なレベルを提供しなければなりません。通常、それは、Sieveスクリプトを検索するために使用されるプロトコル/ APIのように機密性の少なくとも同じレベルになりますが、唯一の実装（または展開）が適切であるか知っているだろう。違いがあります、例えば、社内のファイアウォールLAN上で、（それはどちらも暗号化や認証が必要とされていることもあります）のみ、信頼できるサーバー用に使われているクローズドLAN上のLDAP要求を行う間（スキップしてOKかもしれません暗号化、ポリシーに応じて）、およびオープンなインターネット上の（暗号化および認証）は、おそらく両方が要求されます。また、アクセスされているリストは、（さらにはインターネット上で、何の暗号化や認証は、公開データのために必要とされなくてもよい）、プライベートまたはパブリックであるかどうかを問題になります。
Having the processing and outcome of a Sieve script depend on the contents of external data can allow someone with control of the external data to have unusual, and perhaps unauthorized, control of the script -- and, consequently, of the disposition of the user's email. A user using such a list for spam control, for example, might find important mail being discarded because of tampering with the list. Someone using redirect to an external list could have her email redirected to the wrong eyes because of such tampering. Security and integrity protection of external lists is as important as protection of the Sieve script itself.
ユーザーの電子メールの配置、結果的に、そして - 外部データの内容に依存しSieveスクリプトの処理と結果を持つことは、外部データの制御に誰かがスクリプトの珍しい、おそらく不正、コントロールを持ってできるようにすることができます。スパム制御のためのそのようなリストを使用して、ユーザーは、例えば、重要なメールがあるため、リストの改ざんを破棄されているかもしれません。使用して、外部リストにリダイレクト誰かが彼女の電子メールがあるため、このような改ざんの間違った目にリダイレクト可能性があります。外部リストのセキュリティと完全性保護がSieveスクリプト自体の保護と同様に重要です。
Implementations of this extension should keep in mind that matching values against an externally stored list can be I/O and/or CPU intensive. This can be used to deny service to the mail server and/or to servers providing access to externally stored mailing lists. A naive implementation, such as the one that tries to retrieve content of the whole list to perform matching, can make this worse.
この拡張機能の実装は、外部に格納されたリストに対して一致する値は、I / Oおよび/またはCPUを集中できることを心に留めておく必要があります。これは、メールサーバにおよび/または外部に保存されたメーリングリストへのアクセスを提供するサーバにサービスを拒否するために使用することができます。そのようなマッチングを行うためにリスト全体のコンテンツを取得しようとする一つとして、素朴な実装では、これを悪化させることができます。
But note that many protocols that can be used for accessing externally stored lists support flexible searching features that can be used to minimize network traffic and load on the directory service. For example, LDAP allows for search filters. Implementations SHOULD use such features whenever they can.
しかし、外部に保存されたリストにアクセスするために使用することができる多くのプロトコルは、ディレクトリサービス上のネットワークトラフィックと負荷を最小限に抑えることができる柔軟な検索機能をサポートすることに注意してください。たとえば、LDAPは、検索フィルタが可能になります。いつでも彼らができる実装は、このような機能を使用すべきです。
Many organizations support external lists with thousands of recipients. In order to avoid mailbombs when redirecting a message to an externally stored list, implementations SHOULD enforce limits on the number of recipients and/or on domains to which such recipients belong.
多くの組織では、受信者の何千もの外部リストをサポートしています。外部に格納されたリストにメッセージをリダイレクトするときmailbombsを回避するために、実装および/またはそのような受信者が所属するドメインの受信者数の制限を強制します。
Note, in particular, that it can be too easy for a script to use redirect :list ":addrbook:default"; to send messages to "everyone in your address book", and one can easily imagine both intentional and accidental abuse. The situation can be even worse for, say, ":addrbook:corporate". Warnings, as well as enforced limits, are appropriate here.
リスト「：：addrbook：デフォルト」スクリプトは、リダイレクトを使用することがあまりにも簡単にできることを、具体的には、注意してください。 「あなたのアドレス帳の全員」にメッセージを送信すると、1つは簡単に意図的かつ偶発両方虐待を想像することができます。状況はさらに悪化のためにすることができ、言う「：addrbook：企業」。警告だけでなく、強制制限が、ここでは適切です。
Applications SHOULD ensure appropriate restrictions are in place to protect sensitive information that might be revealed by "addrbook" URNs from access or modification by untrusted sources.
アプリケーションは、適切な制限は信頼できないソースからのアクセスまたは変更から「addrbook」のURNによって明らかにされるかもしれない機密情報を保護するために整備されていることを確認すべきです。
The following template specifies the IANA registration of the Sieve extension specified in this document. This information has been added to the Sieve Extensions registry on http://www.iana.org.
次のテンプレートは、この文書で指定されたSieve拡張のIANA登録を指定します。この情報はhttp://www.iana.orgにふるい拡張レジストリに追加されました。
To: iana@iana.org
と： いあな＠いあな。おｒｇ
Subject: Registration of new Sieve extension
件名：新しいふるい拡張の登録
Capability name: extlists
能力名：extlists
Description: Adds the ":list" match type to certain Sieve tests, and the ":list" argument to the "redirect" action. The ":list" match type changes tests to match values against values stored in one or more externally stored lists. The ":list" argument to the redirect action changes the redirect action to forward the message to email addresses stored in the externally stored list.
説明：アクションを「リダイレクト」に：「リスト」引数特定のふるい試験をマッチタイプ、および：「リスト」に追加します。 「：リスト」マッチタイプは、一つ以上の外部に保存されたリストに格納された値に対して値を一致させるためにテストを変更します。 ：リダイレクトアクションに「リスト」の引数は、外部に格納されたリストに保存された電子メールアドレスにメッセージを転送するリダイレクトアクションを変更します。
RFC number: RFC 6134
RFC番号：RFC 6134
Contact address: Sieve mailing list <sieve@ietf.org>
連絡先アドレス：ふるいメーリングリスト<sieve@ietf.org>
IANA has registered a new ManageSieve Capability according to the IANA registration template specified in [RFC5804]:
IANAは[RFC5804]で指定されたIANA登録テンプレートに従って新しいManageSieve能力を登録しています：
To: iana@iana.org
と： いあな＠いあな。おｒｇ
Subject: ManageSieve Capability Registration
件名：ManageSieve能力登録
Capability name: extlists
能力名：extlists
Description: This capability is returned if the server supports the "extlists" RFC 6134 Sieve extension.
説明：サーバーは「extlists」RFC 6134ふるい拡張をサポートしている場合、この機能が返されます。
Relevant publications: RFC 6134, Section 2.8
関連資料：RFC 6134、セクション2.8
Person & email address to contact for further information: Sieve mailing list <sieve@ietf.org>
人とEメールアドレスは、詳細のために連絡する：ふるいメーリングリスト<sieve@ietf.org>
Author/Change controller: IESG
著者/変更コントローラ：IESG
IANA has created a new registry under "Sieve Extensions" for Sieve URN Parameters. Registration into this registry is according to the "Specification Required" policy [RFC5226].
IANAは、ふるいURNパラメータの「ふるい拡張機能」の下に新しいレジストリを作成しました。このレジストリへの登録は、「仕様が必要」ポリシー[RFC5226]に従っています。
The registry contains the following two items:
レジストリには、次の2つの項目が含まれています。
URN parameter name: The name of the URN parameter. If the name is "paramname", the resulting top-level URN will be "urn:ietf:params:sieve:paramname".
URNパラメータ名：URNパラメータの名前。名前は「paramNameに」である場合、結果のトップレベルのURNは、「URN：IETF：のparams：ふるい：paramNameに」となります。
Reference: The document and section where the definition of the parameter can be found. Be sure to include the section number as well as the document reference, so the documentation is easy to find.
参考：パラメータの定義を見つけることができるドキュメントやセクション。ドキュメントを見つけるのは簡単ですので、セクション番号だけでなく、文書の参照を含めるようにしてください。
The documentation -- which will be in the referenced document and section, and will not be included in the registry -- MUST include the following information (see Section 2.6 for an example):
ドキュメント - 参照文書およびセクションになり、レジストリに含まれない - 以下の情報を含まなければならない（例えば、セクション2.6を参照）。
URN parameter name: The name of the URN parameter.
URNパラメータ名：URNパラメータの名前。
URN parameter syntax: The syntax of the parameter and any sub-parameters, which SHOULD be specified using ABNF [RFC5234].
URNパラメータ構文：ABNF [RFC5234]を使用して指定されるべきであるパラメータと任意のサブパラメータの構文、。
Intended usage: A detailed description of how the parameter and any sub-parameters are expected to be used. This is the place to define static sub-parameters, registries for sub-parameters, options, registries for options, and so on.
意図された使用：パラメータと任意のサブパラメータを使用することが期待されている方法の詳細な説明。これには、静的サブパラメータ、サブパラメータのためのレジストリ、オプション、オプションのためのレジストリなどを定義するための場所です。
Interoperability considerations: Any notes specific to interoperability issues. This is where to put mandatory-to-implement sub-parameters and the like.
相互運用性に関する注意事項：相互運用性の問題に固有の任意のノート。実装に必須のサブパラメータ等を配置する場所です。
Security considerations: Any notes specific to security and privacy issues.
セキュリティの考慮事項：セキュリティとプライバシーの問題に固有の任意のノート。
Contact: Contact information, in case there are questions.
連絡先：ご質問がある場合には、情報をお問い合わせください。
IANA has registered a new Sieve URN parameter in the registry defined in Section 4.3.
IANAはセクション4.3で定義されたレジストリに新しいふるいURNパラメータを登録しています。
URN parameter name: addrbook
URNパラメータ名：addrbook
Reference: RFC 6134, Section 2.6
参考：RFC 6134、セクション2.6
IANA has registered a new URN sub-namespace within the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers defined in [RFC3553].
IANAは[RFC3553]で定義された登録プロトコルパラメータ識別子のIETF URNサブ名前空間内の新しいURNサブ名前空間を登録しました。
Registry name: sieve
レジストリ名：ふるいです
Specification: RFC 6134
仕様：RFC 6134
Repository: Sieve URN Parameters registry (Section 4.3)
リポジトリ：ふるいURNパラメータレジストリ（4.3節）
Index value: Sub-parameters MUST be specified in UTF-8, using standard URI encoding where necessary.
指標値：サブパラメータが必要な場合、標準的なURIエンコーディングを使用して、UTF-8で指定する必要があります。
Thanks to Alexandros Vellis, Nigel Swinson, Ned Freed, Kjetil Torgrim Homme, Dave Cridland, Cyrus Daboo, Pete Resnick, and Robert Burrell Donkin for ideas, comments, and suggestions. Kristin Hubner also helped greatly with the examples.
アイデア、コメント、および提案のためのアレクサンドロスVellis、ナイジェルSwinson、ネッドフリード、はKjetil Torgrimオム、デイブCridland、サイラスDaboo、ピート・レズニック、そしてロバート・バレルDonkinにに感謝します。クリスティン・ヒューブナーはまた、例を挙げて大いに役立ちました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC 4151, October 2005.
[RFC4151] Kindberg、T.とS.ホーク、 " 'タグ' URIスキーム"、RFC 4151、2005年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]ギュンター、P.およびT.ショーウォルター監督、 "ふるい：メールフィルタリング言語"、RFC 5228、2008年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, July 2010.
[RFC5804]メルニコフ、A.およびT.マーティン、 "リモート管理Sieveスクリプトのためのプロトコル"、RFC 5804、2010年7月。
[CardDAV] Daboo, C., "vCard Extensions to WebDAV (CardDAV)", Work in Progress, November 2009.
[CardDAVの] Daboo、C.、 "WebDAVのにvCardの拡張機能（CardDAVの）"、進歩、2009年11月に作業。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] Mealling、M.、Masinter、L.、ハーディー、T.、およびG. Klyne、 "登録プロトコル・パラメータのためのIETF URNサブ名前空間"、BCP 73、RFC 3553、2003年6月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"、RFC 4510、2006年6月。
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[RFC5229]オム、K.、 "ふるいメールフィルタリング：変数の拡張"、RFC 5229、2008年1月。
[RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: Relational Extension", RFC 5231, January 2008.
[RFC5231] Segmuller、W.及びB. Leiba、 "ふるいメールフィルタリング：リレーショナル拡張"、RFC 5231、2008年1月。
[RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress Extension", RFC 5233, January 2008.
[RFC5233]マーチソン、K.、 "ふるいメールフィルタリング：サブアドレス拡張"、RFC 5233、2008年1月。
[RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.
[RFC5235] Daboo、C.、 "ふるいメールフィルタリング：はspamtestとVirustest拡張機能"、RFC 5235、2008年1月。
[RFC5260] Freed, N., "Sieve Email Filtering: Date and Index Extensions", RFC 5260, July 2008.
[RFC5260]解放され、N.、 "ふるいメールフィルタリング：日付とインデックス拡張機能"、RFC 5260、2008年7月。
[RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
[RFC5435]メルニコフ、A.、Leiba、B.、Segmuller、W.、およびT.マーティン、 "ふるい電子メールフィルタリング：通知のための拡張"、RFC 5435、2009年1月。
[RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)", RFC 5437, January 2009.
[RFC5437]サンアンドレ、P.およびA.メルニコフ、 "ふるい通知メカニズム：拡張メッセージングおよびプレゼンスプロトコル（XMPP）"、RFC 5437、2009年1月。
[RFC5463] Freed, N., "Sieve Email Filtering: Ihave Extension", RFC 5463, March 2009.
[RFC5463]フリード、N.、 "ふるいのメールフィルタリング：IHAVE拡張"、RFC 5463、2009年3月。
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, October 2009.
[RFC5703]ハンセン、T.とC. Daboo、 "ふるいメールフィルタリング：MIMEパートのテスト、反復、抽出、置換、およびエンクロージャ"、RFC 5703、2009年10月。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Barry Leiba Huawei Technologies
バリー・レイバ、華為技術
Phone: +1 646 827 0648 EMail: barryleiba@computer.org URI: http://internetmessagingtechnology.org/
電話：+1 646 827 0648 Eメール：barryleiba@computer.org URI：http://internetmessagingtechnology.org/