RFC4406 日本語訳
4406 Sender ID: Authenticating E-Mail. J. Lyon, M. Wong. April 2006. (Format: TXT=40428 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lyon
Request for Comments: 4406 Microsoft Corp.
Category: Experimental M. Wong
pobox.com
April 2006
コメントを求めるワーキンググループJ.リヨン要求をネットワークでつないでください: 4406年のMicrosoft Corp.カテゴリ: 実験的なM.ウォンpobox.com2006年4月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
以下のドキュメント(RFC4405、RFC4406、RFC4407、およびRFC4408)は同時にExperimental RFCsとして発表されます、どんな一般的な技術的なコンセンサスもありません、そして、2つのアプローチを和解させるための努力は失敗しましたが。 そういうものとして、これらのドキュメントは、完全なIETFレビューを受け取っていなくて、それらがMARIDワーキンググループで考えられたとき異なるアプローチを記録するために「そのままで」発表されます。
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は、好まれるアプローチがことである立場を全く取らないで、各アプローチのための重大な未解決の問題と2人乗り自転車でそれらを使用することに関する心配があると読者に警告します。 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
Sender ID実験DNS記録を当てにする関係者はこのセットの事情の有効なメッセージを失うかもしれないのに注意されます。 SPF実験DNS記録を発表する関係者は考えるべきです。
Lyon & Wong Experimental [Page 1] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[1ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
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.
アドバイスは、RFC4406のセクション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実験の関係者は、規格対応することのシステム(Resent-*ヘッダー、およびRFC822に従うシステムを加えないことによって規格に従いますが、まだRFC2822Resent-*意味論を実行していない明確に自動である混載業者)と対話するとき、正統のメールを受け取るためにResent-*ヘッダーフィールドが使用されている方法が失敗に終わるのを意識している必要があります。 標準化過程の上でこの相互運用性問題を解決しないでSender-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サーバーが、受信されたメッセージのEメールアドレスがそのEメールアドレスに含まれているドメインの所有者の許可と共に使用されたかどうか決定できるテストの家族について説明します。
Lyon & Wong Experimental [Page 2] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[2ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
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
1. 序論…3 1.1. このドキュメントで中古のコンベンション…4 2. 問題声明…4 3. SPF2.0は記録します…5 3.1. バージョンと範囲…5 3.1.1. 小さい方のバージョン…6 3.2. 複数の記録…6 3.3. 位置の修飾語…7 3.4. 互換性…8 4. 決定モデル…8 4.1. 議論…9 4.2. 結果…9 4.3. ルックアップを記録してください…9 4.4. 選択を記録してください…9 5. 動作は決定を基礎づけました…10 5.1. 中立、なにも、SoftFail、またはPermError…11 5.2. 通ってください…11 5.3. 失敗してください…11 5.4. TempError…11 6. セキュリティ問題…11 6.1. DNSは攻撃します…12 6.2. TCPは攻撃します…12 6.3. 偽造送付者は攻撃します…12 6.4. アドレス空間ハイジャック…12 6.5. 悪意があるDNSは第三者の上で攻撃します…13 7. 実現指導…13 7.1. 簡単なEメーラー…14 7.2. 混載業者にメールしてください…14 7.3. メーリングリストサーバ…15 7.4. 第三者郵送者…15 7.5. MUA Implementers…15 8. 承認…16 9. 参照…17 9.1. 標準の参照…17 9.2. 有益な参照…17
1. Introduction
1. 序論
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
このドキュメントがそのようなメカニズムのその受信メール配達エージェント(MTAs)、メールDeliveryエージェント(MDAs)、そして/または、メールUserについて説明するので、(MUAs)が見分けることができるエージェントは、上のカテゴリを郵送して、適切な行動を取ります。 例えば、MTAは、メッセージ、MDAを受け入れるのを拒否するかもしれません。
Lyon & Wong Experimental [Page 3] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[3ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion.
メールボックス、および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].
このドキュメントは1組の密接に関連のテストを定義します。 人は[RFC4407]で定義されるようにメッセージのPurported Responsible Address(PRA)を有効にします。 もう片方が[RFC4408]で定義されるようにメッセージのReverse-経路(また、メール-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.
いずれもそれを郵送するSHOULDが情報を発表するこの仕様に従うのがテストして、SHOULDがアレンジするメール送付者は送って、両方のテストに合格するということです。 この仕様SHOULDに従うメール受信機は少なくともこれらのテストの1つを実行します。
1.1. Conventions Used in This Document
1.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].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
2. Problem Statement
2. 問題声明
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
テストのPRAバージョンはメッセージの最新の導入に関連しているメールボックスを郵便配達システムに認証しようとします。 簡単な場合では、これはメールが来ている人です。 しかしながら、第三者郵送者、混載業者、またはaに関するケース
Lyon & Wong Experimental [Page 4] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[4ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
mailing list server, the address being authenticated is that of the third party, the forwarder, or the mailing list.
メーリングリストサーバ、認証されているのが、第三者のものであるということであるアドレス、混載業者、またはメーリングリスト。
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.
他方では、テストのメール-FROMバージョンはメッセージのために、Delivery Status Notifications(DSNs、または弾み)を受けるメールボックスを認証しようとします。 簡単な場合では、これもメールが来ている人です。 しかしながら、第三者郵送者、混載業者、およびメーリングリストサーバは彼らのコントロールの下でアドレスを指定しなければなりません、そして、SHOULDは手配します。このアドレスに受け取られた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.
どちらの場合も、Eメールアドレスに関連しているドメインは認証されることです。 地方の部分を認証するのを試みを全くしません。 ドメイン所有者は、どの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.)
結局、送付者のドメインがいったん認証されると、与えられたメッセージがスパムであるという見込みを決定するのにメカニズムの一部としてそのドメインを使用するのは可能でしょう、例えば評判と資格認定業務を使用して。 (これらのサービスは現在のメカニズムの対象ではありませんが、それはそれらを可能にするべきです。)
3. SPF 2.0 Records
3. SPF2.0は記録します。
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.
それのホストがいて、ドメインネームシステムにおける出版Sender Policy Framework(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"形式」を定義します。
3.1. Version and Scope
3.1. バージョンと範囲
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.
Sender IDの下では、ドメインを受けると、PRAのアイデンティティかメール-FROMのアイデンティティのどちらかのチェックは働くかもしれません。 したがって、送付ドメインはPRAチェックにそれらの認可された外国行きのEメールサーバの発行されたリストを使用できるか否かに関係なく、宣言するか、メール-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の記録的な範囲の概念を加えます。
Lyon & Wong Experimental [Page 5] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[5ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
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" ver小さい方の範囲) 「verに小さい方の=1*DIGIT範囲は」 /と等しい」という範囲イド*、(「」 範囲イド) 範囲イド="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、-すべて。
defines an SPF record that can be used for either MAIL FROM or PRA checks.
MAIL FROMか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].
このドキュメントは2つの範囲の存在を定義するだけです: "mfrom"と"pra"。 これらの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.
他の範囲は将来のドキュメントだけによって定義されるかもしれません。 範囲への登録が全くありません。 範囲定義はメッセージのために送付メールボックスであると何を認識するか、そして、メッセージからその情報をどのように抜粋するか、そして、どのようにチェック_ホスト()機能のための初期の議論を測定するか、そして、結果への対応する応答が何であるかを定義しなければなりません。 これは、発行された記録とメール受信機があるドメインが範囲の意味論に同意するのを確実にします。
A compliant domain SHOULD publish authorizations for every defined scope.
対応するドメインSHOULDはあらゆる定義された範囲に承認を発行します。
3.1.1. Minor Version
3.1.1. 小さい方のバージョン
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.
このドキュメントの将来のバージョンは、使用されるために他の小さい方のバージョンを定義するかもしれません。
3.2. Multiple Records
3.2. 複数の記録
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.
各範囲が高々1SPF2.0の記録に現れれば、ドメインはSPF2.0が記録する倍数を発行するかもしれません。 また、さらに、ドメインは「[RFC4408]で定義されたv=spf1"バージョン識別子」を使用するSPF記録を発表するかもしれません。 セクション4.4の選択規則はこれらの記録の先行を定義します。
Lyon & Wong Experimental [Page 6] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[6ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
3.3. Positional Modifiers
3.3. 位置の修飾語
This section replaces Section 4.6.3 of [RFC4408] and adds the concept of positional modifiers.
このセクションは、.3セクション4.6[RFC4408]を取り替えて、位置の修飾語の概念を加えます。
Modifiers are key/value pairs that affect the evaluation of the check_host() function.
修飾語はチェック_ホスト()機能の評価に影響するキー/値の組です。
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.
グローバルな修飾語は記録でどこでも現れるかもしれませんが、SHOULDはすべてのメカニズムと位置の修飾語の後に終わりに現れます。
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.
これらの規則で、実現は正しく記録をあらかじめ分析できます。 新しい修飾語が紹介さえされるとき、その上、それらは、構文解析アルゴリズムが安定しているのを許容するために作られます。
Lyon & Wong Experimental [Page 7] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[7ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
Modifiers that are unrecognized MUST be ignored. This allows older implementations to handle records with modifiers that were defined after they were written.
認識されていない修飾語を無視しなければなりません。 これで、より古い実現はそれらが書かれた後に定義された修飾語で記録を扱うことができます。
3.4. Compatibility
3.4. 互換性
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.
この仕様に従うドメイン管理者は彼らの認可された外国行きのEメールサーバに関してDNSの情報を発表しなければなりません。 [RFC4408]は接頭語"v=spf1""というバージョンによって特定されたこの情報のために形式について説明します。 多くのドメインが、この形式を使用することでDNSの情報を発表しました。 Sender ID実現SHOULDがこれらのドメインに互換性を提供するためにバージョン接頭語を解釈する、「「spf2.0"は存在していること」をきっかけに「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"記録SHOULDはまた、PRAとの使用に、それらも有効であるかどうかがチェックすることを決定するためにこれらの記録を再検討すること」が既に発行された管理者。 aの情報である、「PRAチェックには、v=spf1"記録が正しくない、管理者SHOULDは正確な情報がある"spf2.0/pra"記録か「spf2.0/pra?」 PRAチェックの結果が明らかに決定的でないのを示す記録」のどちらかを発表します。
4. Decision Model
4. 決定モデル
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]の指定されるとしてのsubmitterアドレスを使用する際に指定されるようにそうします。 このテストのMAIL FROM異形は[RFC4408]で指定されるようにそうします。
2. Extract the domain part of the address determined in step 1.
2. ステップ1で決定しているアドレスのドメイン部分を抽出してください。
Lyon & Wong Experimental [Page 8] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[8ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
3. Call the check_host() function defined in [RFC4408] and modified
by the following subsections.
3. [RFC4408]で定義されて、以下の小区分によって変更されたチェック_ホスト()機能に電話をしてください。
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".
Sender IDチェックであるなら、メールメッセージを受け取るのを離れさせてください。そうすれば、上(メッセージかアドレスが奇形であるので)のステップ1におけるアドレス、次に、メッセージSHOULDが誤りで拒絶されることを決定できないのでMTAによって実行されるのは、「550 5.7の.1のなくなった主張された原因となるアドレス」かそれとも「550 5.7.1Missing Reverse-経路は記述する」誤りですか?
4.1. Arguments
4.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は範囲パラメタの添加でチェック_ホスト()機能を変更します。 したがって、Sender IDに関して、チェック_ホスト()機能は以下のパラメタを通過すると呼ばれます:
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。 "mfrom"(テストのMAIL FROM異形のための) "pra"(テストのPRA異形のための)、またはbの範囲。 IPはメッセージが存在であるか受け取られた(IPv4かIPv6のどちらか)を記述します。. c。 . dの上のステップ2からのドメイン。 上のステップ1からのアドレス。
4.2. Results
4.2. 結果
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.
チェック_ホスト()機能の結果は値「中立」、「パス」、「失敗してください」、"SoftFail"、「なにも」、"TempError"、または"PermError"の1つです。 セクション5はこれらの結果がメッセージを受け取るMTAsによってどう使用されるかを説明します。 この仕様は他の環境におけるこのテストを実行しているパーティーに要件を全く課しません。
4.3. Record Lookup
4.3. ルックアップを記録してください。
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質問が「実在しないドメイン」(RCODE3)を返すなら、すぐ結果があるチェック_ホスト()出口は「失敗します」。
4.4. Record Selection
4.4. レコード選択
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:
ルックアップによって返された記録のセットから始まって、レコード選択はこれらのステップで続きます:
Lyon & Wong Experimental [Page 9] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[9ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
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小さい方の分野を含む」バージョン部。 この分野は、記録が保有されるためによく形成しなければなりませんが、別の方法で無視されます。
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"バージョン識別子、合っている範囲イド<に>が捨てられるのを見させないでください、」 これが範囲イド象徴の上の完全なストリングマッチであることに注意してください: <範囲>が"pra"であるなら、記録的な始めの「無駄口の、そして、めちゃくちゃなspf2.0/mfrom」は捨てられるでしょうが、記録的な始めの「praの、そして、めちゃくちゃなspf2.0/mfrom」は保有されるでしょう。
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"バージョンは必要な範囲イドのために優先します」。 「spf2"記録は必要な範囲イドを含んでいなくて、その時は「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"記録は必要な範囲イドを含んでいなくて、「ドメインのための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つ以上の記録があれば、すぐ誤り"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質問の後にも残っている合っている記録が全くなければ、すぐ結果「なにも」に_ホスト()出口について問い合わせてください。
5. Actions Based on the Decision
5. 決定に基づく動作
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.
Sender IDテストがメッセージを受け取る一部としてSMTPサーバーによって使用されるとき、サーバはこのセクションによって説明された行動を取るべきです。
The check_host() function returns one of the following results. See [RFC4408] for the meaning of these results.
チェック_ホスト()機能は以下の結果の1つを返します。 これらの結果の意味に関して[RFC4408]を見てください。
Lyon & Wong Experimental [Page 10] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[10ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
5.1. Neutral, None, SoftFail, or PermError
5.1. 中立、なにも、SoftFail、またはPermError
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.
この結果が精査を高めたので、SHOULD NOTがこの理由で単独でメッセージを拒絶するというこれらの結果の1つを受け取るSMTPサーバー、他による高められた精査へのメッセージが測定する5月の対象だけ、および5月はメッセージを拒絶します。
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"であるメッセージが結果が「中立である」メッセージほど正統である傾向がないことを考慮に入れるかもしれません。
5.2. Pass
5.2. パス
An SMTP server receiving this result SHOULD treat the message as authentic. It may accept or reject the message depending on other policies.
SHOULDが正統であるとしてメッセージを扱うというこの結果を受けるSMTPサーバー。 それは、他の方針によるメッセージを、受け入れるか、または拒絶するかもしれません。
5.3. Fail
5.3. 失敗してください。
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.
または、Sender IDテストを実行するときにはSMTP取引、この結果SHOULDを受けるメッセージを拒絶するのを選ぶMTAの間、「550 5.7に、.1Sender ID(xxx)はyyyします--グーグーグー」というSMTP誤りでメッセージを拒絶してください、"xxx"を"PRA"に取り替えるところで「メール、」、"yyy"をチェック_ホスト()機能で返す追加理由に取り替えて、「グーグーグー」をチェック_ホスト()機能で返す説明ストリングに取り替えます。
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.
Sender IDを実行するときには、配送(SHOULD NOTがメッセージを送るこの結果を受けるメッセージを拒絶するのを選ぶMTA)へのメールメッセージを受け入れた後に、テストしてください。 代わりに、それはDSNメッセージにおいて普通の規則とメッセージで、一致していた状態でDSNを作成するべきです。
5.4. TempError
5.4. TempError
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 .3Sender IDチェックは一時入手できません」というエラーコードでメッセージを拒絶するかもしれません。 あるいはまた、5月がaを受け入れるというこの結果を受けるSMTPサーバーは、それを通信して、任意にかけます。他の反スパム測定による高められた精査に。
6. Security Considerations
6. セキュリティ問題
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.
このメカニズムが広く配布されると仮定して、以下のセクションはこのメカニズムを破るのに使用できたカウンタ攻撃について説明します。
Lyon & Wong Experimental [Page 11] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[11ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
6.1. DNS Attacks
6.1. DNS攻撃
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 Security(DNSSEC)は結局、このクラスの攻撃を完全に中和する方法を提供するかもしれません。
6.2. TCP Attacks
6.2. TCP攻撃
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ゲートウェイが、ソースアドレスが明確ににせであるときに、パケットを進めるのを拒否するなら、この種類の攻撃を改善できます。
6.3. Forged Sender Attacks
6.3. 偽造送付者攻撃
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.
このメカニズムは、多くのメッセージヘッダーのひとりか2821年のRFCメールコマンドから有効にするアドレスを選んで、次に、合法化にそのアドレスを使用します。 aが本当のメッセージ、Resent、-、ヘッダーかReturn-経路(偽造Fromヘッダーだけ)を受け入れるでしょう。 多くのMUAsが受信されたメッセージのヘッダーのすべてを表示しないので、表示すると、メッセージは鍛造されるように見えるでしょう。
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は、少なくとも確かめられたアドレスを表示し始める必要があるでしょう。 さらに、MTAsは有効にされたアドレスがFromヘッダーと異なっているときの高められた精査への対象のメッセージをそうすることができました。
6.4. Address Space Hijacking
6.4. アドレス空間ハイジャック
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
このメカニズムは、与えられたクライアントが与えられたPRAからメッセージを送るのに権限を与えられるかどうか決定するためにIPアドレス空間の保全を仮定します。 セクション6.2で与えられたTCP攻撃に加えて、十分才略にたけた攻撃者は、aを使用することで双方向通信を可能にするためにIPルーティング構造を変更できるかもしれません。
Lyon & Wong Experimental [Page 12] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[12ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
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.
指定されたIPアドレス。 認可されたアドレスから来るように見えるSMTPセッションを実行するのはその時可能でしょう、TCP一連番号を推測するか、または盲人を伝わる必要性なしで。
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クライアントにより特定のルートの広告を出すかもしれません、一時アドレスの正統の所有者をくつがえして。
6.5. Malicious DNS Attacks on Third Parties
6.5. 第三者に対する悪意があるDNS攻撃
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 MAIL FROM要求とそして、Pを引き起こすのによるVのアドレスを引用するAによって引き受けられる、(世代を呼び出す、)、Delivery Status Notification'弾み'メッセージ(RFC3464)。(そのメッセージは犠牲者Vに送られます)。
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は、PがSender IDテストを引き受けるとき、Failが結果になる(セクション5.3)ように、(セクション4)が攻撃者によってPRAに選択されるメッセージを送ります。
The message will be rejected (as the attacker intended) and a malicious 'bounce' message may be generated and sent to the victim V.
メッセージが拒絶されて(攻撃者が意図したように)、悪意がある'弾み'メッセージを犠牲者Vに生成して、送るかもしれません。
7. Implementation Guidance
7. 実施要項
This section describes the actions that certain members of the Internet e-mail ecosystem must take to be compliant with this specification.
このセクションはインターネット電子メール生態系のメンバーが、この仕様で言いなりになるのを取らなければならないのをそんなに確信している動作について説明します。
Lyon & Wong Experimental [Page 13] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[13ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
7.1. Simple E-Mailers
7.1. 簡単なEメーラー
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ヘッダーでそれ自身の名前を使用して、オリジナルのメールをインターネットに注ぐドメインは言いなりになるようなことを何もする必要はありません。 しかしながら、そのようなドメインSHOULDは[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とこのテストのMAIL FROM異形の両方に同じになるでしょう。 この場合、ドメインSHOULDは、接頭語"v=spf1""があるSPF記録を使用することでそれらの情報を発表します。 そうするのは、より古いSPFプロトコルでもそれらの発行された情報を使用可能に表すでしょう。 (SPFプロトコルの情報に関して[RFC4408]を見てください。)
7.2. E-Mail Forwarders
7.2. E-Mail混載業者
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異形を通過するために、他のアドレスへのメールが前方で受信されたプログラムはそれが使用するのが認可されるEメールアドレスを含む適切なヘッダーを加えなければなりません。 そのようなものがSHOULD使用をプログラムする、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.
テストのMAIL FROM異形を通過するために、他のアドレスへのメールが前方で受信されたプログラムはコントロールの下におけるアドレスにMAIL FROMアドレスを変更しなければなりません。 そのアドレスは結局、オリジナルのMAIL FROMアドレスに送った状態でDSN SHOULDがあるというオリジナルのメッセージに関連するDSNを受けるべきですか? しかしながら、この変えられたアドレスが何かオリジナルのメッセージに関連するDSNs以外のメッセージを受け取るなら、オリジナルのMAIL FROMアドレスにこれらのメッセージを転送してはいけません。 それら、SHOULD、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.
さらに、メール混載業者SHOULDはそれらのドメインのためのSender ID記録を発表します、そして、SHOULDはSender IDチェックが「パス」結果をもたらすMTAsを使用します。
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.
今日の何人かの混載業者が既に適切なヘッダーを加える、(彼らの多くがむしろSenderを使用する、Resent、-、)。 彼らの大部分は上で指定されたアドレス書き直しを実行しません。
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 SHOULDは個別にそれぞれの新しい受取人にメッセージを送ります、メッセージ含有のそれぞれのコピーがa異なっていた状態で新たに挿入されてResent、-、ヘッダーフィールド。
Lyon & Wong Experimental [Page 14] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[14ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
7.3. Mailing List Servers
7.3. メーリングリストサーバ
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異形を通過するために、メーリングリストサーバはそれが使用するのが認可されるEメールアドレスを含む適切なヘッダーを加えなければなりません。 そのようなものがSHOULD使用をプログラムする、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異形を通過するために、メーリングリストサーバはコントロールの下におけるアドレスに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.
さらに、メーリングリストサーバSHOULDはそれらのドメインのためのSender ID記録を発表します、そして、SHOULDはSender IDチェックが「パス」結果をもたらすMTAsを使用します。
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.
だいたい、今日のメーリングリストソフトウェアが既に適切なヘッダーを加える、(彼らの大部分がむしろSenderを使用する、Resent、-、)、彼らの大部分は既にMAIL FROMアドレスを変更します。
7.4. Third-Party Mailers
7.4. 第三者郵送者
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異形を通過するために、別のユーザを代表してメールを送るプログラムはそれが使用するのが認可されるEメールアドレスを含む適切なヘッダーを加えなければなりません。 そのようなプログラムSHOULDはこのためにSenderヘッダーを使用します。
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.
このテストのMAIL FROM異形を通過するために、別のユーザを代表してメールを送るプログラムはコントロールの下にあるMAIL FROMアドレスを使用しなければなりません。 プログラムが処理することをどんな郵便配達人もそのアドレスで受けた定義するのはこのドキュメントの範囲を超えています。
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.
追加、第三者郵送者では、サーバSHOULDはそれらのドメインのためのSender ID記録を発表します、そして、SHOULDはSender IDチェックが「パス」結果をもたらすMTAsを使用します。
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異形で既に対応します。 郵送者がこのテストのMAIL FROM異形で既に言いなりになる範囲は未知です。
7.5. MUA Implementers
7.5. MUA Implementers
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 SHOULDはそのアドレスが2822年のRFC Fromアドレスと異なっているときはいつも、このドキュメントによって定義されるように主張された原因となるアドレスを表示します。 このディスプレイSHOULDはRFC2822に加えたそうです。Fromアドレス。
Lyon & Wong Experimental [Page 15] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[15ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
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、-、Sender、およびFrom、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もEメールアドレスと共に伝えられるかもしれないディスプレイ名を有効にしません。 また、ディスプレイ名もパロディーの、そして、他の形式の攻撃に被害を受け易いです。 そのような攻撃の発生と有効性を抑えるために、MUA implementersはディスプレイ名を保護するメソッドを考えるはずです。 これは以下を含むかもしれません:
* 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.
* ディスプレイ名をユーザに全く提示しないか、または対応するEメールアドレスがユーザのアドレス帳にリストアップされない場合、ディスプレイ名を提示しません。
* 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.
* 疑わしげであるとして、特にヘッダーで実際のEメールアドレスと異なっていると、ディスプレイ名がEメールアドレスの形にそれ自体であるどんなメールも扱います。
* Making it clear to users that the e-mail address has been checked
rather than the display name.
* ディスプレイ名よりむしろEメールアドレスをチェックしてあるとユーザに断言します。
8. Acknowledgements
8. 承認
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とゴードンFecykそれぞれ)に基づいています。 Eメールアドレスの合法性をチェックするために記録的なDNSが祖先をつける使用の考え、「」 草稿からメールをポールVixie[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]と[CallerID]の上の、そして、以前のバージョンから大いに借りて、MARIDワーキンググループの多くのメンバーによって提案された考えを取り入れます。 それぞれの上記での貢献は感謝して承諾されます。
Lyon & Wong Experimental [Page 16] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[16ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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はメールメッセージの責任があるSubmitterを示すための拡大を修理します」、RFC4405、2006年4月。
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, April 2006.
[RFC4407] リヨン、J.、「メールメッセージの主張された原因となるアドレス」、RFC4407、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]ウォン、M.とW.Schlitt、「メールにおけるドメインの使用を認可するための送付者方針フレームワーク(SPF)」RFC4408(2006年4月)。
9.2. Informative References
9.2. 有益な参照
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification, http://www.microsoft.com/mscorp/safety/
technologies/senderid/resources.mspx
[CallerID]マイクロソフト社、メール仕様書のための発信番号表示、 http://www.microsoft.com/mscorp/safety/ 技術/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.
2002年6月の[グリーン]デヴィッド・グリーン、「メール送信機RR」 http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00656.html。
[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と、「軽量のSMTP送付者承認のためのRMX DNS RRとメソッド」、 http://www.danisch.de/work/security/txt/ 草稿-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]ポールVixie、「メールを否認する」、 http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00658.html、6月2002日
Lyon & Wong Experimental [Page 17] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[17ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
Authors' Addresses
作者のアドレス
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
ジムリヨンマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: jimlyon@microsoft.com
メール: jimlyon@microsoft.com
Meng Weng Wong Singapore
Meng Weng Wongシンガポール
EMail: mengwong@dumbo.pobox.com
メール: mengwong@dumbo.pobox.com
Lyon & Wong Experimental [Page 18] RFC 4406 Sender ID: Authenticating E-Mail April 2006
リヨンとウォンの実験的な[18ページ]RFC4406送付者ID: 2006年4月にメールを認証します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Lyon & Wong Experimental [Page 19]
リヨンとウォン実験的です。[19ページ]
一覧
スポンサーリンク
