Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6558 Isode Limited
Category: Standards Track B. Leiba
ISSN: 2070-1721 K. Li
Huawei Technologies
March 2012
Sieve Extension for Converting Messages before Delivery
Abstract
抽象
This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery.
この文書では、「CONVERT」IMAP拡張が最終的な配信の前にメッセージを変換するためにふるいメールフィルタ言語内で使用することができる方法を説明します。
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/rfc6558.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6558で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 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 ....................................................2
1.1. Conventions Used in This Document ..........................2
2. "convert" Action ................................................2
2.1. Interaction with Other Tests and Actions ...................3
2.2. "convert" as a Test ........................................4
3. Examples ........................................................5
3.1. Example 1 ..................................................5
3.2. Example 2 ..................................................5
3.3. Example 3 ..................................................5
3.4. Example 4 ..................................................6
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. Acknowledgements ................................................7
7. Normative References ............................................7
The IMAP "CONVERT" extension [RFC5259] adds an IMAP command for performing client-controlled conversions on whole messages or their body parts. This document defines a similar extension to the Sieve mail filtering language [RFC5228], which reuses the conversion parameters and framework established by IMAP CONVERT.
IMAP「CONVERT」拡張[RFC5259]は、全体のメッセージや自分の体の部分にクライアント制御の変換を実行するためのIMAPコマンドが追加されます。この文書は、IMAP CONVERTによって確立された変換パラメータとフレームワークを再利用ふるいメールフィルタリング言語[RFC5228]と同様の拡張を定義します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Conventions for notations are as in Sieve [RFC5228], Section 1.1.
表記の規則は、ふるい[RFC5228]、セクション1.1のようにしています。
Usage: convert <quoted-from-media-type: string> <quoted-to-media-type: string> <transcoding-params: string-list>
使用方法：変換<引用し-からメディア型：文字列> <引用さ・ツー・メディア・タイプ：文字列> <トランスコーディング-のparams：文字列のリスト>
The "convert" action specifies that all body parts with a media type [RFC2046] (sometimes called "MIME type") equal to <quoted-from-media-type> be converted to the media type in <quoted-to-media-type> using conversion parameters specified in <transcoding-params>. Each conversion parameter value has the following syntax: "<transcoding-param-name>=<transcoding-param-value>", where <transcoding-param-name> and <transcoding-param-value> are defined in CONVERT [RFC5259]. Messages that don't have any body parts with the <quoted-from-media-type> media type are not affected by the conversion.
「変換」アクションが指定する<引用-からメディアタイプ> <内のメディアタイプに変換することに等しいメディアタイプ[RFC2046]（とも呼ばれる「MIMEタイプ」）を持つすべての身体部分引用ツーする、メディア<トランス-paramsは>で指定された変換パラメータを用いて、タイプ>。各変換パラメータ値は、以下の構文を有する： "<トランス-PARAM名> = <トランス-PARAM値>"、<トランス-PARAM-name>と<トランスコーディング-PARAM値が> CONVERTで定義される[RFC5259] 。 <引用し-からメディアタイプ>メディアタイプを持つ任意の体の部分を持っていないメッセージは、変換の影響を受けません。
The "convert" action can be used with Sieve MIME Part Tests [RFC5703], in the case that some, but not all of the body parts need to be converted, or where different body parts might require different conversions. When the "convert" action appears in a "foreverypart" loop, it applies only to the body part being processed, and not to any other body parts (see Section 3.2 for an example).
「変換」アクションは、いくつかのケースでは、ふるいMIMEパート試験[RFC5703]で使用することができ、すべてではない体の部分のは、変換する必要があり、または異なる体の部分が異なる変換を必要とするかもしれないところ。 「変換」アクション「がforeverypart」ループに表示されたら、それは身体の一部にのみ適用され処理されている、といない任意の他の身体部分に（例えば、セクション3.2を参照してください）。
When the "convert" action appears outside a "foreverypart" loop, the conversion applies equally to all body parts -- that is, all body parts that have the "quoted-from-media-type" are converted, using the same transcoding parameters.
つまり、「引用され-からメディア型」と同じ変換パラメータを使用して、変換されているすべてのボディパーツ - 「変換」アクション「がforeverypart」ループの外に表示された場合、変換はすべての身体の部分にも同様に適用されます。
A single "convert" action will only apply once to any body part. If, for example, << convert "image/jpeg" "image/jpeg" ["pix-x=100","pix-y=120"] >> converts a larger JPEG image to the smaller 100 x 120 size, that will be the end of that "convert" action on that body part. The action will not see a "new" JPEG body part to process, resulting from the conversion.
シングル「変換」アクションが唯一の任意の身体の一部に一度適用されます。例えば、<< "画像/ JPEG"、 "画像/ JPEG変換する場合、" [ "PIX-X = 100"、 "PIX-Y = 120"] >>小さな100×120のサイズに大きなJPEG画像を変換し、それは、その身体の部分でその「変換」アクションの終わりになるでしょう。アクションは、変換の結果、プロセスに「新しい」JPEGの身体の部分は表示されません。
If a "convert" action cannot be completed -- perhaps because the conversion failed, or because the requested conversion is not available -- that "convert" action MUST terminate and leave the message unchanged, rolling back any other conversions done by that action. The script processing continues, and prior or subsequent "convert" actions are not affected. No error condition is raised, and no partial conversions from a single "convert" action are allowed.
「変換」アクションを完了できない場合 - おそらく変換が失敗したため、または要求された変換が利用できないため、 - その「変換」アクションが終了し、戻って、そのアクションによって行われ、他の変換を転がり、そのままメッセージを残しておく必要があります。スクリプトの処理は続行され、前または後「変換」アクションは影響を受けません。いいえエラー状態が発生しません、そしてシングル「変換」アクションからの部分的な変換は許可されません。
Implementations might defer any actual conversion until the results of the conversion are needed for script processing, to avoid doing conversions unnecessarily. Consider the case wherein a "convert" action is processed but a "discard" action results without the need to actually perform the conversion.
変換の結果は、スクリプト処理のために必要とされるまで、実装は、不必要な変換を行うことを避けるために、任意の実際の変換を延期する可能性があります。 「変換」アクションが処理されるが、実際に変換を実行することなく、アクションの結果を「破棄」する場合を考えてみましょう。
When conversions actually need to be done, they can put a significant load on the server. Computationally expensive conversions of a lot of body parts can constitute an attack vector; even if done legitimately, they can create an unacceptable load. Servers MAY refuse conversions, or do them at lower priority, effectively slowing the requesting process in order to avoid negative effects on service to other processes.
変換が実際に行われる必要があるとき、彼らは、サーバー上の大きな負荷をかけることができます。体の部分の多くの計算コストの高い変換が攻撃ベクトルを構成することができます。合法的に行われていても、彼らは容認できない負荷を作成することができます。サーバは変換を拒否し、または効果的に他のプロセスへのサービスにマイナスの影響を回避するために、要求プロセスを遅く、低い優先順位でそれらを行うことができます。
Whether or not the actual conversion has been done yet, a successful "convert" action effectively changes the message, and all subsequent actions, including any other "convert" actions, apply to the changed message. The "convert" action does not affect the applicability of other actions; any action that was applicable before the "convert" is equally applicable to the changed message afterward.
実際の変換がまだ行われているかどうかにかかわらず、成功した「変換」アクションが効果的にメッセージを変更し、他の「変換」アクションを含む、すべての後続のアクションは、変更されたメッセージに適用されます。 「変換」アクションは他のアクションの適用可能性には影響を与えません。 「変換」の前に適用されたすべてのアクションが、その後変更されたメッセージにも同様に適用可能です。
When a disposition-type action, such as "fileinto" or "redirect", is encountered, the state of the message with respect to conversions is "locked in" for that disposition-type action. Whether the implementation performs the action at that point or batches it for later, it MUST perform the action on the message as it stood at the time, and MUST NOT include subsequent conversions encountered later in the script processing. Therefore, the sequence "convert, fileinto, convert, fileinto" will store two different versions of the message: the first "fileinto" uses only the first conversion, while the second uses both. See Section 3.4 for an example of how this can be used.
そのような「のfileinto」または「リダイレクト」として配置型のアクションが、検出されたとき、コンバージョンに対するメッセージの状態は、その気質型アクションの「固定」されます。実装は、その時点以降のためのバッチをでアクションを実行するかどうか、それが一度に立ったメッセージに対してアクションを実行しなければなりません、及びスクリプト処理の後半で遭遇する後続の変換を含んではいけません。第二の両方を使用しながら、第一「のfileinto」最初の変換を使用する。したがって、配列は、2つのメッセージの異なるバージョンを保存します「のfileinto、変換、のfileinto変換します」。これを使用する方法の例については、セクション3.4を参照してください。
In addition, any tests done on the message and its parts will test the message after prior conversions have been done. The fourth block of Section 3.4 shows an example of this situation.
また、メッセージとその部分で行わ任意の試験前変換が行われた後にメッセージをテストします。 3.4節の第4ブロックは、このような状況の一例を示しています。
Convert actions are cumulative, and each conversion operates on the message as it stands after all prior conversions. See the fourth block of Section 3.4 for an example of how this might be tricky.
変換の操作は累積され、そしてそれはすべての前の変換の後に立っているとして、各変換は、メッセージ上で動作します。これは難しいことかもしれない方法の例については、3.4節の4番目のブロックを参照してください。
Because the implicit keep (see Section 2.10.2 of [RFC5228]), if it is in effect, acts on the final state of the message, all conversions are performed before any implicit keep.
それが有効である場合、暗黙的なキープは（[RFC5228]のセクション2.10.2を参照）、メッセージの最終状態に作用するため、すべての変換は、任意の暗黙のキープ前に実行されます。
To simplify testing for supported and successful conversions, the "convert" action can also be used as a test. As such, it will attempt to perform the requested conversion(s) and will evaluate to "false" if and only if at least one conversion failed. The failure can be because a conversion was unsupported or because the data could not be converted (perhaps it had been corrupted in transit or mislabeled at its origin).
サポートされており、成功した変換のためのテストを簡素化するために、「変換」アクションは、テストとして使用することができます。このように、それは要求された変換（複数可）を実行しようとすると、少なくとも一つの変換が失敗した場合にのみ、「偽」と評価されます。変換がサポートされていないだったので、データは（おそらくそれは、輸送中に破損しているか、その原点に誤表示されていた）に変換することができなかったので、失敗はすることができます。
This creates a new type of Sieve action, a "testable action". The usage as a test is exactly the same as for an action, and it doubles as an action and a test of the action's result at the same time. See Section 3.2 for an example of how this test can be used.
これは、Sieveアクション、「テスト可能なアクション」の新しいタイプを作成します。テストとしての使用は、アクションのと全く同じであり、それは同時に、アクション、アクションの結果のテストも兼ねています。このテストを使用する方法の例については、セクション3.2を参照してください。
Note that defining this new testable action does not change the definitions of any other actions -- it does not imply that other actions can be used as tests. Future extensions might define other testable actions, but those specifications would be responsible for clearly specifying that.
この新しいテスト可能なアクションを定義することは、他のアクションの定義を変更しないことに注意してください - それは他のアクションをテストとして使用することができることを意味するものではありません。将来の拡張機能は、他のテスト可能なアクションを定義することがありますが、これらの仕様は明らかにそれを指定するための責任を負うことになります。
In the following example, all "image/tiff" body parts of the message are converted to "image/jpeg" with image resolution of 320x240 pixels. The converted message is then subject to the implicit keep.
次の例では、メッセージのすべての「画像/ TIFF」身体の部分は、320×240ピクセルの画像解像度を有する「画像/ JPEG」に変換されます。変換されたメッセージは、暗黙のキープの対象となります。
require ["convert"];
convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"];
In the following example, all "image/tiff" body parts of the message are converted to "image/jpeg", as in Example 1. If the conversions were successful, those messages are then filed into a mailbox called "INBOX.pics". Other messages (those with no image/tiff body parts) are subject to the implicit keep, and have not been converted.
以下の例では、すべてが「画像/ TIFF」メッセージのボディ部は、変換が成功した場合、これらのメッセージは、次に「INBOX.pics」と呼ばれるメールボックスに提出され、実施例1と同様に、「画像/ JPEG」に変換され。他のメッセージ（NO画像/ TIFF本体部分を有するもの）は、暗黙的な維持するために被験体であり、変換されていません。
require ["mime", "fileinto", "convert"];
if header :mime :anychild :contenttype
"Content-Type" "image/tiff"
{
if (convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"])
{
fileinto "INBOX.pics";
}
}
In the following example, only "image/tiff" body parts with a Content-Disposition of "inline" are converted. Matching parts that are larger than 500 kilobytes are converted using an image resolution of 640x480 pixels, and those smaller are converted to 320x240 pixels. The message disposition is not changed, so the implicit keep will be in effect unless something else in the script changes that.
次の例では、「インライン」のコンテンツの廃棄を持つ唯一の「画像/ TIFF」身体部分が変換されます。 500キロバイトより大きい一致する部分は640×480ピクセルの画像解像度を使用して変換され、それらの小さなは、320×240ピクセルに変換されます。スクリプト内の何か他のものはそれを変更しない限り、暗黙のキープが有効になりますので、メッセージの配置は、変更されません。
require ["mime", "foreverypart", "fileinto", "convert"];
foreverypart
{
if header :mime :param "filename" :contains
"Content-Disposition" "inline"
{
if size :over "500K"
{
convert "image/tiff" "image/jpeg" ["pix-x=640","pix-y=480"];
} else {
convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"]; } } }
"画像/ TIFF"、 "画像/ JPEGは、" [ "PIX-X = 320"、 "PIX-Y = 240"]に変換; }}}
[... script continues ...]
[...スクリプトが続きます...]
The following example shows some tricky interactions between multiple "convert" actions and other disposition-type actions.
次の例では、複数の「変換」アクションと他の配置型のアクション間のいくつかのトリッキーな相互作用を示しています。
require ["mime", "foreverypart",
"fileinto", "redirect", "convert"];
# The first "if" block will convert all image/tiff body parts
# to 640x480 jpegs and will file the message
# into the "INBOX.pics" mailbox as converted at this point.
if header :mime :anychild :contenttype
"Content-Type" "image/tiff"
{
convert "image/tiff" "image/jpeg" ["pix-x=640","pix-y=480"];
fileinto "INBOX.pics";
}
# The second block, the "foreverypart" loop, will convert all # inline jpegs to 320x240 resolution... including any tiff body # parts that had been converted in the first block, above. # Therefore, any tiff that had been converted to a 640x480 jpeg # will be re-converted to a 320x240 jpeg here if its # Content-Disposition is specified as "inline". foreverypart { if header :mime :param "filename" :contains "Content-Disposition" "inline" { convert "image/jpeg" "image/jpeg" ["pix-x=320","pix-y=240"]; } }
＃第二ブロック、「foreverypart」ループは、上記第一のブロックに変換された任意のTIFF体位の部分を含む... 320×240の解像度にすべて＃インラインJPEGファイルに変換されます。その＃のContent-処分の「インライン」として指定されている場合＃したがって、640×480のJPEG＃に変換された任意のいさかいは、ここでは320×240のJPEGに再変換されます。 foreverypartヘッダ場合{：MIME：PARAM "ファイル名が"： "コンテンツの廃棄" "インラインを含む画像/ JPEG"、 "画像/ JPEGは" [ "PIX-X = 320"、 "PIX-Y = 240"] "{変換" ; }}
# The third block will take any message that contains a header # field called "Mobile-Link" and redirect it to the user's # mobile address. The redirected message will include both # conversions above, from block one and block two. if exists "Mobile-Link" { redirect "joe@mobile.example.com"; }
＃3番目のブロックは、「モバイルリンク」と呼ばれるヘッダ＃フィールドが含まれている任意のメッセージを取得し、ユーザーの＃携帯のアドレスにリダイレクトされます。リダイレクトされたメッセージは、ブロック1から、上記の両方＃変換を含む二つをブロックします。 「モバイル・リンク」が存在する場合は{「joe@mobile.example.com」リダイレクトします。 }
# The fourth block will file the message into "Tiff" if it # contains any tiff body parts. But because of the earlier # conversion (in the first block), there will never be any # tiff body parts, so this "fileinto" will never happen. if header :mime :anychild :contenttype "Content-Type" "image/tiff" { fileinto "Tiff"; }
それは＃任意のTIFFの体の部分が含まれている場合＃第4ブロックには、「ティフ」にメッセージを提出します。しかし、（最初のブロックで）以前の＃変換のために、任意の＃のTIFF体の部分があることはありませんので、この「のfileinto」は決して起こらないだろう。ヘッダ場合：MIME：anychild： "Tiffを "{のfileinto" のContentType "コンテンツタイプ"" 画像/ TIFF。 }
# Now, at the end of the script processing, the Sieve # processor will perform an implicit keep if none of # the "fileinto" and "redirect" actions were taken. # The kept message will include any conversions that # were done (that is, any from the second block).
＃今、スクリプト処理の最後に、ふるい＃プロセッサは、＃「のfileinto」と「リダイレクト」アクションのどれも取られなかった場合は、暗黙的な維持実行されます。 ＃維持メッセージ（すなわち、第二のブロックからのいずれかである）＃が行われた任意の変換を含むであろう。
Security considerations given in IMAP CONVERT [RFC5259] and Sieve [RFC5228] are relevant to this document. There are no additional security considerations resulting from combining the two.
IMAPのCONVERT [RFC5259]とふるい[RFC5228]で与えられたセキュリティ上の考慮事項は、この文書に関連しています。 2を組み合わせることにより生じる追加のセキュリティ上の考慮事項はありません。
IANA has added the following registration to the "Sieve Extensions" registry, as defined in RFC 5228:
RFC 5228で定義されているIANAは、「ふるい拡張機能」のレジストリに以下の登録を追加しました：
Capability name: convert Description: adds a new Sieve test and action that enable Sieve scripts to perform data conversions on the message being delivered. RFC number: RFC 6558 Contact address: The Sieve discussion list <sieve@ietf.org>
能力名：変換説明：配信されるメッセージのデータ変換を実行するためにSieveスクリプトを有効にする新しいふるいテストとアクションを追加します。 RFC番号：RFC 6558連絡先アドレス：ふるいディスカッションリスト<sieve@ietf.org>
The authors also want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of CONVERT.
著者らはまた、主要な洞察力を貢献し、広く概説およびCONVERTの概念を議論してきたすべての人に感謝したいと思います。
Qian Sun contributed text to this document.
銭Sunは、この文書にテキストを貢献しました。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[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月。
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]ギュンター、P.およびT.ショーウォルター監督、 "ふるい：メールフィルタリング言語"、RFC 5228、2008年1月。
[RFC5259] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[RFC5259]メルニコフ、A.、およびP.コーツ、 "インターネットメッセージアクセスプロトコル - 拡張CONVERT"、RFC 5259、2008年7月。
[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 URI: http://www.melnikov.ca/
電子メール：Alexey.Melnikov@isode.com URI：http://www.melnikov.ca/
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/
Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P. R. China
ベース、禁止の日、長い剛性地区が真であるとしてKE鵬リットルIH UAは518129 P. R.中国、GUビルGケース技術HU Aです
Phone: +86-755-28974289 EMail: likepeng@huawei.com
電話：+ 86-755-28974289電子メール：likepeng@huawei.com