RFC5233 日本語訳
5233 Sieve Email Filtering: Subaddress Extension. K. Murchison. January 2008. (Format: TXT=12448 bytes) (Obsoletes RFC3598) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Murchison Request for Comments: 5233 Carnegie Mellon University Obsoletes: 3598 January 2008 Category: Standards Track
コメントを求めるワーキンググループK.マーチソンの要求をネットワークでつないでください: 5233年のカーネギーメロン大学は以下を時代遅れにします。 3598 2008年1月のカテゴリ: 標準化過程
Sieve Email Filtering: Subaddress Extension
ふるいのメールフィルタリング: Subaddress拡張子
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
要約
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 Email Filtering Language that allows users to compare against the user and detail sub-parts of an address.
'「副-扱」う'と考慮するメールシステムか'詳細なアドレシング'(例えば、「理解+ sieve@example.org 」)では、これらに対する比較をアドレスのサブ部分にするのは時々望ましいです。 このドキュメントはユーザとユーザの詳細サブの部品を比較させるアドレスのSieveメールFiltering Languageと拡大を定義します。
Table of Contents
目次
1. Introduction ....................................................2 2. Conventions Used in This Document ...............................2 3. Capability Identifier ...........................................2 4. Subaddress Comparisons ..........................................2 5. IANA Considerations .............................................5 6. Security Considerations .........................................5 7. Normative References ............................................5 Appendix A. Acknowledgments ........................................6 Appendix B. Changes since RFC 3598 .................................6
1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. 能力識別子…2 4. Subaddress比較…2 5. IANA問題…5 6. セキュリティ問題…5 7. 標準の参照…5 付録A.承認…6 RFC3598以来付録B.は変化します…6
Murchison Standards Track [Page 1] RFC 5233 Sieve: Subaddress Extension January 2008
マーチソンStandardsはRFC5233ふるいを追跡します[1ページ]: Subaddress拡大2008年1月
1. Introduction
1. 序論
Subaddressing is the practice of augmenting the local-part of an [RFC2822] address with some 'detail' information in order to give some extra meaning to that address. One common way of encoding 'detail' information into the local-part is to add a 'separator character sequence', such as "+", to form a boundary between the 'user' (original local-part) and 'detail' sub-parts of the address, much like the "@" character forms the boundary between the local-part and domain.
Subaddressingは何らかの付加的な意味をそのアドレスに与えるために何らかの'詳細'情報で[RFC2822]アドレスの地方の部分を増大させる習慣です。 '詳細'情報を地方の部分にコード化する1つの一般的な方法はアドレスの'ユーザ'(元の地方の部分)と'詳細'サブ部分の間の境界を形成するために「+」などの'分離符キャラクタシーケンス'を加えることです、"@"キャラクタが地方の部分とドメインの間の境界を形成するように。
Typical uses of subaddressing might be:
「副-扱」うことの典型的な用途は以下の通りです。
o A message addressed to "ken+sieve@example.org" is delivered into a
mailbox called "sieve" belonging to the user "ken".
o 「理解+ sieve@example.org 」に扱われたメッセージはユーザ「理解」に属しながら「ふるい」と呼ばれるメールボックスの中に提供されます。
o A message addressed to "5551212#123@example.com" is delivered to
the voice mailbox number "123" at phone number "5551212".
o 「5551212# 123@example.com 」に扱われたメッセージは電話番号「5551212」におけるボイス・メールボックス番号「123」に提供されます。
This document describes an extension to the Sieve language defined by [RFC5228] for comparing against the 'user' and 'detail' sub-parts of an address.
このドキュメントはアドレスの'ユーザ'と'詳細'サブ部分に対して比較するために[RFC5228]によって定義されたSieve言語に拡大について説明します。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Capability Identifier
3. 能力識別子
The capability string associated with the extension defined in this document is "subaddress".
定義される拡大に関連している能力ストリングは本書では"「副-アドレス」"です。
4. Subaddress Comparisons
4. Subaddress比較
Test 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.
「排他的にアドレスに影響するテスト命令が任意のタグ付けをされた議論を取るかもしれない」: ユーザ、」 」 : 詳細である、」 アドレスの地方の部分のどんなサブ一部分が作用されるかを指定するために。
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,
以下に注意してください。 願望がそれらが特定の受取人に着くようにどのように扱われたかに基づくメッセージを分類することであるときに、多くの場合、封筒“to"アドレスは「副-アドレス」情報がないかどうか調べる都合のよいアドレスです。 封筒アドレスは結局与えられたメッセージが与えられたユーザのために与えられたふるいのスクリプトで処理されている理由です。 メーリングリストであるときに、これは特に本当です。
Murchison Standards Track [Page 2] RFC 5233 Sieve: Subaddress Extension January 2008
マーチソンStandardsはRFC5233ふるいを追跡します[2ページ]: Subaddress拡大2008年1月
aliases, and 'virtual domains' are involved since the envelope may
be the only source of detail information for the specific
recipient.
別名、および'バーチャル・ドメイン'は、封筒が特定の受取人への詳細情報の唯一の源であるかもしれないので、かかわります。
NOTE: Because the encoding of detailed addresses are site and/or
implementation specific, using the subaddress extension on foreign
addresses (such as the envelope "from" address or originator
header fields) may lead to inconsistent or incorrect results.
以下に注意してください。 詳細なアドレスのコード化がサイト、そして/または、実装特有であるので、外国アドレス(封筒“from"アドレスか創始者ヘッダーフィールドなどの)で「副-アドレス」拡張子を使用するのは矛盾したか不正確な結果に通じるかもしれません。
The ":user" argument specifies the user sub-part of the local-part of an address. If the address is not encoded to contain a detail sub- part, then ":user" specifies the entire left side of the address (equivalent to ":localpart").
「」 : ユーザ、」 議論はアドレスの地方の部分のユーザサブ一部分を指定します。 「アドレスは」 : 詳細サブ部分、次にユーザを含むようにコード化されない」、アドレスの全体の左側を指定する、(」 : localpartに同等である、」、)
The ":detail" argument specifies the detail sub-part of the local-
part of an address. If the address is not encoded to contain a
detail sub-part, then the address fails to match any of the specified
keys. If a zero-length string is encoded as the detail sub-part,
then ":detail" resolves to the empty value ("").
「」 : 」 議論がアドレスの地方の部分の詳細サブ一部分を指定するという詳細。 アドレスが詳細サブ部分を含むようにコード化されないなら、アドレスは指定されたキーのいずれにも合っていません。 「次に、ゼロ長ストリングが詳細サブ部分としてコード化されるなら」: 」 決心を空の値に詳しく述べてください、(「「)。」
NOTE: If the encoding method used for detailed addresses utilizes
a separator character sequence, and the separator character
sequence occurs more than once in the local-part, then the logic
used to split the address is implementation-defined and is usually
dependent on the format used by the encompassing mail system.
以下に注意してください。 詳細なアドレスに使用されるコード化メソッドが分離符キャラクタシーケンスを利用して、分離符キャラクタシーケンスが地方の部分の一度より起こるなら、アドレスを分けるのに使用される論理は、実装で定義されていて、通常、取り囲んでいるメールシステムによって使用される形式に依存しています。
Implementations MUST make sure that the encoding method used for detailed addresses matches that which is used and/or allowed by the encompassing mail system, otherwise unexpected results might occur. Note that the mechanisms used to define and/or query the encoding method 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 [RFC5228], Section 2.7.4.
「」 : ユーザ、」 」 : 」 アドレス部は[RFC5228]、セクション2.7で.4に定義された標準のアドレス部として同じ規則と制限を受けることがあるという詳細
For convenience, the "ADDRESS-PART" syntax element defined in [RFC5228], Section 2.7.4, is augmented here as follows:
便利において、[RFC5228]で定義された「アドレス部」構文要素(セクション2.7.4)は以下の通りここで増大します:
ADDRESS-PART =/ ":user" / ":detail"
「アドレス部=/」: ユーザ、」 /、」 : 詳細である、」
A diagram showing the ADDRESS-PARTs of an email address where the detail information follows a separator character sequence of "+" is shown below:
詳細情報が「+」の分離符キャラクタシーケンスにどこに従うかをEメールアドレスのADDRESS-PARTsに示すダイヤグラムは以下で見せられます:
Murchison Standards Track [Page 3] RFC 5233 Sieve: Subaddress Extension January 2008
マーチソンStandardsはRFC5233ふるいを追跡します[3ページ]: Subaddress拡大2008年1月
:user "+" :detail "@" :domain
\-----------------/
:local-part
:ユーザ「+」:detail"@":domain\-----------------/: 地方の部分
A diagram showing the ADDRESS-PARTs of a email address where the detail information precedes a separator character sequence of "--" is shown below:
詳細情報がどこで「--」の分離符キャラクタシーケンスに先行するかをEメールアドレスのADDRESS-PARTsに示すダイヤグラムは以下で見せられます:
:detail "--" :user "@" :domain
\------------------/
:local-part
:詳細「--」:user"@":domain\------------------/: 地方の部分
Example (where the detail information follows "+"):
例(詳細情報が「+」に続くところ):
require ["envelope", "subaddress", "fileinto"];
[「封筒」、"「副-アドレス」""fileinto"]を必要としてください。
# In this example the same user account receives mail for both
# "ken@example.com" and "postmaster@example.com"
# この例では、同じユーザアカウントは#" ken@example.com "と" postmaster@example.com "の両方のためのメールを受け取ります。
# File all messages to postmaster into a single mailbox,
# ignoring the :detail part.
if envelope :user "to" "postmaster" {
fileinto "inbox.postmaster";
stop;
}
# #:detail部分を無視して、単一のメールボックスの中への郵便局長にすべてのメッセージをファイルしてください、封筒:user“to"「郵便局長」です。fileinto"inbox.postmaster"(停止)
# File mailing list messages (subscribed as "ken+mta-filters").
if envelope :detail "to" "mta-filters" {
fileinto "inbox.ietf-mta-filters";
}
# メーリングリストメッセージ(「+がmtaにフィルターにかける理解」として、申し込まれる)をファイルしてください、封筒:detail“to"「mta-フィルタ」です。fileinto「inbox.ietf-mta-フィルタ」。
# Redirect all mail sent to "ken+foo".
if envelope :detail "to" "foo" {
redirect "ken@example.net";
}
# 「理解+foo」に送られたすべてのメールを転送してください。封筒:detail“to"であるなら「foo」再直接の" ken@example.net "。
Murchison Standards Track [Page 4] RFC 5233 Sieve: Subaddress Extension January 2008
マーチソンStandardsはRFC5233ふるいを追跡します[4ページ]: Subaddress拡大2008年1月
5. IANA Considerations
5. IANA問題
The following template specifies the IANA registration of the subaddress Sieve extension specified in this document. This registration replaces that from RFC 3598:
以下のテンプレートは本書では指定されたsubaddress Sieve拡張子のIANA登録を指定します。 この登録はRFC3598からそれに取って代わります:
To: iana@iana.org Subject: Registration of new Sieve extension
To: iana@iana.org Subject: 新しいSieve拡張子の登録
Capability name: subaddress
Description: Adds the ':user' and ':detail' address parts
for use with the address and envelope tests
RFC number: RFC 5233
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名: 「副-アドレス」記述: 'アドレスと封筒テストRFC番号で使用のための': ユーザ'と': 詳細'アドレス部を加えます: RFC5233Contactアドレス: Sieve議論 list <ietf-mta-filters@imc.org 、gt。
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 で与えられたSieve拡張子のリストにこの情報を追加してあります。
6. Security Considerations
6. セキュリティ問題
Security considerations are discussed in [RFC5228]. It is believed that this extension does not introduce any additional security concerns.
[RFC5228]でセキュリティ問題について議論します。 この拡大が少しの追加担保関心も導入しないと信じられています。
7. Normative References
7. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC5228] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, January 2008.
[RFC5228]グンサー、P.、エド、T.ショウォーター、エド、「ふるい:」 「言語をフィルターにかけるメール」、RFC5228、2008年1月。
Murchison Standards Track [Page 5] RFC 5233 Sieve: Subaddress Extension January 2008
マーチソンStandardsはRFC5233ふるいを追跡します[5ページ]: Subaddress拡大2008年1月
Appendix A. Acknowledgments
付録A.承認
Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall Gellens, Philip Guenther, Jutta Degener, Michael Haardt, Ned Freed, Mark Mallett, and Barry Leiba for their help with this document.
このドキュメントによる彼らのお力添えをティム・ショウォーター、Alexeyメリニコフ、マイケルSalmon、ランドルGellens、フィリップ・グンサー、ユッタDegener、マイケルHaardt、ネッド・フリード、マーク・マレット、およびバリーLeibaをありがとうございます。
Appendix B. Changes since RFC 3598
RFC3598以来の付録B.変化
o Discussion of how the user and detail information is encoded now
uses generic language.
o ユーザと詳細情報が現在どうコード化されるかに関する議論はジェネリック言語を使用します。
o Added note detailing that this extension is most useful when used
on the envelope "to" address.
o それを詳しく述べて、封筒“to"アドレスで使用されるとこの拡大が最も役に立つことに注意するように言い足しました。
o Added note detailing that this extension isn't very useful on
foreign addresses (envelope "from" or originator header fields).
o それを詳しく述べて、この拡大が外国アドレス(封筒“from"か創始者ヘッダーフィールド)でそれほど役に立たないことに注意するように言い足しました。
o Fixed envelope test example to only use "to" address.
o “to"アドレスを使用するだけであるために封筒テストの例を修理しました。
o Replaced ":user" example with one that doesn't produce unexpected
behavior.
o : ユーザを「取り替える」、」 予期していなかった振舞いを起こさないものがある例。
o Refer to the zero-length string ("") as "empty" instead of "null"
(per RFC 5228).
o ゼロ長ストリングを参照してください、(「「)、「ヌル(RFC5228あたりの)」の代わりに「空である」、」
o Use only RFC 2606 domains in examples.
o 例でRFC2606ドメインだけを使用してください。
o Miscellaneous editorial changes.
o 種々雑多な社説は変化します。
Author's Address
作者のアドレス
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA
ケネスマーチソンカーネギーメロン大学5000フォーブズアベニューCyert Hall285PA15213ピッツバーグ(米国)
Phone: +1 412 268 2638 EMail: murch@andrew.cmu.edu
以下に電話をしてください。 +1 2638年の412 268メール: murch@andrew.cmu.edu
Murchison Standards Track [Page 6] RFC 5233 Sieve: Subaddress Extension January 2008
マーチソンStandardsはRFC5233ふるいを追跡します[6ページ]: Subaddress拡大2008年1月
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に情報を扱ってください。
Murchison Standards Track [Page 7]
マーチソン標準化過程[7ページ]
一覧
スポンサーリンク
