Network Working Group J. Lyon
Request for Comments: 4407 Microsoft Corp.
Category: Experimental April 2006
Purported Responsible Address in E-Mail Messages
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
IESG Note
IESG注意
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group.
何の一般的な技術コンセンサスと失敗した二つのアプローチを調整するための努力はありませんが、以下の文書（RFC 4405、RFC 4406、RFC 4407、およびRFC 4408）は、実験的RFCとして同時に公開されています。このように、これらの文書は、完全なIETFレビューを受け取っていないと、彼らがMARIDワーキンググループで検討されたとして異なるアプローチを文書化するために、「AS-IS」に公開されています。
The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them.
IESGはアプローチが好ましいとされ、それぞれのアプローチとタンデムでそれらを使用する方法についての懸念のための重大な未解決の問題があることを読者に警告するかについて何の位置を取りません。 IESGは異なるアプローチを文書化することは、それらを文書化していないよりも少ない害をすることを考えています。
Note that the Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt.
Sender IDの実験は、現在のSPF実験やこの一連の実験では、以前のバージョン用に作成されている可能性がDNSレコードを使用することができることに注意してください。レコードの内容によっては、これは、Sender-IDの経験則がメッセージに間違って適用されることを意味します。これらの経験則に受信者が関連するアクションに応じて、メッセージが配信されていないか、または領収書に破棄されることがあります。
Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict.
Sender IDの実験のDNSレコードに依存する参加者は、彼らは状況のこのセットに有効なメッセージを失う可能性があると警告しています。 SPF実験のDNSレコードを公開参加者は、RFC 4406のセクション3.4で与えられたアドバイスを検討すべきとの競合を避けるために、V = SPF1とspf2.0両方のレコードを公開することもできます。
Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem.
送信者ID実験の参加者は、標準準拠のシステムはResent-を添加しないことにより、規格に準拠して（具体的には、自動フォワーダと相互作用するときにはResent- *ヘッダフィールドを使用する方法が正当な電子メールを受信するのに失敗をもたらすであろうことに注意する必要がRFC 822に準拠していますが、まだRFC 2822のResent- *セマンティクスを実装していない*ヘッダ、およびシステム）。この相互運用性の問題を解決せずに標準化過程の上送信者IDを進めるために不適切です。
The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future.
コミュニティは、コミュニティの合意は、将来的に到達できるようにするために、公表後2年の間に2つのアプローチの成功または失敗を観察するために招待されます。
Abstract
抽象
This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).
この文書では、1が最も近接し、そのメッセージが配信される原因となったように見える党のアイデンティティを抽出することができ、電子メールメッセージ与えられ、それによってアルゴリズムを定義します。このIDは、自称責任アドレス（PRA）と呼ばれています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Determining the Purported Responsible Address ...................3
3. Security Considerations .........................................5
4. Acknowledgements ................................................5
5. References ......................................................5
5.1. Normative References .......................................5
5.2. Informative References .....................................5
Most e-mail flows relatively directly from a sender to a recipient, with a small number of Mail Transfer Agents (MTAs) in between. Some messages, however, are resent by forwarding agents, mailing list servers, and other such software. These messages effectively result in two or more mail transactions: one from the sender to the forwarding agent, and another from the agent to the destination.
ほとんどの電子メールは、間にメール転送エージェント（MTA）の数が少ないと、受信者に送信者から比較的直接流れます。一部のメッセージが、しかし、転送エージェント、メーリングリストサーバ、およびその他のようなソフトウェアによって再送されています。フォワーディング・エージェントへの送信者から1、およびエージェントから目的地まで別：これらのメッセージは、効果的に二つ以上のメール取引につながります。
In some cases, messages travel through more than one of these agents. This can occur, for example, when one mailing list is subscribed to another, or when the address subscribed to a mailing list is a forwarding service.
いくつかのケースでは、メッセージは、これらの薬剤の複数を通って移動します。これは、1つのメーリングリストが他に加入、またはメーリングリストに登録したアドレスが転送サービスの場合にされたときに、例えば、発生する可能性があります。
Further complicating the situation, in some cases the party that introduces a message is not the author of the message. For example, many news web sites have a "Mail this article" function that the public can use to e-mail a copy of the article to a friend. In this case, the mail is "from" the person who pressed the button, but is physically sent by the operator of the web site.
さらに事態を複雑にし、いくつかのケースでは、メッセージを紹介する当事者はメッセージの作成者ではありません。例えば、多くのニュースのウェブサイトでは、国民は友人に記事のコピーを電子メールで送信するために使用することができます「この記事をメール」機能を持っています。この場合、メールがボタンを押した人「から」ですが、物理的にウェブサイトの運営者によって送信されます。
This document defines a new identity associated with an e-mail message, called the Purported Responsible Address (PRA), which is determined by inspecting the header of the message. The PRA is designed to be the entity that (according to the header) most recently caused the message to be delivered.
この文書は、電子メールメッセージに関連付けられた新しいアイデンティティを定義し、メッセージのヘッダを検査することによって決定される主張責任アドレス（PRA）と呼ばれます。 PRAは、最も最近のメッセージが配信される原因となった（ヘッダに従って）エンティティであるように設計されます。
Note that the results of this algorithm are only as truthful as the headers contained in the message; if a message contains fraudulent or incorrect headers, this algorithm will yield an incorrect result. For this reason, the result of the algorithm is called the "Purported Responsible Address" -- "purported" because it tells you what a message claims about where it came from, but not necessarily where it actually came from.
このアルゴリズムの結果は、ヘッダがメッセージに含まれるとしてのみ真実であることに注意してください。メッセージは、詐欺や不正なヘッダが含まれている場合、このアルゴリズムは、誤った結果が得られます。このため、アルゴリズムの結果は「主張責任アドレス」と呼ばれている - それは、メッセージが、それがどこから来たのかについての主張かを表示しますので、「主張」は、必ずしもそうではないが、それは実際にはどこから来たのか。
This document does not prescribe any particular uses for the Purported Responsible Address. However, [RFC4406] describes a method of determining whether a particular MTA is authorized to send mail on behalf of the domain contained in the PRA.
この文書では、主張責任アドレスのための任意の特定の使用を規定していません。しかしながら、[RFC4406]は、特定のMTAがPRAに含まれるドメインの代わりにメールを送信することを許可されているかどうかを決定する方法を記載しています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The PRA of a message is determined by the following algorithm:
メッセージのPRAは、以下のアルゴリズムによって決定されます。
1. Select the first non-empty Resent-Sender header in the message. If no such header is found, continue with step 2. If it is preceded by a non-empty Resent-From header and one or more Received or Return-Path headers occur after said Resent-From header and before the Resent-Sender header, continue with step 2. Otherwise, proceed to step 5.
1.メッセージ内の最初の非空のResent-Senderのヘッダを選択。そのようなヘッダーが見つからない場合、それが空でないFromヘッダ憤慨、および1つまたは複数の受信またはリターンパスヘッダが先行する場合、ステップ2に進み後ヘッダ憤慨-からとのResent-Senderのヘッダの前に述べて発生、そうでない場合はステップ2に進み、ステップ5に進みます。
2. Select the first non-empty Resent-From header in the message. If a Resent-From header is found, proceed to step 5. Otherwise, continue with step 3.
前記第1の非空のResent-からヘッダメッセージに選択。憤慨-からヘッダが見つかった場合、それ以外の場合はステップ5に進み、ステップ3に進みます。
3. Select all the non-empty Sender headers in the message. If there are no such headers, continue with step 4. If there is exactly one such header, proceed to step 5. If there is more than one such header, proceed to step 6.
3.メッセージ内のすべての空でない送信者のヘッダを選択します。そのようなヘッダが存在しない場合、そのようなヘッダが正確に存在する場合、複数のそのようなヘッダがある場合は、ステップ6に進むステップ5に進むステップ4に進み。
4. Select all the non-empty From headers in the message. If there is exactly one such header, continue with step 5. Otherwise, proceed to step 6.
4.メッセージ内のヘッダーからすべての非空を選択します。そのようなヘッダが正確に存在する場合、そうでない場合は、ステップ6に進み、ステップ5に進みます。
5. A previous step has selected a single header from the message. If that header is malformed (e.g., it appears to contain multiple mailboxes, or the single mailbox is hopelessly malformed, or the single mailbox does not contain a domain name), continue with step 6. Otherwise, return that single mailbox as the Purported Responsible Address.
5.前の手順は、メッセージからの単一のヘッダを選択しています。そのヘッダが不正である場合（例えば、複数のメールボックスが含まれているように見える、または単一のメールボックスは絶望的に不正な形式である、または単一のメールボックスは、ドメイン名が含まれていない）、それ以外の場合はステップ6に進み、主張責任として、その単一のメールボックスを返します住所。
6. The message is ill-formed, and it is impossible to determine a Purported Responsible Address.
6.メッセージが悪い形成され、主張責任アドレスを決定することは不可能です。
For the purposes of this algorithm, a header field is "non-empty" if and only if it contains any non-whitespace characters. Header fields that are otherwise relevant but contain only whitespace are ignored and treated as if they were not present.
このアルゴリズムの目的で、ヘッダフィールドは、それが任意の非空白文字が含まれている場合にのみ、「非空」です。それ以外の場合は関連していますが、唯一の空白が含まれているヘッダフィールドは無視され、それらが存在しないかのように扱われます。
Note that steps 1 and 2 above extract the Resent-Sender or Resent-From header from the first resent block (as defined by section 3.6.6 of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From header if there are no resent blocks.
最初の再送ブロックから抽出上方憤慨、送信者または憤慨-からヘッダ1及び2ステップ音符（[RFC2822]のセクション3.6.6で定義）があれば。ステップ3とNO再送ブロックが存在しない場合は4は、上記送信者またはFromヘッダーを抽出します。
Note that what constitutes a hopelessly malformed header or a hopelessly malformed mailbox in step 5 above is a matter for local policy. Such local policy will never cause two implementations to return different PRAs. However, it may cause one implementation to return a PRA where another implementation does not. This will occur only when dealing with a message containing headers of questionable legality.
絶望的に奇形のヘッダーまたはステップ5で絶望的不正なメールボックスを構成するもの上記ローカルポリシーの問題であることに留意されたいです。このようなローカルポリシーが異なるのPRAを返すために、2つの実装を引き起こすことはありません。しかし、それは一つの実施は、他の実装がないPRAを返すために発生することがあります。疑わしい合法性のヘッダを含むメッセージを扱う場合にのみ発生します。
Although the algorithm specifies how messages that are not in strict conformance with the provisions of RFC 2822 should be treated for the purposes of determining the PRA, this should not be taken as requiring or recommending that any systems accept such messages when they otherwise would not have done so. However, if a liberal implementation accepts such messages and desires to know their PRAs, it MUST use the algorithm specified here.
アルゴリズムは、RFC 2822の規定に厳密に準拠していないメッセージがPRAを決定する目的のために処理されるべき方法を指定するが、これは、彼らがそうでなければ持っていない場合、任意のシステムは、このようなメッセージを受け入れることを要求または勧告として解釈されるべきではありませんそうし。リベラルな実装は、このようなメッセージを受け入れ、彼らののPRAを知りたい場合は、それはここで指定されたアルゴリズムを使用しなければなりません。
Where messages conform to RFC 822 rather than RFC 2822, it is possible for the algorithm to give unexpected results. An RFC822 message should not normally contain more than one set of resent headers; however, the placement of those headers is not specified, nor are they required to be contiguous. It is therefore possible that the Resent-From header will be selected even though a Resent-Sender header is present. Such cases are expected to be rare or non-existent in practice.
メッセージではなくRFC 2822よりも822をRFCに準拠どこアルゴリズムは、予期しない結果を与えるすることが可能です。 RFC822メッセージは通常、再送ヘッダの複数のセットを含めることはできません。しかし、これらのヘッダの配置が指定されていない、また彼らは連続であることが要求されています。再送、送信者のヘッダが存在するにもかかわらず、憤慨-からヘッダが選択されることが可能です。このようなケースは実際には稀なまたは存在しないことが予想されます。
The PRA, as described by this document, is extracted from message headers that have historically not been verified. Thus, anyone using the PRA for any purpose MUST be aware that the headers from which it is derived might be fraudulent, malicious, malformed, and/or incorrect. [RFC4406] describes one mechanism for validating the PRA.
PRAは、本文書によって記載されているように、歴史的に検証されていないメッセージヘッダから抽出されます。このように、どのような目的のためにPRAを使用して誰もが、それが由来するヘッダは、詐欺的な悪質な、不正な形式、および/または不正確かもしれないことを認識しなければなりません。 [RFC4406]はPRAを検証するための一つのメカニズムを説明しています。
A message's PRA will often be extracted from a header field that is not normally displayed by existing mail user agent software. If the PRA is used as part of a mechanism to authenticate the message's origin, the message SHOULD NOT be displayed with an indication of its authenticity (positive or negative) without the PRA header field also being displayed.
メッセージのPRAは、多くの場合、通常、既存のメールユーザエージェントソフトウェアによって表示されていないヘッダフィールドから抽出されます。 PRAは、メッセージの発信元を認証するための機構の一部として使用される場合、メッセージは表示されているPRAヘッダフィールドなし（正または負）は、その真正性の表示で表示されません。
The PRA concept was first published in [CallerID]. It has been refined using valuable suggestions from members of the MARID working group.
PRAのコンセプトは、最初の[発信者番号]に掲載されました。これは、MARIDワーキンググループのメンバーから貴重な提案を使用して洗練されています。
[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月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical Specification, http://www.microsoft.com/mscorp/safety/technologies/ senderid/resources.mspx
[発信者番号]マイクロソフトコーポレーション、Eメール技術仕様のための発信者ID、http://www.microsoft.com/mscorp/safety/technologies/のSenderID / resources.mspx
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[RFC4406]リヨン、J.とM.ウォン、 "送信者ID：の認証Eメール"、RFC 4406、2006年4月。
Author's Address
著者のアドレス
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
じｍ ょん みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: jimlyon@microsoft.com
メールアドレス：jimlyon@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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/SHE 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。