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.Sender-ID実験の参加者は、Resent-*ヘッダフィールドを使う方法では、標準に準拠したシステム（特に、Resent-*ヘッダを追加しない方法で標準に準拠している自動転送器や、RFC822には準拠しているがRFC2822のResent-*セマンティクスを実装していないシステム）との対話時に正しい電子メールを受信できない結果になることに気づく必要がある。
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年間で本RFCの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).
要約
本文書は、電子メールメッセージにおいて、そのメッセージを配送させた責任を最も有しているとされる対象の身元を抽出するためのアルゴリズムを定義している。この身元はPRA（Purported Responsible Address：責任を持つはずのアドレス）と呼ばれている。
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
目次
1. はじめに 2
1.1. 本文書で使われる慣例 3
2. PRAの決定 3
3. セキュリティに関する考察 5
4. 謝辞 5
5. 参照資料 5
5.1. インターネット標準に関する参照資料 5
5.2. 情報に関する参照資料 5
1. Introduction
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.
1. はじめに
ほとんどの電子メールは、送信者から受信者へと比較的直接に配送され、経由するMTA（電子メール転送エージェント）の数は少ない。しかし、転送エージェントやメーリングリストサーバ、その他のソフトウェアによって再送されるメッセージも存在する。これらのメッセージでは、まず送信者から転送エージェントへ、そしてエージェントから宛先へと、実質的に2回以上のメール転送が行われることになる。
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.場合によっては、これらのエージェントを複数経由するメッセージもある。このような例は、あるメーリングリストが別のメーリングリストの購読者である場合や、メーリングリストを購読しているアドレスが転送サービスである場合に起こりうる。
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.状況をさらに複雑にすることに、時にはメッセージを最初に送った送信者がメッセージの書き手でない場合もある。たとえば、ニュースサイトの多くでは、「この記事を電子メールで送る」という機能があり、閲覧者がその記事のコピーを友人に電子メールで送るために使うことができる。この場合、そのメールはボタンを押した人「から」のメールであるが、物理的にはウェブサイトの管理ソフトによって送られる。
[Page 2]
| 《PREV》 |