Network Working Group J. Lyon
Request for Comments: 4406 Microsoft Corp.
Category: Experimental M. Wong
pobox.com
April 2006
Sender ID: Authenticating E-Mail
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
抽象
Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.
この場合は、アドレスはドメインの所有者の許可なしに使用されていることを意味して「偽装された」 - インターネットメールは、多くの迷惑メールが偽装されたアドレスを使用して送信されているという事実に苦しんでいます。この文書では、SMTPサーバが受信したメッセージ内の電子メールアドレスはその電子メールアドレスに含まれるドメインの所有者の許可を得て使用されたかどうかを判断することが可能なテストの家族を記述する。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Problem Statement ...............................................4
3. SPF 2.0 Records .................................................5
3.1. Version and Scope ..........................................5
3.1.1. Minor Version .......................................6
3.2. Multiple Records ...........................................6
3.3. Positional Modifiers .......................................7
3.4. Compatibility ..............................................8
4. Decision Model ..................................................8
4.1. Arguments ..................................................9
4.2. Results ....................................................9
4.3. Record Lookup ..............................................9
4.4. Record Selection ...........................................9
5. Actions Based on the Decision ..................................10
5.1. Neutral, None, SoftFail, or PermError .....................11
5.2. Pass ......................................................11
5.3. Fail ......................................................11
5.4. TempError .................................................11
6. Security Considerations ........................................11
6.1. DNS Attacks ...............................................12
6.2. TCP Attacks ...............................................12
6.3. Forged Sender Attacks .....................................12
6.4. Address Space Hijacking ...................................12
6.5. Malicious DNS Attacks on Third Parties ....................13
7. Implementation Guidance ........................................13
7.1. Simple E-Mailers ..........................................14
7.2. E-Mail Forwarders .........................................14
7.3. Mailing List Servers ......................................15
7.4. Third-Party Mailers .......................................15
7.5. MUA Implementers ..........................................15
8. Acknowledgements ...............................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
Today, a huge majority of unwanted e-mail contains headers that lie about the origin of the mail. This is true of most spam and substantially all of the virus e-mail that is sent.
今日では、不要な電子メールの巨大な大多数は、メールの原点を偽るのヘッダーが含まれています。これは、ほとんどのスパムおよび実質的にすべて送信されたウイルスメールの真のです。
This document describes a mechanism such that receiving Mail Transfer Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents (MUAs) can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message, an MDA might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion.
この文書では、メカニズムを説明受信メール転送エージェント（MTA）、メール配送エージェント（のMDA）、および/またはメールユーザエージェント（MUA）は上記のカテゴリにメールを認識し、適切な措置をとることができるようになっています。たとえば、MTAがメッセージを受け入れることを拒否される場合もあります、MDAはメッセージを破棄するのではなくメールボックスにそれを置く、とMUAは、いくつかの特徴的な方法でそのメッセージをレンダリングする場合があります。
In order to avoid further fragmentation of the Internet e-mail system, it is desirable that the Internet community as a whole come to a consensus as to what mail senders should do to make their mail appear non-spoofed, and how mail receivers should determine whether mail is spoofed. On the other hand, it is not necessary to reach a consensus regarding the actions that various parties take once a message has been determined to be spoofed. This can be done unilaterally -- one agent might decide to discard a spoofed message whereas another decides to add a disclaimer.
インターネット電子メールシステムのさらなる断片化を避けるために、それは、インターネットコミュニティ全体が送信者がメールを作るために何をすべきか、メールへと合意に達していることが望ましい非偽装され表示され、メールの受信機が決定する方法メールが偽装されているかどうか。一方、さまざまな当事者がメッセージを詐称することが決定された一回取る行動に関する合意に達するために必要はありません。これは、一方的に行うことができます - 別の免責事項を追加することを決定したのに対し、1つのエージェントが偽装されたメッセージを破棄することを決定するかもしれません。
This document defines a pair of closely-related tests. One validates a message's Purported Responsible Address (PRA) as defined in [RFC4407]. The other validates a message's Reverse-Path (also known as MAIL-FROM address) as defined in [RFC4408].
この文書では、密接に関連するテストの組を定義します。 [RFC4407]で定義されるように、1つは、メッセージの主張責任アドレス（PRA）を検証します。 [RFC4408]で定義されるように、他は（また、MAIL-FROMアドレスとしても知られる）、メッセージのリバースパスを検証します。
An e-mail sender complying with this specification SHOULD publish information for both tests, and SHOULD arrange that any mail that is sent will pass both tests. An e-mail receiver complying with this specification SHOULD perform at least one of these tests.
この仕様に準拠する電子メールの送信者は、両方のテストのための情報を公開すべきである、と送信されるメールは、両方のテストに合格することを手配すべきです。この仕様に準拠する電子メールの受信者は、これらのテストのうちの少なくとも一つを実行する必要があります。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [RFC2119]に記載されているように解釈されるべきです。
Briefly stated, the mechanisms of this document allow one to answer the following question:
簡単に述べると、このドキュメントのメカニズムは、次の質問に答えるために1を許可します：
When a message is transferred via SMTP between two unrelated parties, does the SMTP client host have permission to send mail on behalf of a mailbox referenced by the message?
メッセージは2つの無関係な当事者間でSMTPを介して転送されると、SMTPクライアントのホストは、メッセージが参照するメールボックスの代理でメールを送信する権限を持っていますか？
As seen from the question, this mechanism applies to unrelated parties: It is useful at the point where a message passes across the Internet from one organization to another. It is beyond the scope of this document to describe authentication mechanisms that can be deployed within an organization.
質問からわかるように、このメカニズムは無関係な者に適用されます。これは、メッセージが1つの組織から別の組織インターネットを通過する時点で有効です。これは、組織内で展開することができる認証メカニズムを記述するために、このドキュメントの範囲を超えています。
The PRA version of the test seeks to authenticate the mailbox associated with the most recent introduction of a message into the mail delivery system. In simple cases, this is who the mail is from. However, in the case of a third-party mailer, a forwarder, or a mailing list server, the address being authenticated is that of the third party, the forwarder, or the mailing list.
テストのPRAのバージョンは、メール配信システムへのメッセージの最も最近の導入に関連したメールボックスを認証しようとしています。簡単な例では、これは、メールから提示された方です。しかし、サードパーティのメーラー、フォワーダ、またはメーリングリストサーバの場合には、認証されているアドレスは第三者、フォワーダ、またはメーリングリストのことです。
On the other hand, the MAIL-FROM version of the test seeks to authenticate the mailbox that would receive Delivery Status Notifications (DSNs, or bounces) for the message. In simple cases, this too is who the mail is from. However, third-party mailers, forwarders, and mailing list servers MUST specify an address under their control, and SHOULD arrange that DSNs received at this address are forwarded to the original bounce address.
一方、MAIL FROM-テストのバージョンでは、メッセージの配信状態通知（DSN、またはバウンス）を受け取ることになるメールボックスを認証しようとしています。簡単な例では、これはあまりにもメールがあるから誰です。しかし、サードパーティのメーラー、フォワーダ、メーリングリストサーバは、その管理下にアドレスを指定する必要があり、かつDSNには、元のバウンスアドレスに転送され、このアドレスで受信したことを手配すべきです。
In both cases, the domain associated with an e-mail address is what is authenticated; no attempt is made to authenticate the local-part. A domain owner gets to determine which SMTP clients speak on behalf of addresses within the domain; a responsible domain owner should not authorize SMTP clients that will lie about local parts.
どちらの場合も、電子メールアドレスに関連付けられているドメインが認証されているものです。試みは、ローカル部分を認証するために行われません。ドメインの所有者は、クライアントがドメイン内のアドレスに代わって話すどのSMTP決定するために取得します。責任あるドメインの所有者は、ローカル部品偽るするSMTPクライアントを許可すべきではありません。
In the long run, once the domain of the sender is authenticated, it will be possible to use that domain as part of a mechanism to determine the likelihood that a given message is spam, using, for example, reputation and accreditation services. (These services are not the subject of the present mechanism, but it should enable them.)
送信者のドメインが認証されると、長い目で見れば、与えられたメッセージは、例えば、評判と認定サービスを使用して、スパムである可能性を決定するためのメカニズムの一部としてそのドメインを使用することが可能になります。 （これらのサービスは、現在のメカニズムの対象ではないが、それは、それらを有効にする必要があります。）
Domains declare which hosts are and are not authorized to transmit e-mail messages on their behalf by publishing Sender Policy Framework (SPF) records in the Domain Name System. [RFC4408] defines a format for these records identified by the version prefix "v=spf1". This section defines an amended format, identified by the version prefix "spf2.0", that allows sending domains to explicitly specify how their records should be interpreted, and provides for additional extensibility. Sending domains MAY publish either or both formats.
ドメインがあり、SPF（Sender Policy Framework）をドメインネームシステム内のレコードを公開することにより自分に代わって電子メールメッセージを送信することを許可されていないホストを宣言します。 [RFC4408]は、バージョンプレフィックス「V = SPF1」によって識別されるこれらのレコードのフォーマットを定義します。このセクションでは、明示的に自分の記録をどのように解釈するかを指定するには、ドメインを送ることができますし、追加の拡張性を提供し、バージョンプレフィックス「spf2.0」で識別される改正フォーマットを、定義されています。送信ドメインは、いずれか、または両方のフォーマットを公開してもよい（MAY）。
Since the two formats are identical in most respects, the following subsections define the "spf2.0" format relative to [RFC4408].
二つのフォーマットは、ほとんどの点で同じであるので、以下のサブセクションでは、[RFC4408]に対して「spf2.0」フォーマットを定義します。
Under Sender ID, receiving domains may perform a check of either the PRA identity or the MAIL-FROM identity. Sending domains therefore require a method for declaring whether their published list of authorized outbound e-mail servers can be used for the PRA check, the MAIL-FROM check, or both.
送信者IDの下で、受信したドメインは、PRAの同一またはメールからIDのいずれかのチェックを行うことができます。ドメインを送信するため、許可された送信電子メールサーバの自分の公表リストは、PRAチェック、MAIL FROM-チェック、またはその両方のために使用することができるかどうかを宣言するための方法が必要です。
This section replaces the definition of the version identifier in Section 4.5 of [RFC4408] and adds the concept of SPF record scopes.
このセクションでは、[RFC4408]のセクション4.5にバージョン識別子の定義を置き換え、SPFレコードスコープの概念が追加されます。
SPF records begin with a version identifier and may also include a scope:
SPFレコードは、バージョン識別子で始まり、また範囲を含むこともできます。
record = version terms *SP version = "v=spf1" | ( "spf2." ver-minor scope) ver-minor = 1*DIGIT scope = "/" scope-id *( "," scope-id ) scope-id = "mfrom" / "pra" / name
記録=バージョン条件* SPバージョン= "V = spf1レコード" | （ "SPF2。" 版、マイナー範囲）版-マイナー= 1 * DIGITスコープ= "/" スコープのID *（ "" スコープID）スコープID = "mfrom" / "PRA" /名前
For example, the SPF record
たとえば、SPFレコード
spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all
spf2.0 / mfrom、PRA + MX + IP4：192.168.0.100 -all
defines an SPF record that can be used for either MAIL FROM or PRA checks.
FROM MAILまたはPRAチェックのどちらにも使用することができるSPFレコードを定義します。
This document only defines the existence of two scopes: "mfrom" and "pra". The details of these two scopes are defined in other documents: "mfrom" is defined in [RFC4408]; "pra" is defined in [RFC4407].
「mfrom」と「PRA」：この文書では、唯一の2つのスコープが存在することを定義します。これらの2つのスコープの詳細は他のドキュメントで定義されています。「mfromは」[RFC4408]で定義されています。 "PRA" [RFC4407]で定義されています。
Other scopes may be defined by future documents only. There is no registry for scopes. A scope definition must define what it identifies as the sending mailbox for a message, how to extract that information from a message, how to determine the initial arguments for the check_host() function, and what the compliant responses to the result are. This ensures that domains with published records and mail receiver agree on the semantics of the scope.
他のスコープは、将来の文書によって定義することができます。スコープのためのレジストリはありません。スコープ定義ははcheck_host（）関数の最初の引数を決定する方法を、メッセージからの情報を抽出する方法、それはメッセージの送信メールボックスとして識別するかを定義し、どのような結果に準拠応答である必要があります。これは、公開されたレコードとメール受信を持つドメインはスコープのセマンティクスに同意することを保証します。
A compliant domain SHOULD publish authorizations for every defined scope.
準拠したドメインは、すべての定義されたスコープの権限を公開する必要があります。
All published records that use the "spf2" version identifier MUST start with "spf2.0". This document only specifies records with a minor version of "0".
「SPF2」バージョン識別子を使用するすべての出版されたレコードは、「spf2.0」で開始する必要があります。この文書では、唯一の「0」のマイナーバージョンのレコードを指定します。
Future versions of this document may define other minor versions to be used.
このドキュメントの将来のバージョンでは、使用する他のマイナーバージョンを定義することができます。
A domain MAY publish multiple SPF 2.0 records, provided that each scope appears in at most one SPF 2.0 record. In addition, a domain MAY also publish an SPF record that uses the "v=spf1" version identifier defined in [RFC4408]. The selection rules in Section 4.4 define the precedence of these records.
ドメインが複数のSPF 2.0レコードを公開することが、各スコープは、多くても1つのSPFレコードを2.0にで表示されていることを提供します。また、ドメインには、[RFC4408]で定義された「V = spf1レコード」バージョン識別子を使用してSPFレコードを公開してもよい（MAY）。 4.4節での選択ルールは、これらのレコードの優先順位を定義します。
This section replaces Section 4.6.3 of [RFC4408] and adds the concept of positional modifiers.
このセクションでは、[RFC4408]のセクション4.6.3を置き換え、位置修飾子の概念が追加されます。
Modifiers are key/value pairs that affect the evaluation of the check_host() function.
修飾子ははcheck_host（）関数の評価に影響を与えるキー/値のペアです。
Modifiers are either global or positional:
修飾子は、グローバルまたは位置のどちらかであります：
Global modifiers MAY appear anywhere in the record, but SHOULD appear at the end, after all mechanisms and positional modifiers.
グローバル修飾子は、どこでも、レコードに表示される場合がありますが、すべてのメカニズムと位置修飾した後、最後に表示される必要があります。
Positional modifiers apply only to the mechanism they follow. It is a syntax error for a positional modifier to appear before the first mechanism.
位置修飾子は、彼らが従う機構にのみ適用されます。これは、最初のメカニズムの前に表示されるように、位置修飾子の構文エラーです。
Modifiers of either type are also either singular or multiple:
どちらのタイプの修飾子も、単数または複数のいずれかです：
Singular modifiers may appear only once in the record if they are global, or once after each mechanism if they are positional.
彼らはグローバルである場合、または各機構の後に一度、彼らが位置している場合、単数修飾子はレコードに一度だけ表示されることがあります。
Multiple modifiers may appear multiple times in the record if they are global, or multiple times after each mechanism if they are positional.
彼らは、位置している場合、彼らは各機構の後にグローバル、または複数回ある場合、複数の修飾子は、レコード内で複数回表示されることがあります。
A modifier is not allowed to be defined as both global and positional.
修飾子は、グローバル及び位置の両方として定義することを許可されていません。
The modifiers "redirect" and "exp" described in Section 6 of [RFC4408] are global and singular.
[RFC4408]のセクション6で説明修飾子「リダイレクト」と「EXP」は、グローバルと特異です。
Ordering of modifiers does not matter, except that:
修飾子の順序はことを除いて、重要ではありません。
1. positional modifiers must appear after the mechanism they affect and before any subsequent mechanisms; and
1.位置修飾子は、彼らが影響を与えるメカニズムの後およびその後のメカニズムの前に現れなければなりません。そして
2. when a multiple modifier appears more than one time, the ordering of the appearances may be significant to the modifier.
複数の修飾子が複数回表示されたとき2.出現順序は修飾に重要であり得ます。
Other than these constraints, implementations MUST treat different orders of modifiers the same. An intended side effect of these rules is that modifiers cannot be defined that modify other modifiers.
これらの制約以外に、実装は同じ修飾子の異なる順序を扱わなければなりません。これらの規則の意図的な副作用は、改質剤は、他の修飾子を変更するように定義することができないことです。
These rules allow an implementation to correctly pre-parse a record. Furthermore, they are crafted to allow the parsing algorithm to be stable, even when new modifiers are introduced.
これらのルールは、実装が正しくレコードを事前に解析することができます。さらに、彼らは新しい修飾子が導入された場合でも、構文解析アルゴリズムが安定していることができるように作られています。
Modifiers that are unrecognized MUST be ignored. This allows older implementations to handle records with modifiers that were defined after they were written.
認識されていない修飾子は無視しなければなりません。これは、古い実装は、それらが書かれた後に定義された修飾子を持つレコードを処理することができます。
Domain administrators complying with this specification are required to publish information in DNS regarding their authorized outbound e-mail servers. [RFC4408] describes a format for this information identified by the version prefix "v=spf1". Many domains have published information in DNS using this format. In order to provide compatibility for these domains, Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.
この仕様に準拠するドメイン管理者は、その許可された送信電子メールサーバに関するDNSに情報を公開するために必要とされています。 [RFC4408]は、バージョンプレフィックス「V = SPF1」により識別情報の形式を記述する。多くのドメインが、この形式を使用してDNSの情報を公開しています。これらのドメインの互換性を提供するために、送信者IDの実装は、「spf2.0 / mfrom、PRA」に相当するようバージョンプレフィックス「V = SPF1」を解釈すべき、「spf2.0」で始まるないレコード存在しません。
Administrators who have already published "v=spf1" records SHOULD review these records to determine whether they are also valid for use with PRA checks. If the information in a "v=spf1" record is not correct for a PRA check, administrators SHOULD publish either an "spf2.0/pra" record with correct information or an "spf2.0/pra ?all" record indicating that the result of a PRA check is explicitly inconclusive.
すでに「V = spf1レコード」レコードを公開している管理者は、彼らがPRAチェックを使用するためにも有効であるかどうかを判断するためにこれらのレコードを確認する必要があります。 「V = spf1レコード」レコードの情報は、PRAチェックのために正しくない場合、管理者は正しい情報で「spf2.0 / PRA」レコードまたは示す「spf2.0 / PRA？すべて」のレコードのいずれかを発行しなければならないことPRAチェックの結果は、明示的に決定的です。
Sender ID enables receiving e-mail systems to answer the following question:
送信者IDは、次の質問に答えるために電子メールシステムを受信可能にします。
Given an e-mail message, and given an IP address from which it has been (or will be) received, is the SMTP client at that IP address authorized to send that e-mail message?
電子メールメッセージを考えると、それがされている（または予定）、そこからIPアドレスを与え受け、その電子メールメッセージを送信する権限を与えているIPアドレスのSMTPクライアントですか？
This question will usually be asked by an SMTP server as part of deciding whether to accept an incoming mail message. However, this question could also be asked later by a different party. An MUA, for example, could use the result of this question to determine how to file or present a message.
この質問は、通常、受信メールメッセージを受け入れるかどうかを判断する際の一部としてSMTPサーバーによって要求されます。しかし、この質問は、異なる当事者が後で求められることができました。 MUAは、例えば、ファイルまたはメッセージを提示する方法を決定するために、この質問の結果を使用することができます。
There are three steps to answering this question:
この質問に答えるには3つのステップがあります。
1. From an e-mail message, extract the address to verify. The PRA variant of this test does so as specified in [RFC4407], or alternatively, using the submitter address as specified in [RFC4405]. The MAIL FROM variant of this test does so as specified in [RFC4408].
電子メールメッセージから、[検証するアドレスを抽出します。 [RFC4405]で指定されるようにサブミッター・アドレスを使用して、代わりに[RFC4407]で指定された、又はように、このテストのPRAバリアントはありません。この試験の変異体からのメールは[RFC4408]で指定されたように行います。
3. Call the check_host() function defined in [RFC4408] and modified by the following subsections.
3. [RFC4408]で定義はcheck_host（）関数を呼び出して、以下のサブセクションにより修飾。
If the Sender ID check is being performed by an MTA as part of receiving an e-mail message, and it cannot determine an address in step 1 above (because the message or address is malformed), then the message SHOULD be rejected with error "550 5.7.1 Missing Purported Responsible Address" or error "550 5.7.1 Missing Reverse-Path address".
送信者IDチェックが電子メールメッセージを受信するの一部としてMTAによって実行され、（メッセージまたはアドレスが不正であるため）、それは上記のステップ1のアドレスを判別できない場合、メッセージは、「エラーで拒絶されるべき550 5.7.1は主張責任アドレス」またはエラー 『550 5.7.1欠落リバースパスアドレスを』行方不明。
Sender ID modifies the check_host() function by the addition of a scope parameter. Thus, for Sender ID the check_host() function is called passing the following parameters:
送信者IDは、スコープパラメータの添加によってはcheck_host（）関数を修正します。したがって、送信者IDのためにはcheck_host（）関数は、以下のパラメーターを渡すと呼ばれます。
a. A scope of "pra" (for the PRA variant of the test), or "mfrom" (for the MAIL FROM variant of the test). b. The IP address (either IPv4 or IPv6) from which the message is being or has been received. c. The domain from step 2 above. d. The address from step 1 above.
A。 （試験のPRA変異体の場合）、「PRA」の範囲、又は（試験のバリアントFROMメールの）「mfrom」。 B。 IPアドレス（IPv4またはIPv6）メッセージがあるか、または受信されました。 C。上記ステップ2からのドメイン。 D。上記ステップ1からのアドレス。
The result of the check_host() function is one of the values "Neutral", "Pass", "Fail", "SoftFail", "None", "TempError", or "PermError". Section 5 describes how these results are used by MTAs receiving messages. This specification imposes no requirements on parties performing this test in other environments.
check_host（）関数の結果は、「合格」、「失敗」、「Softfailは」、「なし」、「TempError」、または「PermErrorという」「中立」のいずれかの値です。第5節では、これらの結果は、メッセージの受信のMTAによって使用されている方法を説明します。この仕様は、他の環境でこのテストを実行し、当事者には何の要件を課していません。
SPF records are looked up in DNS in accordance with Section 4.4 of [RFC4408].
SPFレコードは、[RFC4408]のセクション4.4に従ってDNSで検索されています。
When performing the PRA version of the test, if the DNS query returns "non-existent domain" (RCODE 3), then check_host() exits immediately with the result "Fail".
テストのPRAのバージョンを実行する場合、DNSクエリが「存在しないドメイン」（RCODE 3）を返す場合、その後はcheck_host（）は、結果「失敗」とすぐに終了します。
This section replaces the record selection steps described in Section 4.5 of [RFC4408].
このセクションでは、[RFC4408]のセクション4.5で説明したレコード選択手順を置き換えます。
Starting with the set of records that were returned by the lookup, record selection proceeds in these steps:
検索によって返されたレコードのセットから始めて、次の手順でレコード選択が進行します：
1. If any records of type SPF are in the set, then all records of type TXT are discarded.
1.型SPFのすべてのレコードをセットにしている場合は、タイプTXTのすべてのレコードは破棄されます。
2. Records that do not begin with proper version and scope sections are discarded. The version section for "spf2" records contains a ver-minor field that is for backward-compatible future extensions. This field must be well formed for a record to be retained, but is otherwise ignored.
適切なバージョンとスコープセクションで始まらない2レコードは破棄されます。 「SPF2」レコードのバージョンセクションは、下位互換性が将来の拡張のためにある版 - マイナーなフィールドが含まれています。このフィールドはよく保持するレコードのために形成されなければならないが、それ以外は無視されます。
3. Records that use the "spf2" version identifier and do not have a scope-id that matches <scope> are discarded. Note that this is a complete string match on the scope-id tokens: If <scope> is "pra", then the record starting "spf2.0/mfrom,prattle,fubar" would be discarded, but a record starting "spf2.0/mfrom,pra,fubar" would be retained.
「SPF2」バージョン識別子を使用して、<スコープ>が破棄されると一致するスコープIDをお持ちでない場合3.レコード。これはスコープ-IDトークンの完全な文字列の一致であることに注意してください：<スコープ>が「PRA」であれば、記録開始は「spf2.0 / mfrom、喋る、めちゃくちゃは」破棄されますが、レコードは「SPF2を開始します。 0 / mfrom、PRA、めちゃくちゃは」保持されます。
4. If the lookup returned two records, one containing the "v=spf1" version identifier and the other containing the "spf2" version identifier, the "spf2" version takes precedence for the desired scope-id. If the "spf2" record does not contain the desired scope-id, then the "v=spf1" record is selected.
4.ルックアップは、2つのレコード、「V = SPF1」バージョン識別子と「SPF2」バージョン識別子を含むその他を含むものを返した場合は、「SPF2」バージョンは、所望の範囲-IDのために優先されます。 「SPF2」レコードは、所望の範囲-IDが含まれていない場合は、「V = SPF1」のレコードが選択されます。
5. If an "spf2" record does not contain the desired scope-id and there is no "v=spf1" record for the domain, then no record is selected.
5.「SPF2」レコードは、所望の範囲-IDが含まれていないドメインには「V = SPF1」のレコードが存在しない場合、何のレコードが選択されていません。
After the above steps, there should be one record remaining and evaluation can proceed. If there are two or more records remaining, then check_host() exits immediately with the error "PermError".
上記の手順の後、そこに一つのレコードが残っているべきであるとの評価を進めることができます。残りの2つの以上のレコードがある場合、はcheck_host（）はエラー「PermErrorという」とすぐに終了します。
If there are no matching records remaining after the initial DNS query or any subsequent optional DNS queries, then check_host() exits immediately with the result "None".
最初のDNSクエリまたはそれ以降のオプションのDNSクエリ後に残っ一致するレコードがない場合、はcheck_host（）は、結果「なし」とすぐに終了します。
When the Sender ID test is used by an SMTP server as part of receiving a message, the server should take the actions described by this section.
送信者IDテストがメッセージを受信するの一部として、SMTPサーバによって使用されている場合、サーバは、このセクションによって記述行動をとるべきです。
The check_host() function returns one of the following results. See [RFC4408] for the meaning of these results.
check_host（）関数は、以下の結果のいずれかを返します。これらの結果の意味については、[RFC4408]を参照してください。
An SMTP server receiving one of these results SHOULD NOT reject the message for this reason alone, but MAY subject the message to heightened scrutiny by other measures, and MAY reject the message as a result of this heightened scrutiny.
これらの結果のうちの1つを受信するSMTPサーバはこの理由だけのためにメッセージを拒否してはならず、他の措置によって高め精査にメッセージを施すことができ、この高め精査の結果としてメッセージを拒否するかもしれません。
Such additional security measures MAY take into account that a message for which the result is "SoftFail" is less likely to be authentic than a message for which the result is "Neutral".
このような追加のセキュリティ対策は、結果が「Softfailはは」結果が「ニュートラル」であるため、メッセージより本物になりにくいですされているメッセージということを考慮に入れることができます。
An SMTP server receiving this result SHOULD treat the message as authentic. It may accept or reject the message depending on other policies.
この結果を受けたSMTPサーバは、本物のようなメッセージを扱うべきです。これは、他のポリシーに応じたメッセージを受け入れるか拒否することができます。
When performing the Sender ID test during an SMTP transaction, an MTA that chooses to reject a message receiving this result SHOULD reject the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error, where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced with the additional reason returned by the check_host() function, and "zzz" is replaced with the explanation string returned by the check_host() function.
「XXX」はSMTPエラー、 - SMTPトランザクション中に送信者のIDの検査を行う場合、この結果をメッセージ受信を拒否することを選択したMTAは、「ZZZ 550 5.7.1送信者ID（XXX）YYY」のメッセージを拒否すべきです「FROM MAIL」「PRA」またはに置き換え、「yyyが」はcheck_host（）関数によって返された追加の理由に置き換えられ、「ZZZ」とはcheck_host（）関数によって返された説明の文字列に置き換えられます。
When performing the Sender ID test after accepting an e-mail message for delivery, an MTA that chooses to reject a message receiving this result SHOULD NOT deliver the message. Instead, it should create a DSN message, consistent with the usual rules for DSN messages.
送達のための電子メールメッセージを受け入れた後に送信者IDの試験を行う場合、この結果をメッセージ受信を拒否することを選択したMTAは、メッセージを配信すべきではありません。その代わりに、DSNメッセージの通常の規則と一致DSNメッセージを、作成する必要があります。
An SMTP server receiving this result MAY reject the message with a "450 4.4.3 Sender ID check is temporarily unavailable" error code. Alternatively, an SMTP server receiving this result MAY accept a message and optionally subject it to heightened scrutiny by other anti-spam measures.
エラーコード「450 4.4.3 Sender IDのチェックが一時的に使用できない」と、この結果を受けたSMTPサーバはメッセージを拒否するかもしれません。代替的に、この結果を受けたSMTPサーバは、他のアンチスパム対策によって高め精査にメッセージおよび任意被写体を受け入れることができます。
This entire document describes a new mechanism for mitigating spoofed e-mail, which is today a pervasive security problem in the Internet.
この全体のドキュメントはインターネットで普及し、セキュリティの問題、今日で偽装された電子メールを、軽減するための新しいメカニズムを説明しています。
Assuming that this mechanism is widely deployed, the following sections describe counter attacks that could be used to defeat this mechanism.
このメカニズムが広く展開されているとすると、次のセクションでは、このメカニズムを打ち負かすために使用できるカウンター攻撃を記述する。
The new mechanism is entirely dependent on DNS lookups, and is therefore only as secure as DNS. An attacker bent on spoofing messages could attempt to get his messages accepted by sending forged answers to DNS queries.
新機構は、DNSルックアップに完全に依存しているので、DNSと同じくらい安全です。なりすましメッセージの攻撃を曲げ、彼のメッセージは、DNSクエリに偽造の回答を送信することによって、受け入れを取得しようとする可能性があり。
An MTA could largely defeat such an attack by using a properly paranoid DNS resolver. DNS Security (DNSSEC) may ultimately provide a way to completely neutralize this class of attacks.
MTAは、大部分が適切に偏執的DNSリゾルバを使用することによって、このような攻撃を打ち負かすことができます。 DNSセキュリティ（DNSSEC）は、最終的には完全に攻撃のこのクラスを中和する方法を提供することができます。
This mechanism is designed to be used in conjunction with SMTP over TCP. A sufficiently resourceful attacker might be able to send TCP packets with forged from-addresses, and thus execute an entire SMTP session that appears to come from somewhere other than its true origin.
このメカニズムは、TCP上のSMTPと組み合わせて使用するように設計されています。十分に機知に攻撃者から-アドレスを偽造してTCPパケットを送信することができ、したがって、その真の起源以外のどこから来るように見える全体のSMTPセッションを実行する可能性があります。
Such an attack requires guessing what TCP sequence numbers an SMTP server will use. It also requires transmitting completely in the blind -- the attack will be unable to hear any of the server's side of the conversation.
このような攻撃はSMTPサーバが使用するどのようなTCPシーケンス番号を推測する必要があり。また、ブラインドで完全に送信する必要が - 攻撃は、会話のサーバの側のいずれかを聞くことができなくなります。
Attacks of this sort can be ameliorated if IP gateways refuse to forward packets when the source address is clearly bogus.
IPゲートウェイは、送信元アドレスは明らかに偽のときにパケットを転送することを拒否する場合は、この種の攻撃を改善することができます。
This mechanism chooses an address to validate either from one of a number of message headers or from the RFC 2821 MAIL command, and then uses that address for validation. A message with a true Resent-From header or Return-Path, but a forged From header, will be accepted. Since many MUAs do not display all of the headers of received messages, the message will appear to be forged when displayed.
この機構は、メッセージヘッダーのうちの1つから、またはRFC 2821 MAILコマンドからいずれか検証するアドレスを選択し、その後の検証のためにそのアドレスを使用します。真憤慨-からヘッダから鍛造ヘッダまたはリターンパス、しかし、受け入れられるとメッセージ。多くのMUAは、受信したメッセージのヘッダのすべてが表示されませんので、メッセージが表示されるときに偽造されるように表示されます。
In order to neutralize this attack, MUAs will need to start displaying at least the address that was verified. In addition, MTAs could subject messages to heightened scrutiny when the validated address differs from the From header.
この攻撃を中和するためには、のMUAは少なくとも確認されたアドレスの表示を開始する必要があります。検証アドレスからヘッダと異なる場合に加えて、MTAが高く精査にメッセージを施すことができました。
This mechanism assumes the integrity of IP address space for determining whether a given client is authorized to send messages from a given PRA. In addition to the TCP attack given in Section 6.2, a sufficiently resourceful attacker might be able to alter the IP routing structure to permit two-way communication using a specified IP address. It would then be possible to execute an SMTP session that appears to come from an authorized address, without the need to guess TCP sequence numbers or transmit in the blind.
このメカニズムは、特定のクライアントが与えられたPRAからメッセージを送信することを許可されているかどうかを判断するためのIPアドレス空間の整合性を前提としています。 6.2節で与えられたTCP攻撃に加えて、十分に機知に攻撃者が指定したIPアドレスを使用して双方向通信を可能にするために、IPルーティング構造を変更することができるかもしれません。その後、TCPシーケンス番号を推測するか、ブラインドに送信する必要なしに、許可されたアドレスから来るように見えるSMTPセッションを実行することが可能であろう。
Such an attack might occur if the attacker obtained access to a router that participates in external BGP routing. Such a router could advertise a more specific route to a rogue SMTP client, temporarily overriding the legitimate owner of the address.
攻撃者は、外部BGPルーティングに参加するルータへのアクセスを取得した場合には、このような攻撃が発生する可能性があります。このようなルータは、一時的にアドレスの正当な所有者をオーバーライドし、不正なSMTPクライアントに、より具体的なルートをアドバタイズできます。
There is class of attacks in which an attacker A can entice a participant P to send a malicious message to a victim V.
攻撃者Aは、被害者Vに悪質なメッセージを送信するために参加者Pを誘惑することができている攻撃のクラスがあります
These attacks are undertaken by A citing the address of V in the SMTP MAIL FROM request and then by causing P to generate (or invoke the generation of) a Delivery Status Notification 'bounce' message (RFC3464), which is sent to the victim V.
これらの攻撃は、被害者Vに送られるPが生成（又は発生を起動）させることにより、要求からSMTPメールにVのアドレスを引用配信状態通知「バウンス」メッセージ（RFC3464）によって行われます。
The attacker relies upon it being common practice to copy the original message into the 'bounce' report, thereby causing the malice to be sent onward to V.
攻撃者はこれにより、悪意がVに以降送信される原因と、それは「バウンス」レポートに元のメッセージをコピーするのが一般的であることに依存しています
This mode of attack has the advantages (to the attacker) of obfuscating the location of the host from which the attack was mounted, and of possibly damaging the reputation of P by making it appear that P originated or was an active participant in the sending of the malicious message.
攻撃のこのモードは、攻撃が搭載されたホストの位置を難読化する（攻撃者）に利点を有しており、おそらくPが発信または送信に積極的に参加したことを表示させることによりPの評判を損傷します悪質なメッセージ。
In current practice, A causes P to cause the 'bounce' by addressing the original message to a nonexistent recipient.
現在実際には、Aは、Pが存在しない受信者に元のメッセージをアドレス指定することにより、「バウンス」を引き起こす原因となります。
Sender ID enables a new variant of this attack.
送信者IDは、この攻撃の新しい変種を可能にします。
In this variant, the attacker A sends a message whose PRA (Section 4) is selected by the attacker to be such that, when P undertakes the Sender ID test, a Fail will result (Section 5.3).
この変形例では、Aは、PRA（第4章）メッセージを送信する攻撃者は、Pは、送信者IDの試験を行っていた場合に、失敗する（セクション5.3）をもたらすようなもので、攻撃者によって選択されます。
The message will be rejected (as the attacker intended) and a malicious 'bounce' message may be generated and sent to the victim V.
（攻撃者が意図したように）メッセージが拒否され、悪質な「バウンス」というメッセージが生成され、被害者Vに送ることができます
This section describes the actions that certain members of the Internet e-mail ecosystem must take to be compliant with this specification.
このセクションでは、インターネット電子メールのエコシステムの特定のメンバーは、この仕様に準拠するために取らなければならないというアクションについて説明します。
A domain that injects original e-mail into the Internet, using its own name in From headers, need do nothing to be compliant. However, such domains SHOULD publish records in DNS as defined by [RFC4408] and this specification.
Fromヘッダー内に独自の名前を使用して、インターネットに元の電子メールを注入ドメインは、準拠するように何もしない必要があります。 [RFC4408]及び本明細書で定義されているようしかし、そのようなドメインがDNSレコードを公開するべきです。
In the majority of cases, the domain's published information will be the same for both the PRA and MAIL FROM variants of this test. In this case, domains SHOULD publish their information using an SPF record with the prefix "v=spf1". Doing so will render their published information usable by the older SPF protocol, too. (See [RFC4408] for information on the SPF protocol.)
ほとんどの場合、ドメインの公開情報は、PRAと、このテストのバリエーションFROM MAILの両方で同じになります。この場合、ドメインは、接頭辞「V = spf1レコード」とSPFレコードを使用して、その情報を公開すべきです。そうすることは、あまりにも、古いSPFプロトコルによるそれらの公開されている情報は、使用可能なレンダリングされます。 （SPFプロトコルについては、[RFC4408]を参照）。
In order to pass the PRA variant of the test, a program that forwards received mail to other addresses MUST add an appropriate header that contains an e-mail address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose.
試験のPRA変異体を通過するために、転送は、他のアドレスにメールを受信した番組は、使用を許可されている電子メールアドレスを含む適切なヘッダーを追加しなければなりません。このようなプログラムは、この目的のためのResent-からヘッダを使用すべきです。
In order to pass the MAIL FROM variant of the test, a program that forwards received mail to other addresses MUST alter the MAIL FROM address to an address under its control. Should that address eventually receive a DSN relating to the original message, that DSN SHOULD be forwarded to the original MAIL FROM address. However, if this altered address receives any messages other than DSNs related to the original message, these messages MUST NOT be forwarded to the original MAIL FROM address; they SHOULD be refused during an SMTP transaction.
試験の変異体からのメールを通過するために、転送は、他のアドレスにメールを受信したプログラムは、その制御下のアドレスにアドレスからのメールを変更しなければなりません。そのアドレスは、最終的に元のメッセージに関連するDSNを受けるべきで、そのDSNは、アドレスから元のMAILに転送する必要があります。この改変されたアドレスは、元のメッセージに関連のDSN以外のメッセージを受信した場合は、これらのメッセージは、アドレスから元のメールに転送されてはいけません。彼らは、SMTPトランザクションの間に拒否されるべきです。
In addition, e-mail forwarders SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result.
また、電子メールフォワーダは、そのドメインの送信者IDレコードを公開する必要があり、送信者IDチェックが「合格」の結果が得られたためのMTAを使うべきです。
Some of today's forwarders already add an appropriate header (although many of them use Sender rather than Resent-From.) Most of them do not perform the address-rewriting specified above.
（それらの多くはではなく、送信者を使用するが、憤慨し-から。）今日のフォワーダのいくつかは、すでに適切なヘッダを追加し、それらのほとんどは、アドレス書き換え上で指定を行わないでください。
Note that an e-mail forwarder might receive a single message for two or more recipients, each of whom requests forwarding to a new address. In this case, the forwarder's MTA SHOULD transmit the message to each new recipient individually, with each copy of the message containing a different newly inserted Resent-From header field.
電子メールフォワーダが新しいアドレスに転送を要求し、それぞれの人の2人以上の受信者のための単一のメッセージを受け取る場合があります。この場合、フォワーダのMTAは、異なる新たに挿入された憤慨-からヘッダフィールドを含むメッセージの各コピーと共に、個々にそれぞれの新しい受信者にメッセージを送信しなければなりません。
In order to pass the PRA variant of the test, a mailing list server MUST add an appropriate header that contains an e-mail address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose.
試験のPRA変異体を通過するために、メーリングリストサーバは、使用を許可されている電子メールアドレスを含む適切なヘッダーを追加しなければなりません。このようなプログラムは、この目的のためのResent-からヘッダを使用すべきです。
In order to pass the MAIL FROM variant of the test, a mailing list server MUST alter the MAIL FROM address to an address under its control.
テストのバリアントからのメールを渡すために、メーリングリストサーバは、その制御下のアドレスにMAIL FROMアドレスを変更する必要があります。
In addition, mailing list servers SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result.
また、メーリングリストサーバは、そのドメインの送信者IDレコードを公開する必要があり、送信者IDチェックが「合格」の結果が得られたためのMTAを使うべきです。
Most of today's mailing list software already adds an appropriate header (although most of them use Sender rather than Resent-From), and most of them already alter the MAIL FROM address.
今日のメーリングリストソフトウェアのほとんどは、すでに（それらのほとんどは、かなりのResent-からよりも送信者を使用するが）適切なヘッダを追加し、それらのほとんどは、すでにアドレスからのメールを変えます。
In order to pass the PRA variant of this test, a program that sends mail on behalf of another user MUST add an appropriate header that contains an e-mail address that it is authorized to use. Such programs SHOULD use the Sender header for this purpose.
この試験のPRA変異体を通過するために、別のユーザーに代わってメールを送信するプログラムは、使用を許可されている電子メールアドレスを含む適切なヘッダーを追加しなければなりません。そのようなプログラムは、この目的のために送信者ヘッダを使用すべきです。
In order to pass the MAIL FROM variant of this test, a program that sends mail on behalf of another user MUST use a MAIL FROM address that is under its control. Defining what the program does with any mail received at that address is beyond the scope of this document.
このテストのバリアントからのメールを渡すためには、別のユーザーに代わってメールを送信するプログラムは、その制御下にあるアドレスからのメールを使用しなければなりません。プログラムは、そのアドレスで受信したすべてのメールに何をするか定義することは、このドキュメントの範囲を超えています。
In addition, third-party mailers, servers SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result.
また、サードパーティ製のメーラー、サーバは、そのドメインの送信者IDレコードを公開する必要があり、送信者IDチェックが「合格」の結果が得られたためのMTAを使うべきです。
Many, but not all, of today's third-party mailers are already compliant with the PRA variant of the test. The extent to which mailers are already compliant with the MAIL FROM variant of this test is unknown.
多くの、すべてではありませんが、今日のサードパーティ製メーラーのは、すでにテストのPRAバリアントに準拠しています。メーラーは既にこのテストの変形FROM MAILに準拠している程度は不明です。
When displaying a received message, an MUA SHOULD display the purported responsible address as defined by this document whenever that address differs from the RFC 2822 From address. This display SHOULD be in addition to the RFC 2822 From address.
受信したメッセージを表示する際にそのアドレスがアドレスからRFC 2822と異なるときはいつでも、この文書によって定義されるように、MUAを主張責任アドレスが表示されます。この表示は、FromアドレスRFC 2822に加えて、あるべきです。
When a received message contains multiple headers that might be used for the purported responsible address determination, an MUA should consider displaying all of them. That is, if a message contains several Resent-From's, a Sender, and a From, an MUA should consider displaying all of them.
受信したメッセージが主張責任アドレス決意のために使用されるかもしれない複数のヘッダが含まれている場合、MUAはそれらのすべてを表示する検討すべきです。メッセージは、いくつかのからのResent-、送信者、およびから、Aが含まれている場合には、MUAはそれらのすべてを表示する検討すべきです。
Sender ID also does not validate the display name that may be transmitted along with an e-mail address. The display name is also vulnerable to spoofing and other forms of attacks. In order to reduce the occurrence and effectiveness of such attacks, MUA implementers should consider methods to safeguard the display name. This could include the following:
送信者IDは、電子メールアドレスと一緒に送信することができる表示名を検証しません。表示名は、なりすましや攻撃の他の形態に対して脆弱です。このような攻撃の発生と有効性を減少させるために、MUAの実装は、表示名を保護するための方法を検討すべきです。これは、次を含めることができます：
* Not presenting the display name to the user at all, or not presenting the display name unless the corresponding e-mail address is listed in the user's address book.
*は、すべてのユーザーに表示名を提示していない、または対応するメールアドレスがユーザーのアドレス帳に記載されていない限り、表示名を提示していません。
* Treating as suspicious any e-mail where the display name is itself in the form of an e-mail address, especially when it differs from the actual e-mail address in the header.
*表示名は、それがヘッダの実際の電子メールアドレスと異なる場合は特に、電子メールアドレスの形式でそれ自体であるような疑わしい任意の電子メールを扱います。
* Making it clear to users that the e-mail address has been checked rather than the display name.
*電子メールアドレスが表示名ではなく、チェックされていることをユーザーにそれが明確に作ります。
This design is based on earlier work published in 2003 in [RMX] and [DMP] drafts (by Hadmut Danisch and Gordon Fecyk, respectively). The idea of using a DNS record to check the legitimacy of an e-mail address traces its ancestry to "Repudiating Mail From" draft by Paul Vixie [Vixie] (based on suggestion by Jim Miller) and to "Domain-Authorized SMTP Mail" draft by David Green [Green], who first introduced this idea on the namedroppers mailing list in 2002.
この設計は、先に[RMX]で2003年に出版され、仕事と（それぞれHadmutデンマークの特許とゴードンFecykことにより、）[DMP]ドラフトに基づいています。電子メールアドレスの正当性を確認するためにDNSレコードを使用してのアイデアは、（ジム・ミラーの提案に基づいて）ポール・ヴィクシー[いるVixie]による草案「から否認メール」の祖先へのトレースと「ドメイン認可SMTPメール」へ最初の2002年にnamedroppersメーリングリストでこのアイデアを紹介デビッド・グリーン[緑]、によってドラフト。
The current document borrows heavily from each of the above, as well as earlier versions of [RFC4408] and [CallerID], and incorporates ideas proposed by many members of the MARID working group. The contributions of each of the above are gratefully acknowledged.
現在の文書には、上記のそれぞれから重く借りて、だけでなく、[RFC4408]と[発信者番号]の以前のバージョン、および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月。
[RFC4405] Allman E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, April 2006.
[RFC4405]オールマンE.およびH.カッツ、「電子メールメッセージの責任提出者を示すためのSMTPサービス拡張」、RFC 4405、2006年4月。
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[RFC4407]リヨン、J.、 "Eメールメッセージで主張責任アドレス"、RFC 4407、2006年4月。
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail", RFC 4408, April 2006.
"E-Mailでのドメインの認可使用のためのSPF（Sender Policy Framework）を" [RFC4408]ウォン、M.およびW. Schlitt、RFC 4408、2006年4月。
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical Specification, http://www.microsoft.com/mscorp/safety/ technologies/senderid/resources.mspx
[発信者番号]マイクロソフトコーポレーション、Eメール技術仕様、http://www.microsoft.com/mscorp/safety/技術の発信者ID / SenderIDの/ resources.mspx
[DMP] Fecyk, G., "Designated Mailers Protocol", http://www.pan-am.ca/dmp/draft-fecyk-dmp-01.txt, December 2003.
[DMP] Fecyk、G.、 "指定メーラー議定書"、http://www.pan-am.ca/dmp/draft-fecyk-dmp-01.txt、2003年12月。
[Green] David Green, "Mail-Transmitter RR", http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00656.html, June 2002.
[緑]デヴィッド・グリーン、 "メール送信RR"、http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00656.html、2002年6月。
[RMX] H. Danisch, "The RMX DNS RR and method for lightweight SMTP sender authorization", http://www.danisch.de/work/security/txt/ draft-danisch-dns-rr-smtp-04.txt
[RMX] H.デンマークの特許、 "RMX DNS RRと軽量SMTP送信者認証のための方法"、http://www.danisch.de/work/security/txt/ドラフト - デンマークの特許-DNS-RR-SMTP-04.txt
[Vixie] Paul Vixie, "Repudiating Mail From", http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00658.html, June 2002.
[いるVixie]ポール・ヴィクシー、 "から否認メール"、http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00658.html、2002年6月。
Authors' Addresses
著者のアドレス
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
じｍ ょん みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: jimlyon@microsoft.com
メールアドレス：jimlyon@microsoft.com
Meng Weng Wong Singapore
孟ウェン・ウォン、シンガポール
EMail: mengwong@dumbo.pobox.com
メールアドレス：mengwong@dumbo.pobox.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）によって提供されます。