RFC 3894 - Sieve Extension: Copying Without Side Effects 日本語訳

URL : https://tools.ietf.org/html/rfc3894
タイトル : RFC 3894 - ふるい拡張子：副作用なしのコピー
翻訳編集 : 自動生成

Network Working Group                                         J. Degener
Request for Comments: 3894                                Sendmail, Inc.
Category: Standards Track                                   October 2004

             Sieve Extension: Copying Without Side Effects

Status of this Memo

このメモの位置付け

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

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2004）。

Abstract

抽象

The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior.

Sieveスクリプト言語は、ユーザーが受信した電子メールの取り扱いや処分を制御することができます。デフォルトでは、Sieveスクリプトによって処理される電子メールメッセージは、所有者の「受信トレイ」に保存されます。こうした「のfileinto」と、このデフォルトの動作をキャンセルする「リダイレクト」などのアクション。

This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script.

ふるい「のfileinto」と「リダイレクト」アクションで使用する、「コピー」この文書は、新しいキーワードパラメータを定義します。追加「：コピーを」アクションには、デフォルトの「受信トレイ」保存の取り消しを抑制することができます。これにより、ユーザーは、スクリプトの残りの部分の意味を変更することなく、既存のスクリプトにコマンドを追加することができます。

1. Introduction

1. はじめに

The Sieve scripting language [SIEVE] allows users to control handling and disposal of their incoming e-mail. Two frequently used Sieve commands are "fileinto" (saving into a local message store, such as an IMAP server) and "redirect" (forwarding to another e-mail address). Both of these cancel the Sieve default behavior of saving into the user's "inbox".

Sieveスクリプト言語[SIEVE]は、ユーザーが受信した電子メールの取り扱いや処分を制御することができます。二つの頻繁に使用されるふるいのコマンドは、（例えば、IMAPサーバとしてローカルメッセージストアに保存）「のfileinto」であり、（別の電子メールアドレスに転送する）「リダイレクトします」。これらの両方は、ユーザの「受信トレイ」に保存のふるいデフォルト動作をキャンセルします。

But some users have the notion of forwarding an extra copy of a message for safekeeping to another e-mail address, or of saving a copy in a folder - in addition to the regular message delivery, which shouldn't be affected by the copy.

しかし、一部のユーザーは、別の電子メールアドレスへの保管のため、またはフォルダにコピーを保存するメッセージの余分なコピーを転送するという概念を持っている - コピーによって影響されるべきではない通常のメッセージの配信に加えて。

If saving an extra copy is all the user wanted to do,

余分なコピーを保存する場合は、すべてのユーザーがやってみたかったです、

      fileinto "unfiltered";
      keep;

would do the job. The "keep" command does explicitly what the cancelled default behavior did. But the explicit "keep" is a poor substitute for the implicit "keep" when more processing follows:

仕事をするだろう。「キープ」コマンドがキャンセルされ、デフォルトの動作が何をしたか、明示的に行います。しかし、「続ける」明示的には、より多くの処理が続く場合、「続ける」暗黙のための貧しい人々の代替は、次のとおりです。

      fileinto "unfiltered";
      keep;

if header "Subject" "MAKE MONEY FAST!!!" { discard; }

FASTお金を稼ぐ「ヘッダ「件名」であれば!!!」 {廃棄; }

In this example, the "discard" is ineffective against the explicit "keep"; the discarded message still ends up in the user's inbox.

この例では、「廃棄」「保つ」明示に対しては無効です。廃棄されたメッセージはまだ、ユーザーの受信トレイに終わります。

It is possible to generate Sieve code that perfectly expresses a user's wishes, but such code quickly grows unwieldy because it needs to keep track of the state that the implicit "keep" would have had without the "fileinto" or "redirect" command.

完全にユーザーの希望を表現ふるいコードを生成することが可能であるが、それは暗黙的には「のfileinto」せずに持っていたでしょうか、コマンドを「リダイレクト」「保つ」という状態を追跡する必要があるため、このようなコードがすぐに手に負えなく成長します。

This extension tries to make life easier for user interface designers and script writers by allowing them to express the "copy" semantics directly.

この拡張は、彼らが直接「コピー」の意味を表現できるようにすることで、ユーザーインターフェースの設計者やスクリプト作成者のための生活を楽にしようとします。

2. Conventions used

2.表記を使用します

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

アクションの定義のためのラベルと引数の構文をタグ付け：「構文」の表記の規則は、[キーワード]との使用を含むセクション1.1、[SIEVE]のようにしています。

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

この文書で定義された拡張子に関連付けられた機能の文字列は、「コピー」です。

3. ":copy" extension to the "fileinto" and "redirect" commands

3.「：コピー」「のfileinto」の拡張機能とコマンドを「リダイレクト」

Syntax: "fileinto" [":copy"] <folder: string> "redirect" [":copy"] <address: string>

構文： "のfileinto" [ "：コピー" <フォルダ：文字列> [ "：コピーを"] "リダイレクト" <住所：文字列>

If the optional ":copy" keyword is specified with "fileinto" or "redirect", the tagged command does not cancel the implicit "keep". Instead, it merely files or redirects a copy in addition to whatever else is happening to the message.

「：コピー」オプションの場合はキーワードが「のfileinto」または「リダイレクト」と指定され、タグ付きコマンドが暗黙の「キープ」キャンセルされません。代わりに、それは単にファイルやメッセージに起こっている任意の他に加えて、コピーをリダイレクトします。

Example:

例：

      require ["copy", "fileinto"];
      fileinto :copy "incoming";

# ... more processing follows ...

＃...より多くの処理は、次の...

4. Security Considerations

4.セキュリティについての考慮事項

The "copy" extension makes it easier to eavesdrop on a user's message stream without the user noticing. This was technically possible before if an attacker gained read/write access to a user's Sieve scripts, but now an attacker no longer needs to parse a script in order to modify it. Write access to Sieve scripts must be protected as strongly as read/write access to e-mail, for example by using secure directory protocols such as correctly parameterized LDAP over TLS [LDAP].

「コピー」の拡張は、簡単にユーザーの気付かず、ユーザーのメッセージストリームを盗聴することができます。攻撃者は、ユーザーのSieveスクリプトへの読み取り/書き込みアクセス権を得た場合、これは前に技術的に可能ではなかったが、今、攻撃者は、もはやそれを修正するためにスクリプトを解析する必要があります。 Sieveスクリプトへのアクセスを書くようにTLS [LDAP]の上に正しくパラメータ化LDAPディレクトリなどのセキュア・プロトコルを使用することにより、たとえば、として強く、電子メールへの読み取り/書き込みアクセスとして保護されなければなりません。

Organizations that wish to monitor their users' e-mail traffic must familiarize themselves with local data protection laws before creating stores of old e-mail traffic without control, or perhaps even knowledge, of the sender or intended recipients.

そのユーザーの電子メールトラフィックを監視する組織は、制御なしで古い電子メールトラフィックのストアを作成する前に、ローカルのデータ保護法に慣れる、または送信者や受信者のおそらく知識、しなければなりません。

Organizations that legally use "redirect :copy" to eavesdrop on correspondence (for example, by keeping a log to answer questions about insider trading at a later time) can avoid future problems by setting users' privacy expectations correctly.

正しくユーザーのプライバシーの期待を設定することにより、将来の問題を避けることができる（例えば、後の時点で、インサイダー取引についての質問に答えるために、ログを保つことによって）対応を盗聴する：合法的に「コピーをリダイレクトする」使用する組織。

5. IANA Considerations

5. IANAの考慮事項

The following template specifies the IANA registration of the "copy" Sieve extension specified in this document.

次のテンプレートは、この文書で指定された「コピー」ふるい拡張のIANA登録を指定します。

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

To：iana@iana.org件名：新しいふるい拡張の登録

Capability name: copy Capability keyword: copy Capability arguments: N/A Standards Track: RFC 3894 Person and email address to contact for further information:

能力名：コピー能力キーワード：コピー能力の引数：N / A標準化過程：詳細のために連絡するRFC 3894人とEメールアドレス：

Jutta Degener Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608

ユッタ・デッジナーのSendmail社6425クリスティアベニュー、4階エメリービル、CA 94608

Email: jutta@sendmail.com

メール：jutta@sendmail.com

This information has been added to the list of Sieve extensions given on http://www.iana.org/assignments/sieve-extensions.

この情報はhttp://www.iana.org/assignments/sieve-extensionsに与えられたふるい拡張子のリストに追加されました。

6. Acknowledgments

6.謝辞

Thanks to Eric Allman, Ned Freed, Will Lee, Nigel Swinson, and Rand Wacker for corrections and comments.

修正とコメントのエリック・オールマン、ネッドフリード、ウィル・リー、ナイジェルSwinson、およびランドワッカーに感謝します。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

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

[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.

[SIEVE]ショーウォルター監督、T.、 "ふるい：メールフィルタ言語"、RFC 3028、2001年1月。

7.2. Informative References

7.2. 参考文献

[LDAP] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.

[LDAP]ワール、M.、Alvestrand、H.、ホッジス、J.、およびR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年5月。

Author's Address

著者のアドレス

Jutta Degener Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608

ユッタ・デッジナーのSendmail社6425クリスティアベニュー、4階エメリービル、CA 94608

EMail: jutta@sendmail.com

メールアドレス：jutta@sendmail.com

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2004）。

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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.

この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。

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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。

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リポジトリから。

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に情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。