[要約] RFC 4406は、電子メールの送信者IDを認証するための仕様書であり、SPF（Sender Policy Framework）を定義しています。目的は、電子メールの送信者のドメインを偽装から保護し、スパムやフィッシングのリスクを軽減することです。
Network Working Group J. Lyon
Request for Comments: 4406 Microsoft Corp.
Category: Experimental M. Wong
pobox.com
April 2006
Sender ID: Authenticating E-Mail
送信者ID：電子メールの認証
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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として同時に公開されていますが、2つのアプローチを再構成する一般的な技術的コンセンサスと努力は失敗しています。そのため、これらのドキュメントは完全なIETFレビューを受け取っておらず、マリドワーキンググループで考慮されたさまざまなアプローチを文書化するために「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.
送信者ID実験は、この一連の実験で現在のSPF実験または以前のバージョンに作成された可能性のあるDNSレコードを使用する場合があることに注意してください。レコードの内容に応じて、これは、送信者-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.
送信者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.
Sender-ID実験の参加者は、res resting-*ヘッダーフィールドが使用される方法が、標準に準拠したシステム（特にresentを追加しないことで標準に準拠する自動転送業者に相互作用する際に正当な電子メールを受信できないことを認識する必要があります。*ヘッダー、およびRFC 822に準拠しているが、まだRFC 2822 Resent-* Semanticsを実装していないシステム。この相互運用性の問題を解決することなく、標準トラックで送信者-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）、および/またはメールユーザーエージェント（MUAS）が上記のカテゴリでメールを認識して適切なアクションを実行できるメカニズムについて説明します。たとえば、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.
インターネットの電子メールシステムのさらなる断片化を回避するために、インターネットコミュニティ全体で、メール送信者がメールを引き起こすために何をすべきか、そしてメール受信者がどのように決定すべきかについてコンセンサスに達することが望ましいですメールがスプーフィングされているかどうか。一方、メッセージがスプーフィングされると判断されたら、さまざまな当事者がとるアクションに関するコンセンサスに到達する必要はありません。これは一方的に行うことができます - あるエージェントは、スプーフィングされたメッセージを破棄することを決定する場合がありますが、別のエージェントは免責事項を追加することを決定します。
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]で定義されているように、メッセージの責任あるアドレス（PRA）を検証します。もう1つは、[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.
この仕様に準拠した電子メール送信者は、両方のテストの情報を公開し、送信されたメールが両方のテストに合格することを手配する必要があります。この仕様に準拠した電子メール受信機は、これらのテストの少なくとも1つを実行する必要があります。
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].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"[RFC2119]に記載されているように解釈されます。
Briefly stated, the mechanisms of this document allow one to answer the following question:
簡単に言えば、このドキュメントのメカニズムにより、次の質問に答えることができます。
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.
質問から見たように、このメカニズムは無関係な関係者に適用されます。これは、メッセージがインターネットを横切ってある組織から別の組織に通過する時点で役立ちます。組織内で展開できる認証メカニズムを説明するのは、このドキュメントの範囲を超えています。
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.
一方、テストのメールからのバージョンは、メッセージの配信ステータス通知（DSNSまたはバウンス）を受信するメールボックスを認証しようとしています。簡単な場合、これもメールの出身です。ただし、サードパーティのメーラー、フォワーダー、メーリングリストサーバーは、その制御下にある住所を指定する必要があり、このアドレスで受信したDSNSが元のバウンスアドレスに転送されることを手配する必要があります。
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）レコードを公開することにより、どのホストが電子メールメッセージを送信することを許可されているかを宣言します。[RFC4408]は、バージョンのプレフィックス「V = SPF1」で識別されたこれらのレコードの形式を定義します。このセクションでは、バージョンのプレフィックス「SPF2.0」で識別される修正形式を定義します。これにより、ドメインを送信してレコードの解釈方法を明示的に指定し、追加の拡張性を提供します。ドメインの送信は、いずれかまたは両方の形式を公開する場合があります。
Since the two formats are identical in most respects, the following subsections define the "spf2.0" format relative to [RFC4408].
2つの形式はほとんどの点で同一であるため、次のサブセクションは[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チェック、メールフロムチェック、またはその両方に使用できるかどうかを宣言する方法が必要です。
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
For example, the SPF record
たとえば、SPFレコード
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.
メールまたは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.
ドメインは、各スコープが最大1つのSPF 2.0レコードに表示される場合、複数のSPF 2.0レコードを公開する場合があります。さらに、ドメインは、[RFC4408]で定義された「V = SPF1」バージョン識別子を使用するSPFレコードを公開することもできます。セクション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.
特異な修飾子は、グローバルである場合、または各メカニズムが位置的である場合は、レコードに1回だけ表示される場合があります。
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」を解釈する必要があります。
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？all」レコードを公開する必要があります。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].
1. 電子メールメッセージから、アドレスを抽出して確認します。このテストのPRAバリアントは、[RFC4407]で指定されているように、または[RFC4405]で指定されている提出者アドレスを使用して、そうします。このテストのバリアントからのメールは、[RFC4408]で指定されています。
2. Extract the domain part of the address determined in step 1.
2. ステップ1で決定されたアドレスのドメイン部分を抽出します。
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バリアント用）または「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（）関数の結果は、値「ニュートラル」、「パス」、「失敗」、「ソフトファイル」、「なし」、「Temperror」、または「Permerror」値の1つです。セクション5では、これらの結果がメッセージを受信するMTAによってどのように使用されるかについて説明します。この仕様は、他の環境でこのテストを実行する当事者に要件を課しません。
SPF records are looked up in DNS in accordance with Section 4.4 of [RFC4408].
[RFC4408]のセクション4.4に従って、SPFレコードが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」レコードのバージョンセクションには、後方互換の将来の拡張機能用のVer-Minorフィールドが含まれています。このフィールドは、記録を保持するために十分に形成する必要がありますが、それ以外の場合は無視されます。
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.
3. 「SPF2」バージョン識別子を使用し、<scope>に一致するScope-IDを使用していないレコードは破棄されます。これは、Scope-IDトークンの完全な文字列マッチであることに注意してください。<scope>が「PRA」の場合、「SPF2.0/MFROM、PRATTLE、FUBAR」を開始するレコードは破棄されますが、レコードは「SPF2」を開始します。0/mfrom、pra、fubarは保持されます。
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. Lookupが2つのレコードを返した場合、1つは「V = SPF1」バージョン識別子を含み、もう1つは「SPF2」バージョン識別子を含む、「SPF2」バージョンが目的のScope-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」レコードに目的のScope-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".
上記の手順の後、1つのレコードが残り、評価が進むことができます。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.
これらの結果のいずれかを受信する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.
SMTPトランザクション中に送信者IDテストを実行する場合、この結果を受信するメッセージを拒否することを選択するMTAは、「550 5.7.1 Sender ID（xxx）yyy -zzz」SMTPエラーでメッセージを拒否するはずです。「PRA」または「Mail From」に置き換えられ、「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.
この結果を受信するSMTPサーバーは、「450 4.4.3 Sender ID Checkが一時的に利用できない」エラーコードでメッセージを拒否する場合があります。あるいは、この結果を受信する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と組み合わせて使用するように設計されています。十分に機知に富んだ攻撃者は、AddressesからForgedから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.
このメカニズムは、多数のメッセージヘッダーのいずれかまたはRFC 2821メールコマンドから検証するアドレスを選択し、そのアドレスを検証に使用します。ヘッダーまたはリターンパスからの真のresりを含むが、ヘッダーから鍛造されたメッセージは受け入れられます。多くの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.
この攻撃を中和するために、MUASは少なくとも検証されたアドレスの表示を開始する必要があります。さらに、MTAは、検証済みのアドレスがFrom Headerとは異なる場合、メッセージを強化した精査を受ける可能性があります。
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が参加者Pを誘惑して、犠牲者Vに悪意のあるメッセージを送信できる攻撃のクラスがあります。
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.
これらの攻撃は、リクエストからSMTPメールのVのアドレスを引用し、Pが犠牲者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の評判を損傷する可能性があります。悪意のあるメッセージ。
In current practice, A causes P to cause the 'bounce' by addressing the original message to a nonexistent recipient.
現在の実践では、Aは、元のメッセージを存在しない受信者に扱うことにより、「バウンス」を引き起こします。
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.
ヘッダーから独自の名前を使用して、元の電子メールをインターネットに注入するドメインは、準拠する必要はありません。ただし、そのようなドメインは、[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とメールの両方で同じになります。この場合、ドメインは、spfレコードを使用して情報を「v = spf1」とともに公開する必要があります。そうすることで、公開された情報が古い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バリアントに合格するために、他のアドレスに送信されるプログラムは、使用が許可されている電子メールアドレスを含む適切なヘッダーを追加する必要があります。このようなプログラムは、この目的のためにヘッダーからresしたヘッダーを使用する必要があります。
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はアドレスから元のメールに転送する必要があります。ただし、この変更されたアドレスが元のメッセージに関連する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.
今日のフォワーダーの一部は、すでに適切なヘッダーを追加しています（それらの多くはresからresするのではなく送信者を使用しています）。それらのほとんどは、上記のアドレスrewritingを実行していません。
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は、メッセージの各コピーが異なる新しく挿入されたヘッダーから挿入された異なるresed fieldを含む各新しい受信者に個別にメッセージを送信する必要があります。
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バリアントに合格するには、メーリングリストサーバーは、使用が許可されている電子メールアドレスを含む適切なヘッダーを追加する必要があります。このようなプログラムは、この目的のためにヘッダーからresしたヘッダーを使用する必要があります。
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.
テストのバリアントからメールを渡すには、メーリングリストサーバーが住所からその制御下のアドレスにメールを変更する必要があります。
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.
今日のメーリングリストソフトウェアのほとんどはすでに適切なヘッダーを追加しています（それらのほとんどはresからresったのではなく送信者を使用しています）、それらのほとんどはすでにアドレスからメールを変更しています。
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バリアントにすでに準拠しています。メーラーがすでにこのテストのバリアントからのメールに準拠している程度は不明です。
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.
受信したメッセージを表示する場合、MUAは、このドキュメントで定義されている責任あるアドレスを、アドレスからRFC 2822とは異なる場合はいつでも表示する必要があります。このディスプレイは、アドレスから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はそれらすべてを表示することを検討する必要があります。つまり、メッセージにいくつかのresりfrom、送信者、およびfからの場合、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:
Sender 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.
このデザインは、2003年に[RMX]および[DMP]ドラフト（Hadmut DanischとGordon Fecykによる）で公開された以前の作品に基づいています。DNSレコードを使用して電子メールアドレスの正当性を確認するというアイデアは、その祖先を「Mailの否認」Paul Vixie [Vixie]（Jim Millerの提案に基づいて）と「ドメインが許可されたSMTPメール」に「拒否」を追跡します。2002年にAnigantPersメーリングリストでこのアイデアを最初に紹介したDavid Green [Green]によるドラフト。
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]および[callerid]の以前のバージョンから、マリドワーキンググループの多くのメンバーによって提案されたアイデアを組み込んでいます。上記のそれぞれの貢献は感謝されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Allman E.およびH. Katz、「電子メールメッセージの責任ある提出者を示すためのSMTPサービス拡張」、RFC 4405、2006年4月。
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[RFC4407] Lyon、J。、「電子メールメッセージの責任ある住所」、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.
[RFC4408] Wong、M。およびW. Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）」、RFC 4408、2006年4月。
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical Specification, http://www.microsoft.com/mscorp/safety/ technologies/senderid/resources.mspx
[Callerid] Microsoft Corporation、電子メール技術仕様の発信者ID、http：//www.microsoft.com/mscorp/safety/ technologies/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.
[Green] David Green、 "Mail-Transmitter RR"、http://ops.ietf.org/lists/namedoppers/namedoppers.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. Danisch、「RMX DNS RRおよび軽量SMTP送信者認証の方法」、http://www.danisch.de/work/security/txt/ draft-danisch-dns-rr-smtp-04.txt
[Vixie] Paul Vixie, "Repudiating Mail From", http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00658.html, June 2002.
[vixie] Paul Vixie、「Repudiating Mail」、http://ops.ietf.org/lists/namedoppers/namedoppers.2002/MSG00658.html、2002年6月。
Authors' Addresses
著者のアドレス
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Jim Lyon Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
EMail: jimlyon@microsoft.com
Meng Weng Wong Singapore
Meng Weng Wong Singapore
EMail: mengwong@dumbo.pobox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。