[要約] RFC 3598は、Sieveメールフィルタリングのサブアドレス拡張に関するものであり、要約すると以下のようになります: 1. サブアドレスを使用してメールアドレスを拡張するための標準化された方法を提供する。 2. メールフィルタリングの効率を向上させ、メールの整理やルーティングを容易にする。 3. サブアドレスの使用に関する一貫性と互換性を確保するためのガイドラインを提供する。

Network Working Group                                       K. Murchison
Request for Comments: 3598                            Oceana Matrix Ltd.
Category: Standards Track                                 September 2003
        

Sieve Email Filtering -- Subaddress Extension

シーブメールフィルタリング - サブアドレス拡張機能

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 (2003). All Rights Reserved.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

Abstract

概要

On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address.

「サブアドレス」または「詳細なアドレス指定」を可能にする電子メールシステム(例:「ken sieve@example.org」)では、これらのアドレスのサブパートと比較することが望ましい場合があります。このドキュメントでは、ユーザーがユーザーと比較し、アドレスの詳細部分と比較できるようにするSieve Mailフィルタリング言語の拡張機能を定義します。

Table of Contents

目次

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Capability Identifier . . . . . . . . . . . . . . . . . . . .   2
   3.  Subaddress Comparisons. . . . . . . . . . . . . . . . . . . .   2
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References. . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Intellectual Property Statement . . . . . . . . . . . . . . .   5
   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .   5
   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .   6
        
1. Introduction
1. はじめに

Subaddressing is the practice of appending some "detail" information to the local-part of an [IMAIL] address to indicate that the message should be delivered to the mailbox specified by the "detail" information. The "detail" information is prefixed with a special "separator character" (typically "+") which forms the boundary between the "user" (original local-part) and the "detail" sub-parts of the address, much like the "@" character forms the boundary between the local-part and domain.

サブアドレスは、「詳細」情報で指定されたメールボックスにメッセージを配信する必要があることを示すために、[imail]アドレスのローカルパートに「詳細」情報を追加する慣行です。「詳細」情報には、「ユーザー」(オリジナルのローカルパート)とアドレスの「詳細」サブパートの境界を形成する特別な「セパレーター文字」(通常は「」)が付いています。@"文字は、ローカルパートとドメインの境界を形成します。

Typical uses of subaddressing might be:

サブアドレスの典型的な用途は次のとおりです。

- A message addressed to "ken+sieve@example.org" is delivered into a mailbox called "sieve" belonging to the user "ken".

- 「ken sieve@example.org」に宛てられたメッセージは、ユーザー「Ken」に属する「Sieve」と呼ばれるメールボックスに配信されます。

- A message addressed to "5551212#123@example.org" is delivered to the voice mailbox number "123" at phone number "5551212".

- 「5551212#123@example.org」に宛てられたメッセージは、電話番号「5551212」でボイスメールボックス番号「123」に配信されます。

This document describes an extension to the Sieve language defined by [SIEVE] for comparing against the "user" and "detail" sub-parts of an address.

このドキュメントでは、アドレスの「ユーザー」と「詳細」サブパートと比較するために[Sieve]によって定義されたSieve言語の拡張機能について説明します。

Conventions for notations are as in [SIEVE] section 1.1, including use of [KEYWORDS].

表記の規則は、[キーワード]の使用を含む[Sieve]セクション1.1のようにあります。

2. Capability Identifier
2. 機能識別子

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

このドキュメントで定義されている拡張機能に関連付けられている機能文字列は「サブアドレス」です。

3. Subaddress Comparisons
3. サブアドレス比較

Commands that act exclusively on addresses may take the optional tagged arguments ":user" and ":detail" to specify what sub-part of the local-part of the address will be acted upon.

アドレスのみで行動するコマンドは、オプションのタグ付けされた引数「:user」と「詳細」を取得して、アドレスのローカルパートのサブパートを指定することができます。

NOTE: In most cases, the envelope "to" address is the preferred address to examine for subaddress information when the desire is to sort messages based on how they were addressed so as to get to a specific recipient. The envelope address is, after all, the reason a given message is being processed by a given sieve script for a given user. This is particularly true when mailing lists, aliases, and "virtual domains" are involved since the envelope may be the only source of detail information for the specific recipient.

注:ほとんどの場合、エンベロープ「To」アドレスは、特定の受信者に到達するためにそれらがどのように対処されたかに基づいてメッセージを並べ替えたい場合に、サブアドレス情報を調べるための優先アドレスです。エンベロープアドレスは、結局のところ、特定のユーザーの特定のふるいスクリプトによって与えられたメッセージが処理されている理由です。これは、封筒が特定の受信者の唯一の詳細情報のソースである可能性があるため、メーリングリスト、エイリアス、および「仮想ドメイン」が関与する場合に特に当てはまります。

The ":user" argument specifies that sub-part of the local-part which lies to the left of the separator character (e.g., "ken" in "ken+sieve@example.org"). If no separator character exists, then ":user" specifies the entire left-side of the address (equivalent to ":localpart").

「:user」引数は、セパレーター文字の左側にあるローカルパートのサブパート(「ken sieve@example.org」の「ken」)を指定します。セパレーター文字が存在しない場合、「:ユーザー」はアドレスの左側全体を指定します(「:localpart」に相当)。

The ":detail" argument specifies that sub-part of the local-part which lies to the right of the separator character (e.g., "sieve" in "ken+sieve@example.org"). If no separator character exists, the test evaluates to false. If nothing lies to the right of the separator character, then ":detail" ":is" the null key (""). Otherwise, the ":detail" sub-part contains the null key.

「:詳細」の引数は、セパレーター文字の右側にあるローカルパートのサブパート(例えば、「ken sieve@example.org」の「ふるい」)を指定します。セパレータ文字が存在しない場合、テストはfalseと評価されます。セパレーター文字の右側にない場合、 ":detail" ":は「null key(" ")です。それ以外の場合、「:詳細」サブパートにはnullキーが含まれています。

Implementations MUST make sure that the separator character matches that which is used and/or allowed by the encompassing mail system, otherwise unexpected results might occur. Implementations SHOULD allow the separator character to be configurable so that they may be used with a variety of mail systems. Note that the mechanisms used to define and/or query the separator character used by the mail system are outside the scope of this document.

実装は、セパレーターの文字が、包括的なメールシステムによって使用および/または許可されているものと一致することを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。実装により、セパレーター文字がさまざまなメールシステムで使用できるように設定可能にする必要があります。メールシステムで使用されるセパレーター文字を定義および/またはクエリするために使用されるメカニズムは、このドキュメントの範囲外であることに注意してください。

The ":user" and ":detail" address parts are subject to the same rules and restrictions as the standard address parts defined in [SIEVE]. For convenience, the "ADDRESS-PART" syntax element defined in [SIEVE] is augmented here as follows:

「:ユーザー」と「詳細」アドレスパーツは、[Sieve]で定義されている標準アドレスパーツと同じルールと制限の対象となります。便利なため、[Sieve]で定義されている「アドレスパート」構文要素は、次のようにここで補強されています。

      ADDRESS-PART  =/  ":user" / ":detail"
        

A diagram showing the ADDRESS-PARTs of a email address utilizing a separator character of '+' is shown below:

「」のセパレーター文字を使用した電子メールアドレスのアドレスパートを示す図を以下に示します。

       :user "+" :detail  "@" :domain
      `-----------------'
          :local-part
        

Example:

例:

require "subaddress";

「サブアドレス」が必要です。

   # File mailing list messages (subscribed as "ken+mta-filters").
   if envelope :detail "to" "mta-filters" {
     fileinto "inbox.ietf-mta-filters";
   }
        
   # If a message is not to me (ignoring +detail), junk it.
   if not allof (address :user ["to", "cc", "bcc"] "ken",
        address :domain ["to", "cc", "bcc"] "example.org") {
     discard;
        

}

}

   # Redirect all mail sent to +foo.
   if envelope :detail ["to", "cc", "bcc"] "foo" {
     redirect "ken@example.edu";
   }
        
4. Security Considerations
4. セキュリティに関する考慮事項

Security considerations are discussed in [SIEVE]. It is believed that this extension does not introduce any additional security concerns.

セキュリティ上の考慮事項については、[ふるい]で説明します。この拡張機能は追加のセキュリティ上の懸念をもたらさないと考えられています。

5. IANA Considerations
5. IANAの考慮事項

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

次のテンプレートは、このドキュメントで指定されたSIVE拡張のIANA登録を指定します。

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

宛先:iana@iana.org件名:新しいふるい延長の登録

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

機能名:サブアドレス機能キーワード:サブアドレス機能引数:n/a標準トラック/RFC 3598人と電子メールアドレスに連絡して、詳細について:

Kenneth Murchison ken@oceana.com

Kenneth Murchison ken@oceana.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. Normative References
6. 引用文献

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

[imail] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。

[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. Acknowledgments
7. 謝辞

Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall Gellens, Philip Guenther and Jutta Degener for their help with this document.

ティム・ショールーター、アレクセイ・メルニコフ、マイケル・サーモン、ランドール・ゲレンズ、フィリップ・ゲンサー、ジュッタ・デジェナーに感謝します。

8. Intellectual Property Statement
8. 知的財産声明

The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.

IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。

9. Author's Address
9. 著者の連絡先

Kenneth Murchison Oceana Matrix Ltd. 21 Princeton Place Orchard Park, NY 14127

Kenneth Murchison Oceana Matrix Ltd. 21プリンストンプレイスオーチャードパーク、ニューヨーク14127

   EMail: ken@oceana.com
        
10. 完全な著作権声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

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

RFCエディター機能の資金は現在、インターネット協会によって提供されています。