RFC5293 日本語訳

Network Working Group                                         J. Degener
Request for Comments: 5293                                   P. Guenther
Category: Standards Track                                 Sendmail, Inc.
                                                             August 2008

Degenerがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5293年のP.グンサーカテゴリ: 標準化過程センドメールInc.2008年8月

              Sieve Email Filtering: Editheader Extension

ふるいのメールフィルタリング: Editheader拡張子

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document defines two new actions for the "Sieve" email filtering
   language that add and delete email header fields.

このドキュメントは「ふるい」メールフィルタリング言語のためのメールヘッダーフィールドを加えて、削除する2回の新しい動きを定義します。

1.  Introduction

1. 序論

   Email header fields are a flexible and easy-to-understand means of
   communication between email processors.  This extension enables sieve
   scripts to interact with other components that consume or produce
   header fields by allowing the script to delete and add header fields.

メールヘッダーフィールドはメールプロセッサのコミュニケーションのフレキシブルで分かり易い手段です。 この拡大は、ふるいのスクリプトがスクリプトがヘッダーフィールドを削除して、加えるのを許容することによって、ヘッダーフィールドを消費するか、または生産する他のコンポーネントと対話するのを可能にします。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?

   Conventions for notations are as in Section 1.1 of [SIEVE], including
   use of the "Usage:" label for the definition of action and tagged
   arguments syntax.

記法のためのコンベンションが[SIEVE]のセクション1.1にあって、使用を含めている、「用法:」 動作とタグ付けをされた議論構文の定義のために、ラベルします。

   The term "header field" is used here as in [IMAIL] to mean a logical
   line of an email message header.

「ヘッダーフィールド」という用語はメールメッセージヘッダーの論理行を意味する[IMAIL]のようにここで使用されます。

3.  Capability Identifier

3. 能力識別子

   The capability string associated with the extension defined in this
   document is "editheader".

定義される拡大に関連している能力ストリングは本書では"editheader"です。

Degener & Guenther          Standards Track                     [Page 1]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[1ページ]: Editheader拡大2008年8月

4.  Action addheader

4. 動作addheader

   Usage: "addheader" [":last"] <field-name: string> <value: string>

用法: "addheader"[「: 最終」]<フィールド名: ><価値を結んでください: ストリング>。

   The addheader action adds a header field to the existing message
   header.  If the field-name is not a valid 7-bit US-ASCII header field
   name, as described by the [IMAIL] "field-name" nonterminal syntax
   element, the implementation MUST flag an error.  The addheader action
   does not affect Sieve's implicit keep.

addheader動作は既存のメッセージヘッダーにヘッダーフィールドを加えます。 フィールド名が有効な7ビットの米国-ASCIIヘッダーフィールド名でないなら、[IMAIL]「フィールド名」非終端記号構文要素によって説明されるように、実現は誤りに旗を揚げさせなければなりません。 addheader動作はSieveの暗黙の生活費に影響しません。

   If the specified field value does not match the [IMAIL]
   "unstructured" nonterminal syntax element or exceeds a length limit
   set by the implementation, the implementation MUST either flag an
   error or encode the field using folding white space and the encodings
   described in [MIME3] or [MIMEPARAM] to be compliant with [IMAIL].

指定された分野値が[IMAIL]「不統一な」非終端記号構文要素を合わせないか、または実現で長さの極限集合を超えているなら、[IMAIL]と共に言いなりになるために[MIME3]か[MIMEPARAM]で説明された折りたたみの余白とencodingsを使用して、実現は、誤りに旗を揚げさせなければならないか、または分野をコード化しなければなりません。

   An implementation MAY impose a length limit onto the size of the
   encoded header field; such a limit MUST NOT be less than 998
   characters, not including the terminating CRLF supplied by the
   implementation.

実現はコード化されたヘッダーフィールドのサイズに長さの限界を課すかもしれません。 そのような限界はCRLFが実現で供給した終わりを含んでいるのではなく、998未満のキャラクタであるはずがありません。

   By default, the header field is inserted at the beginning of the
   existing message header.  If the optional flag ":last" is specified,
   it is appended at the end.

デフォルトで、ヘッダーフィールドは既存のメッセージヘッダーの始めに挿入されます。 「任意であるなら、」 : 最終に旗を揚げさせてください」、指定されていて、終わりにそれを追加します。

   Example:

例:

        /* Don't redirect if we already redirected */
        if not header :contains "X-Sieve-Filtered"
                ["<kim@job.example.com>", "<kim@home.example.com>"]
        {
                addheader "X-Sieve-Filtered" "<kim@job.example.com>";
                redirect "kim@home.example.com";
        }

「/*が私たちが既に*/を向け直したか、そして、ヘッダー:contains「フィルターにかけられたXふるい」を向け直さない、[ "<kim@job.example.com 、gt;、」、 "<kim@home.example.com 、gt;、」、]「addheader「フィルターにかけられたXふるい」 "<kim@job.example.com 、gt;、」 ; " kim@home.example.com "を向け直してください。

5.  Action deleteheader

5. 動作deleteheader

      Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
                   [COMPARATOR] [MATCH-TYPE]
                   <field-name: string>
                   [<value-patterns: string-list>]

用法: "deleteheader"[「: インデックス」<fieldno: 数の>[「: 最終」]][COMPARATOR][MATCH-TYPE]<フィールド名: ストリング>。[<価値パターン: ストリングリスト>]

   By default, the deleteheader action deletes all occurrences of the
   named header field.  The deleteheader action does not affect Sieve's
   implicit keep.

デフォルトで、deleteheader動作は命名されたヘッダーフィールドのすべての発生を削除します。 deleteheader動作はSieveの暗黙の生活費に影響しません。

Degener & Guenther          Standards Track                     [Page 2]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[2ページ]: Editheader拡大2008年8月

   The field-name is mandatory and always matched as a case-insensitive
   US-ASCII string.  If the field-name is not a valid 7-bit header field
   name as described by the [IMAIL] "field-name" nonterminal syntax
   element, the implementation MUST flag an error.

フィールド名は、義務的であって、大文字と小文字を区別しない米国-ASCIIストリングとしていつも取り組んでいます。 フィールド名が[IMAIL]「フィールド名」非終端記号構文要素によって説明されるように有効な7ビットのヘッダーフィールド名でないなら、実現は誤りに旗を揚げさせなければなりません。

   The value-patterns, if specified, restrict which occurrences of the
   header field are deleted to those whose values match any of the
   specified value-patterns, the matching being according to the match-
   type and comparator and performed as if by the "header" test.  In
   particular, leading and trailing whitespace in the field values is
   ignored.  If no value-patterns are specified, then the comparator and
   match-type options are silently ignored.

値パターンであって、指定されていて、ヘッダーフィールドのどの発生がマッチタイプに従ってマッチングがあって、値が指定された値パターンについて何かにも合っているそれらに削除されるか、そして、比較器を制限してください、そして、「ヘッダー」で実行されて、テストしてください。 特に、分野値における主で引きずっている空白は無視されます。 値パターンが全く指定されないなら、比較器とマッチタイプオプションは静かに無視されます。

   If :index <fieldno> is specified, the attempts to match a value are
   limited to the <fieldno> occurrence of the named header field,
   beginning at 1, the first named header field.  If :last is specified,
   the count is backwards; 1 denotes the last named header field, 2 the
   second to last, and so on.  The counting happens before the <value-
   patterns> match, if any.  For example:

:index<fieldno>が指定されるなら、値を合わせる試みは命名されたヘッダーフィールドの<fieldno>発生に制限されます、1から、ヘッダーフィールドという1番目。 :lastが指定されるなら、カウントは後方に指定されます。 1は最後に命名されたヘッダーフィールド、2を指示します。持続する2番目など。 <が>マッチを値で型に基づいて作る前に勘定はもしあれば起こります。 例えば:

      deleteheader :index 1 :contains "Delivered-To"
                              "bob@example.com";

deleteheader:index1:containsは" bob@example.com "を「配達しました」。

   deletes the first "Delivered-To" header field if it contains the
   string "bob@example.com" (not the first "Delivered-To" field that
   contains "bob@example.com").

ストリング" bob@example.com "を含んでいるなら(いずれの1番目も" bob@example.com "を含む分野を「配達しなかった」)、最初に「配達された」というヘッダーフィールドを削除します。

   It is not an error if no header fields match the conditions in the
   deleteheader action or if the :index argument is greater than the
   number of named header fields.

どんなヘッダーフィールドもdeleteheader動作における状態に合っていないか、または:index議論が命名されたヘッダーフィールドの数より大きいなら、それは誤りではありません。

   The implementation MUST flag an error if :last is specified without
   also specifying :index.

:lastがまた、:indexを指定しないで指定されるなら、実現は誤りに旗を揚げさせなければなりません。

6.  Implementation Limitations on Changes

6. 変化における実現制限

   As a matter of local policy, implementations MAY limit which header
   fields may be deleted and which header fields may be added.  However,
   implementations MUST NOT permit attempts to delete "Received" and
   "Auto-Submitted" header fields and MUST permit both addition and
   deletion of the "Subject" header field.

ローカルの方針の問題として、それのヘッダーフィールドが削除されるかもしれなくて、ヘッダーがさばく実現5月の限界は加えられるかもしれません。 しかしながら、実現は、「受け取られていてい」て「自動提出された」ヘッダーフィールドを削除する試みを可能にしてはいけなくて、添加と「受けることがある」ヘッダーフィールドの削除の両方を可能にしなければなりません。

   If a script tries to make a change that isn't permitted, the attempt
   MUST be silently ignored.

スクリプトが受入れられない変更を行おうとするなら、静かに試みを無視しなければなりません。

Degener & Guenther          Standards Track                     [Page 3]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[3ページ]: Editheader拡大2008年8月

7.  Interaction with Other Sieve Extensions

7. 他のふるいの拡大との相互作用

   Actions that generate [MDN], [DSN], or similar disposition messages
   MUST do so using the original, unmodified message header.  Similarly,
   if an error terminates processing of the script, the original message
   header MUST be used when doing the implicit keep required by Section
   2.10.6 of [SIEVE].

[MDN]、[DSN]、または同様の気質メッセージを発生させる動作はそうオリジナルの、そして、変更されていないメッセージヘッダーを使用にしなければなりません。 暗黙が続けるするのが.6セクション2.10[SIEVE]が必要であるときに、同様に、誤りがスクリプトの処理を終えるなら、オリジナルのメッセージヘッダーを使用しなければなりません。

   All other actions that store, send, or alter the message MUST do so
   with the current set of header fields.  This includes the addheader
   and deleteheader actions themselves.  For example, the following
   leaves the message unchanged:

したがって、メッセージを格納するか、送るか、または変更する他のすべての動作が現在のヘッダーフィールドを処理しなければなりません。 これはaddheaderとdeleteheader動作自体を含んでいます。 例えば、以下はメッセージを変わりがないままにします:

      addheader "X-Hello" "World";
      deleteheader :index 1 "X-Hello";

addheader、「X、-、こんにちは、」 「世界的に」。 deleteheader:index1、「X、-、こんにちは、」、。

   Similarly, given a message with three or more "X-Hello" header
   fields, the following example deletes the first and third of them,
   not the first and second:

aを考えて、同様に、3以上で通信してください、「X、-、こんにちは、」 ヘッダーフィールド、以下の例は1番目と2番目ではなく、それらの1番目と3つ番目を削除します:

      deleteheader :index 1 "X-Hello";
      deleteheader :index 2 "X-Hello";

deleteheader:index1、「X、-、こんにちは、」、。 deleteheader:index2、「X、-、こんにちは、」、。

   Tests and actions such as "exists", "header", or "vacation"
   [VACATION] that examine header fields MUST examine the current state
   of a header as modified by any actions that have taken place so far.

ヘッダーフィールドを調べる「存在」、「ヘッダー」、または「休暇」[VACATION]などのテストと動作は変更されるとしての今までのところ行われたどんな動作によるヘッダーの現状も調べなければなりません。

   As an example, the "header" test in the following fragment will
   always evaluate to true, regardless of whether or not the incoming
   message contained an "X-Hello" header field:

例、以下の断片におけるテストがいつも入来が含まれた状態で通信するかどうかにかかわらず本当に評価する「ヘッダー」、「X、-、こんにちは、」 ヘッダーフィールド:

      addheader "X-Hello" "World";
      if header :contains "X-Hello" "World"
      {
              fileinto "international";
      }

addheader、「X、-、こんにちは、」 「世界的に」。 ヘッダー:containsである、「X、-、こんにちは、」 「世界」fileinto「国際的」。

   However, if the presence or value of a header field affects how the
   implementation parses or decodes other parts of the message, then,
   for the purposes of that parsing or decoding, the implementation MAY
   ignore some or all changes made to those header fields.  For example,
   in an implementation that supports the [BODY] extension, "body" tests
   may be unaffected by deleting or adding "Content-Type" or "Content-
   Transfer-Encoding" header fields.  This does not rescind the
   requirement that changes to those header fields affect direct tests;
   only the semantic side effects of changes to the fields may be
   ignored.

しかしながら、ヘッダーフィールドの存在か値が実現がメッセージの他の部分を分析するか、またはどう解読するかに影響するなら、そして、それが分析するか、または解読する目的のために、実現はそれらのヘッダーフィールドにされたいくつかかすべての変更を無視するかもしれません。 例えば、[BODY]拡大を支持する実現では、「ボディー」テストは、「コンテントタイプ」か「内容転送コード化」ヘッダーフィールドを削除するか、または加えることによって、影響を受けないかもしれません。 これはそれらのヘッダーフィールドへの変化がダイレクトテストに影響するという要件を無効にしません。 その分野への変化の意味副作用だけを無視してもよいです。

Degener & Guenther          Standards Track                     [Page 4]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[4ページ]: Editheader拡大2008年8月

   For the purpose of weeding out duplicates, a message modified by
   addheader or deleteheader MUST be considered the same as the original
   message.  For example, in an implementation that obeys the constraint
   in Section 2.10.3 of [SIEVE] and does not deliver the same message to
   a folder more than once, the following code fragment

写しを取り外す目的のために、オリジナルのメッセージであると同じようにaddheaderかdeleteheaderによって変更されたメッセージをみなさなければなりません。 例えば、それは、一度ほど実現では、.3セクション2.10[SIEVE]で規制に従って、同じメッセージをフォルダーに渡しません、以下のコード断片

      keep;
      addheader "X-Flavor" "vanilla";
      keep;

保ってください。 addheader「X-風味」「バニラ」。 保ってください。

   MUST only file one message.  It is up to the implementation to pick
   which of the redundant "fileinto" or "keep" actions is executed, and
   which ones are ignored.

1つのメッセージをファイルするだけでよいです。 それは選ぶ実現まで達しています(余分な"fileinto"か「保ってください」動作について実行されて、無視されます)。

   The "implicit keep" is thought to be executed at the end of the
   script, after the headers have been modified.  (However, a canceled
   "implicit keep" remains canceled.)

ヘッダーが変更された後にスクリプトの終わりで「暗黙の生活費」が実行されると考えられます。 (しかしながら、取り消された「暗黙の生活費」は取り消されたままで残っています。)

8.  IANA Considerations

8. IANA問題

   The following template specifies the IANA registration of the Sieve
   extension specified in this document:

以下のテンプレートは本書では指定されたSieve拡張子のIANA登録を指定します:

   To: iana@iana.org
   Subject: Registration of new Sieve extension

To: iana@iana.org Subject: 新しいSieve拡張子の登録

   Capability name: editheader
   Description:     Adds actions 'addheader' and 'deleteheader' that
                    modify the header of the message being processed
   RFC number:      RFC 5293
   Contact Address: The Sieve discussion list <ietf-mta-filters&imc.org>

能力名: editheader記述: 動作処理されるメッセージのヘッダーを変更する'addheader'と'deleteheader'RFC番号を加えます: RFC5293はアドレスに連絡します: Sieve議論リスト<ietf-mta-フィルタとimc.org>。

9.  Security Considerations

9. セキュリティ問題

   Someone with write access to a user's script storage may use this
   extension to generate headers that a user would otherwise be shielded
   from (e.g., by a gateway Mail Transport Agent (MTA) that removes
   them).

アクセスを書いてください。ユーザが発生させるヘッダーを発生させるのにこの拡張子をユーザのスクリプト格納まで使用するかもしれません。だれか、そうでなければ、盾となられてください(例えば、彼らを取り除くゲートウェイメールTransportエージェント(MTA)で)。

   This is the first Sieve extension to be standardized that allows
   alteration of messages being processed by Sieve engines.  A Sieve
   script that uses Sieve tests defined in [SIEVE], the editheader
   extension, and the redirect action back to the same user can keep
   some state between different invocations of the same script for the
   same message. But note that it would not be possible to introduce an
   infinite loop using any such script, because each iteration adds a
   new Received header field, so email loop prevention described in
   [SMTP] will eventually non deliver the message, and because the

これはSieveエンジンによって処理されるメッセージの変更を許す標準化されるべき最初のSieve拡張子です。 [SIEVE]、editheader拡張子、および再直接の動作後部で同じユーザと定義されたSieveテストを使用するSieveスクリプトは同じメッセージのために同じスクリプトの異なった実施の何らかの状態を間に置くことができます。 そしてしたがって、各繰り返しが新しいReceivedヘッダーフィールドを加えるのでどんなそのようなスクリプトも使用する無限ループを紹介するのが可能でないことに注意するのを除いて、[SMTP]で説明されたメール輪の防止が結局注意する、非、配送、メッセージ。

Degener & Guenther          Standards Track                     [Page 5]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[5ページ]: Editheader拡大2008年8月

   editheader extension is explicitly prohibited to alter or delete
   Received header fields (i.e., it can't interfere with loop
   prevention).

editheader拡張子は、Receivedヘッダーフィールドを変更するか、または削除するために明らかに禁止されています(すなわち、それは輪の防止を妨げることができません)。

   A sieve filter that removes header fields may unwisely destroy
   evidence about the path a message has taken.

ヘッダーフィールドを取り除くふるいのフィルタはあさはかにメッセージが取った経路に関する証拠を無効にするかもしれません。

   Any change in message content may interfere with digital signature
   mechanisms that include the header in the signed material.  For
   example, changes to (or deletion/addition of) header fields included
   in the "SHOULD be included in the signature" list in Section 5.5 of
   [DKIM] can invalidate DKIM signatures.  This also includes DKIM
   signatures that guarantee a header field absence.

メッセージ内容におけるどんな変化もサインされた材料にヘッダーを含んでいるデジタル署名メカニズムを妨げるかもしれません。 例えば、変化、(削除/添加、)、ヘッダーフィールドを含んでいる、「SHOULD、含まれていて、署名では、」 [DKIM]のセクション5.5のリストはDKIM署名を無効にすることができます。 また、これはヘッダーフィールド不在を保証するDKIM署名を含んでいます。

   The editheader extension doesn't directly affect [IMAIL] header field
   signatures generated using [SMIME] or [OPENPGP], because these
   signature schemes include a separate copy of the header fields inside
   the signed message/rfc822 body part.  However, software written to
   detect differences between the inner (signed) copy of header fields
   and the outer (modified by editheader) header fields might be
   affected by changes made by editheader.

editheader拡張子は直接[SMIME]か[OPENPGP]を使用することで発生する[IMAIL]ヘッダーフィールド署名に影響しません、これらの署名計画がサインされたメッセージ/rfc822身体の部分の中にヘッダーフィールドの別々のコピーを含んでいるので。 しかしながら、内側(サインされる)のコピーのヘッダーフィールドと外側(editheaderによって変更される)のヘッダーフィールドの違いを検出するために書かれたソフトウェアはeditheaderによって行われた変更で影響を受けるかもしれません。

   Since normal message delivery adds "Received" header fields and other
   trace fields to the beginning of a message, many such digital
   signature mechanisms are impervious to headers prefixed to a message,
   and will work with "addheader" unless :last is used.

通常のメッセージ配送が「受け取られていている」ヘッダーフィールドと他の跡の分野をメッセージの始まりに加えるので、そのような多くのデジタル署名メカニズムが、メッセージへ前に置かれたヘッダーにおいて不浸透性であり、:lastが使用されていないと、"addheader"で動作するでしょう。

   Any decision mechanism in a user's filter that is based on headers is
   vulnerable to header spoofing.  For example, if the user adds an
   APPROVED header or tag, a malicious sender may add that tag or header
   themselves.  One way to guard against this is to delete or rename any
   such headers or stamps prior to processing the message.

ヘッダーに基づいているユーザのフィルタのどんな決定機構もヘッダースプーフィングに傷つきやすいです。 例えば、ユーザがAPPROVEDヘッダーかタグを加えるなら、悪意がある送付者は自分たちでそのタグかヘッダーを加えるかもしれません。 これに用心する1つの方法は、メッセージを処理する前にどんなそのようなヘッダーやスタンプも削除するか、または改名することです。

10.  Acknowledgments

10. 承認

   Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Arnt
   Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Will Lee, William
   Leibzon, Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall
   Schwartz, Aaron Stone, Nigel Swinson, and Rand Wacker for extensive
   corrections and suggestions.

大規模な修正と提案をエリック・オールマン、サイラスDaboo、マシュー・エルビ、ネッド・フリード、Arnt Gulbrandsen、Kjetil Torgrim Homme、サイモンJosefsson、ウィル・リー、ウィリアムLeibzon、マーク・E.マレット、クリスMarkle、Alexeyメリニコフ、ランドル・シュワルツ、アーロン・ストーン、ナイジェル・スウィンソン、およびRandワッカーをありがとうございます。

Degener & Guenther          Standards Track                     [Page 6]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[6ページ]: Editheader拡大2008年8月

11.  References

11. 参照

11.1.  Normative References

11.1. 引用規格

   [IMAIL]      Resnick, P., Ed., "Internet Message Format", RFC 2822,
                April 2001.

[IMAIL] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [MIME3]      Moore, K., "MIME (Multipurpose Internet Mail Extensions)
                Part Three: Message Header Extensions for Non-ASCII
                Text", RFC 2047, November 1996.

[MIME3]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。

   [MIMEPARAM]  Freed, N. and K. Moore, "MIME Parameter Value and
                Encoded Word Extensions: Character Sets, Languages, and
                Continuations", RFC 2231, November 1997.

解放された[MIMEPARAM]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2231、11月1997日

   [SIEVE]      Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
                Email Filtering Language", RFC 5228, January 2008.

[ふるい] グンサー、P.、エド、T.ショウォーター、エド、「ふるい:」 「言語をフィルターにかけるメール」、RFC5228、2008年1月。

11.2.  Informative References

11.2. 有益な参照

   [BODY]       Degener, J. and P. Guenther, "Sieve Email Filtering:
                Body Extension", RFC 5173, April 2008.

[ボディー] DegenerとJ.とP.グンサー、「以下をフィルターにかけるふるいのメール」 「ボディー拡大」、RFC5173、2008年4月。

   [DKIM]       Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
                J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
                Signatures", RFC 4871, May 2007.

[DKIM] オールマン、E.、カラス、J.、ディラニー、M.、リッベイ、M.、フェントン、J.、およびM.トーマス、「DomainKeysはメール(DKIM)署名を特定しました」、RFC4871、2007年5月。

   [DSN]        Moore, K. and G. Vaudreuil, "An Extensible Message
                Format for Delivery Status Notifications", RFC 3464,
                January 2003.

[DSN] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。

   [MDN]        Hansen, T., Ed., and G. Vaudreuil, Ed., "Message
                Disposition Notification", RFC 3798, May 2004.

[MDN]ハンセン、T.、エド、G.ボードルイ、エド、「メッセージ気質通知」、RFC3798、5月2004日

   [OPENPGP]    Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
                "MIME Security with OpenPGP", RFC 3156, August 2001.

2001年8月の[OPENPGP]エルキンズとM.とデルTortoとD.とレヴィエン、R.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」RFC3156。

   [SMIME]      Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
                Extensions (S/MIME) Version 3.1 Message Specification",
                RFC 3851, July 2004.

[SMIME] Ramsdell、B.、エド、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1は仕様を通信する」RFC3851、7月2004日

   [SMTP]       Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
                2821, April 2001.

[SMTP] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日

Degener & Guenther          Standards Track                     [Page 7]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[7ページ]: Editheader拡大2008年8月

   [VACATION]   Showalter, T. and N. Freed, Ed., "Sieve Email Filtering:
                Vacation Extension", RFC 5230, January 2008.

[休暇] ショウォーターとT.と解放されたN.、エド、「以下をフィルターにかけるふるいのメール」 「休暇延期」、RFC5230、2008年1月。

Authors' Addresses

作者のアドレス

   Jutta Degener
   5245 College Ave, Suite #127
   Oakland, CA 94618

ユッタDegener5245大学Ave、スイート#127オークランド、カリフォルニア 94618

   EMail: jutta@pobox.com

メール: jutta@pobox.com

   Philip Guenther
   Sendmail, Inc.
   6475 Christie Ave., Ste 350
   Emeryville, CA 94608

フィリップグンサーセンドメールInc.6475クリスティAve、エマリービル、Ste350カリフォルニア 94608

   EMail: guenther@sendmail.com

メール: guenther@sendmail.com

Degener & Guenther          Standards Track                     [Page 8]

RFC 5293      Sieve Email Filtering: Editheader Extension    August 2008

DegenerとグンサーStandardsはRFC5293ふるいのメールフィルタリングを追跡します[8ページ]: Editheader拡大2008年8月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Degener & Guenther          Standards Track                     [Page 9]

Degenerとグンサー標準化過程[9ページ]