[要約] RFC 3894は、Sieve拡張機能である「Copying Without Side Effects」についての要約と目的を提供しています。このRFCの目的は、Sieveスクリプトでのメッセージのコピー操作を行う際に、副作用を最小限に抑えることです。

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)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004).

著作権(c)The Internet Society(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 Scripting Languageを使用すると、ユーザーは着信電子メールの取り扱いと廃棄を制御できます。デフォルトでは、ふるいスクリプトによって処理される電子メールメッセージが所有者の「受信トレイ」に保存されます。「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 Scripting Language [Sieve]を使用すると、ユーザーは着信電子メールの取り扱いと廃棄を制御できます。頻繁に使用される2つのシーブコマンドは、「FileInto」(IMAPサーバーなどのローカルメッセージストアに保存)と「リダイレクト」(別の電子メールアドレスへの転送)です。これらはどちらも、ユーザーの「受信トレイ」に保存するSiveデフォルトの動作をキャンセルします。

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;

fileinto "filtered";保つ;

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:

仕事をするでしょう。「Keep」コマンドは、キャンセルされたデフォルトの動作が行ったことを明示的に行います。しかし、明示的な「キープ」は、より多くの処理が続く場合、暗黙の「キープ」の貧弱な代替品です。

fileinto "unfiltered"; keep;

fileinto "filtered";保つ;

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

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.

ユーザーの希望を完全に表現するふるいコードを生成することは可能ですが、そのようなコードは、暗黙の「Keep」には「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.

表記の規則は、[キーワード]および「syntax:」の使用を含む[sieve]セクション1.1のように、アクションの定義とタグ付けされた引数構文を含む。

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>
        

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.

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

Example:

例:

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

["copy"、 "fileinto"]が必要です。fileinto:「受信」をコピーします。

# ... 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スクリプトへの書き込みアクセスは、たとえば、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

宛先: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人とメールアドレスへの連絡先の詳細については:

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

Jutta Degener Sendmail、Inc。6425 Christie Ave、4th Floor Emeryville、CA 94608

      Email: 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.

エリック・オールマン、ネッド・フリード、ウィル・リー、ナイジェル・スウィンソン、ランド・ワッカーに感謝します。

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.

[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[Sieve] Showalter、T。、「Sieve:A Mail Filtering Language」、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] Wahl、M.、Alvestrand、H.、Hodges、J。、およびR. Morgan、「LDAPの認証方法」、RFC 2829、2000年5月。

Author's Address

著者の連絡先

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

Jutta Degener Sendmail、Inc。6425 Christie Ave、4th Floor Emeryville、CA 94608

   EMail: jutta@sendmail.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004).

著作権(c)The Internet Society(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.

このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織(もしあれば)が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。