[要約] RFC 6686は、Sender Policy Framework（SPF）とSender IDの実験の結果と解決策を提供しています。このRFCの目的は、SPFとSender IDの問題を特定し、改善策を提案することです。
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6686 Cloudmark
Category: Informational July 2012
ISSN: 2070-1721
Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments
Sender Policy Framework（SPF）およびSender ID Experimentsの解決
Abstract
概要
In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.
2006年、IETFはSender Policy Framework（SPF）とSender ID（2つの提案された電子メール認証プロトコル）を含む一連のプロトコルドキュメントを公開しました。これらのプロトコルはどちらも、ドメインネームシステムを介して、クエリ対象のドメイン名に代わって電子メールの送信を許可するメールサーバーを宣言するポリシーを公開できるようにします。一部の重要な運用状況で2つが競合し、メッセージの配信が妨害されることが懸念されました。
The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.
IESGは、これらのすべてのドキュメント（RFC 4405、RFC 4406、RFC 4407、およびRFC 4408）を試験的RFCとして公開することを要求し、コミュニティが公開日から2年間にわたってプロトコルの展開と運用を監視することを要求しました今後の合理的な道筋を決定する。
After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings.
6年後、このように作成された実験は終了したと見なすことができるという十分な経験と証拠が集められました。このドキュメントはそれらの調査結果を示します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6686.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6686で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................3
3. Evidence of Deployment ..........................................3
3.1. DNS Resource Record Types ..................................3
3.2. Implementations ............................................5
3.3. The SUBMITTER SMTP Extension ...............................6
4. Evidence of Differences .........................................7
5. Analysis ........................................................7
6. Conclusions .....................................................8
7. Security Considerations .........................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
Appendix A. Background on the RRTYPE Issue ........................10
Appendix B. Acknowledgments .......................................11
In April 2006, the IETF published the [SPF] and Sender ID email authentication protocols, the latter consisting of three documents ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers are authorized to send email on behalf of the selected domain name.
2006年4月、IETFは[SPF]およびSender ID電子メール認証プロトコルを公開しました。後者は3つのドキュメント（[SUBMITTER]、[SENDER-ID]、および[PRA]）で構成されています。これらのプロトコルはどちらも、ドメインネームシステムを介して、選択したドメイン名に代わって電子メールを送信することを許可されているメールサーバーを宣言するポリシーを公開できるようにします。
Consensus did not clearly support one protocol over the other, and there was significant concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents as Experimental, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication in order to determine a reasonable path forward.
コンセンサスは1つのプロトコルを他のプロトコルよりも明確にサポートしていませんでした。また、2つのプロトコルが重要な運用状況で競合し、メッセージの配信を妨害するという重大な懸念がありました。 IESGは、これらすべてのドキュメントの公開を試験運用として要求し、コミュニティが今後の合理的な道筋を決定するために、公開日から2年間にわたってプロトコルの展開と運用を監視することを要求しました。
In line with the IESG's request to evaluate after a period of time, this document concludes the experiments by presenting evidence regarding both deployment and comparative effect of the two protocols. At the end, it presents conclusions based on the data collected.
一定期間後に評価するというIESGの要求に沿って、このドキュメントでは、2つのプロトコルの展開と比較効果の両方に関する証拠を提示して実験を終了します。最後に、収集されたデータに基づいて結論を提示します。
It is important to note that this document makes no direct technical comparison of the two protocols in terms of correctness, weaknesses, or use case coverage. The email community at large has already done that through its deployment choices. Rather, the analysis presented here is merely an observation of what has been deployed and supported in the time since the protocols were published and lists conclusions based on those observations.
このドキュメントでは、2つのプロトコルの正確性、弱点、またはユースケースカバレッジの点で直接技術的な比較を行うことはありません。電子メールコミュニティ全体では、展開の選択を通じて既にそれを行っています。むしろ、ここに提示された分析は、プロトコルが公開されて以来、展開されサポートされてきたものの単なる観察であり、それらの観察に基づいて結論を列挙しています。
The data collected and presented here are presumed to be a reasonable representative view of the global deployment data, which could never itself be fully surveyed within a reasonable period of time.
ここで収集および表示されたデータは、グローバル展開データの合理的な代表的なビューであると想定されており、合理的な期間内に完全に調査することはできません。
The term "RRTYPE" is used to refer to a Domain Name System ([DNS]) Resource Record (RR) type. These are always expressed internally in software as numbers, assigned according to the procedures in [DNS-IANA] Assigned RRTYPEs also have names. The two of interest in this work are the TXT RRTYPE (16) and the SPF RRTYPE (99).
「RRTYPE」という用語は、ドメインネームシステム（[DNS]）リソースレコード（RR）タイプを指すために使用されます。これらは常にソフトウェアで内部的に番号として表現され、[DNS-IANA]の手順に従って割り当てられます。割り当てられたRRTYPEにも名前があります。この作業で興味深いのは、TXT RRTYPE（16）とSPF RRTYPE（99）です。
This section presents the collected research done to determine what parts of the two protocol suites are in general use as well as related issues like [DNS] support.
このセクションでは、2つのプロトコルスイートのどの部分が一般的に使用されているかを判断するために行われた収集された調査と、[DNS]サポートなどの関連する問題を示します。
Three large-scale DNS surveys were run that looked for the two supported kinds of RRTYPEs that can contain SPF policy statements. These surveys selected substantial sets of distinct domain names from email headers and logs over long periods, regardless of whether the DNS data for those domains included A, MX, or any other RRTYPEs. The nameservers for these domains were queried, asking for both of the RRTYPEs that could be used for SPF and/or Sender ID.
SPFポリシーステートメントを含むことができるサポートされている2種類のRRTYPEを探す3つの大規模DNS調査が実行されました。これらの調査では、それらのドメインのDNSデータにA、MX、またはその他のRRTYPEが含まれているかどうかに関係なく、長期間にわたって、メールヘッダーとログから異なるドメイン名の実質的なセットを選択しました。これらのドメインのネームサーバーが照会され、SPFまたは送信者ID、あるいはその両方に使用できるRRTYPEの両方が要求されました。
In the tables below, replies were counted only if they included prefixes that indicated the record was intended to be of a form defined in either [SPF] or [SENDER-ID], though complete syntax validation of the replies was not done. That is, the records started either "v=spf1" or "spf2.0/", or they were not counted as replies.
以下の表では、レコードが[SPF]または[SENDER-ID]で定義された形式であることを示すプレフィックスが含まれている場合にのみ返信がカウントされましたが、返信の完全な構文検証は行われていません。つまり、「v = spf1」または「spf2.0 /」のいずれかで開始されたレコード、またはそれらは応答としてカウントされませんでした。
The tables are broken down into three parts: (a) the size of the sample set, (b) a report about RRTYPE use independent of content, and (c) a report about content independent of RRTYPE.
表は3つの部分に分かれています。（a）サンプルセットのサイズ、（b）コンテンツに依存しないRRTYPEの使用に関するレポート、および（c）RRTYPEに依存しないコンテンツに関するレポート。
"SPF+TXT" indicates the count of domains where both types were in use.
「SPF + TXT」は、両方のタイプが使用されていたドメインの数を示します。
DNS Survey #1 (Cisco)
DNS調査＃1（シスコ）
+------------------+-----------+-------+
| Domains queried | 1,000,000 | - |
+------------------+-----------+-------+
| TXT replies | 397,511 | 39.8% |
| SPF replies | 6,627 | <1.0% |
| SPF+TXT replies | 6,603 | <1.0% |
+------------------+-----------+-------+
| v=spf1 replies | 395,659 | 39.6% |
| spf2.0/* replies | 5,291 | <1.0% |
+------------------+-----------+-------+
Domains were selected as the top million domains as reported by Alexa, which monitors browser activity.
ブラウザのアクティビティを監視しているAlexaの報告によると、ドメインは上位100万ドメインとして選択されました。
DNS Survey #2 (The Trusted Domain Project)
DNS調査＃2（信頼されたドメインプロジェクト）
+------------------+-----------+-------+
| Domains queried | 278,353 | - |
+------------------+-----------+-------+
| TXT replies | 156,894 | 56.4% |
| SPF replies | 2,876 | 1.0% |
| SPF+TXT replies | 2,689 | <1.0% |
+------------------+-----------+-------+
| v=spf1 replies | 149,985 | 53.9% |
| spf2.0/* replies | 7,285 | 2.7% |
+------------------+-----------+-------+
This survey selected its domains from data observed in email headers and previous SPF and Sender ID evaluations, collected from 23 reporting hosts across a handful of unrelated operators over a period of 22 months.
この調査では、電子メールのヘッダーで観測されたデータと以前のSPFおよび送信者IDの評価からドメインを選択し、22か月の期間にわたって少数の無関係なオペレーターの23のレポートホストから収集しました。
During this second survey, some domains were observed to provide immediate answers for RRTYPE 16 queries, but would time out waiting for replies to RRTYPE 99 queries. For example, it was observed that 4,360 (over 1.6%) distinct domains in the survey returned a result of some kind (a record or an error) for the TXT query in time N, while the SPF query ultimately failed after at least time 4N.
この2回目の調査中に、一部のドメインはRRTYPE 16クエリに対して即時の回答を提供することが観察されましたが、RRTYPE 99クエリへの応答を待機してタイムアウトしました。たとえば、調査の4,360（1.6％以上）の異なるドメインが、時間NにTXTクエリに対して何らかの結果（レコードまたはエラー）を返したのに対し、SPFクエリは少なくとも時間4N後に最終的に失敗したことが観察されました。
DNS Survey #3 (Hotmail)
DNS調査＃3（Hotmail）
+------------------+-----------+-------+
| Domains queried | 100,000 | - |
+------------------+-----------+-------+
| TXT replies | 46,221 | 46.2% |
| SPF replies | 954 | <1.0% |
| SPF+TXT replies | 1,383 | 1.4% |
+------------------+-----------+-------+
Hotmail's domain set was selected from live email traffic at the time the sample was extracted. Only the RRTYPE portion of the report is available.
Hotmailのドメインセットは、サンプルの抽出時にライブメールトラフィックから選択されました。レポートのRRTYPE部分のみが使用可能です。
A separate survey was done of queries for RRTYPE 16 and RRTYPE 99 records by observing nameserver traffic records. Only a few queries were ever received for RRTYPE 99 records, and those almost exclusively came from one large email service provider that queried for both RRTYPEs. The vast majority of other querying agents only ever requested RRTYPE 16.
ネームサーバートラフィックレコードを監視することにより、RRTYPE 16およびRRTYPE 99レコードのクエリについて別の調査が行われました。 RRTYPE 99レコードに対して受信されたクエリはごくわずかであり、これらのクエリは両方のRRTYPEを照会する1つの大規模な電子メールサービスプロバイダーからほとんど独占的に送信されました。他の大部分のクエリエージェントは、RRTYPE 16を要求しただけです。
It is likely impossible to determine from a survey which Mail Transfer Agents (MTAs) have SPF and/or Sender ID checking enabled at message ingress since it does not appear, for example, in the reply to the EHLO command from extended [SMTP]. Therefore, we relied on evidence found via web searches and observed the following:
たとえば、拡張[SMTP]からのEHLOコマンドへの応答に表示されないため、メッセージの入力時にどのメール転送エージェント（MTA）がSPFまたは送信者IDチェックを有効にしているかを調査から判別することはおそらく不可能です。そのため、ウェブ検索で見つかった証拠に頼り、以下を観察しました。
o A web site [SID-IMPL] dedicated to highlighting Sender ID implementations, last updated in late 2007, listed 13 commercial implementations, which we assume means they implement the Purported Responsible Address (PRA) checks. At least one of them is known no longer to be supported by its vendor. There were no free open-source implementations listed.
o 2007年後半に最終更新されたSender IDの実装を強調する専用のWebサイト[SID-IMPL]には、13の商用実装がリストされています。これは、Purported Responsible Address（PRA）チェックを実装していることを意味します。それらの少なくとも1つは、そのベンダーによってサポートされなくなったことがわかっています。リストされている無料のオープンソース実装はありませんでした。
o The [OPENSPF] web site maintains a list of implementations of SPF. At the time of this document's writing, it listed six libraries, 22 MTAs with built-in SPF implementations, and numerous patches for MTAs and mail clients. The set included a mix of commercial and free open-source implementations.
o [OPENSPF] Webサイトは、SPFの実装のリストを維持しています。このドキュメントの執筆時点では、6つのライブラリ、SPF実装が組み込まれた22のMTA、およびMTAとメールクライアント用の多数のパッチがリストされていました。セットには、商用と無料のオープンソース実装の組み合わせが含まれていました。
The PRA is the output of a heuristic that seeks to scan a message header and extract from it the email address most likely to be the one responsible for injection of that message into the mail stream. The SUBMITTER extension to SMTP is a mechanism to provide an early hint (i.e., as part of the MAIL command in an SMTP session) to the receiving MTA of what the PRA would be on full receipt of the message.
PRAは、メッセージヘッダーをスキャンし、そのメッセージからメールストリームへのメッセージの挿入を担当している可能性が最も高いメールアドレスを抽出するヒューリスティックの出力です。 SMTPのSUBMITTER拡張機能は、PRAがメッセージを完全に受信したときに受信するMTAに初期のヒントを（SMTPセッションのMAILコマンドの一部として）提供するメカニズムです。
In a review of numerous MTAs in current or recent use, two (Santronics WinServer and McAfee MxLogic) were found to contain implementations of the SMTP SUBMITTER extension as part of the MTA service, which could act as an enabler to Sender ID.
現在または最近使用されている多数のMTAのレビューで、2つ（Santronics WinServerおよびMcAfee MxLogic）は、Sender IDのイネーブラーとして機能する可能性のあるMTAサービスの一部として、SMTP SUBMITTER拡張の実装を含んでいることがわかりました。
An unknown number of SMTP clients implement the SUBMITTER SMTP extension. Although information from MTA logs indicates substantial use of the SMTP extension, it is not possible to determine whether the usage is from multiple instances of the same SMTP client or different SMTP client implementations.
不明な数のSMTPクライアントがSUBMITTER SMTP拡張機能を実装しています。 MTAログからの情報はSMTP拡張機能の実質的な使用を示していますが、使用が同じSMTPクライアントの複数のインスタンスからのものか、異なるSMTPクライアント実装からのものかを判別することはできません。
An active survey of MTAs accessible over the Internet was performed. The MTAs selected were found by querying for MX and A resource records of a subset of all domains observed by The Trusted Domain Project's data collection system in the preceding 20 months. The results were as follows:
インターネット経由でアクセス可能なMTAのアクティブな調査が行われました。選択されたMTAは、Trusted Domain Projectのデータ収集システムによって過去20か月に観察されたすべてのドメインのサブセットのMXおよびAリソースレコードをクエリすることで見つかりました。結果は次のとおりです。
SUBMITTER Survey (The Trusted Domain Project)
提出者調査（Trusted Domain Project）
+-------------------+-----------+-------+
| MTAs selected | 484,980 | - |
| MTAs responding | 371,779 | 76.7% |
| SUBMITTER enabled | 17,425 | 4.7% |
| MXLogic banner | 16,914 | 4.6% |
+-------------------+-----------+-------+
Note: The bottom two rows indicate the percentage of responding MTAs with the stated property, not the percentage of selected MTAs.
注：下の2行は、選択されたMTAの割合ではなく、指定されたプロパティを持つ応答MTAの割合を示します。
Based on the SMTP banner presented upon connection, the entire set of SUBMITTER-enabled MTAs consisted of the two found during the review (above) and a third whose identity could not be positively determined.
接続時に提示されるSMTPバナーに基づいて、送信者対応MTAのセット全体は、レビュー中に見つかった2つ（上記）と、正体を明確に特定できなかった3つ目で構成されました。
Of those few responding MTAs advertising the SUBMITTER SMTP extension, 97% were different instances of one MTA. The service operating that MTA (MXLogic, a division of McAfee) reported that about 11% of all observed SMTP sessions involved SMTP clients that make use of the SUBMITTER extension. Note that this represents about 11% of the clients of 4.6% of the responding MTAs in the survey.
SUBMITTER SMTP拡張機能をアドバタイズする数少ない応答するMTAのうち、97％が1つのMTAの異なるインスタンスでした。 MTA（マカフィーの一部門であるMXLogic）が運用しているサービスは、観測されたすべてのSMTPセッションの約11％が、SUBMITTER拡張を利用するSMTPクライアントに関係していると報告しています。これは、調査で回答したMTAの4.6％のクライアントの約11％に相当します。
Separate surveys from Hotmail and The Trusted Domain Project compared the cases where the PRA (used by Sender ID) and the RFC5321.MailFrom address (used by SPF) differed. The results of these tests showed that, at least 50% of the time, the two addresses were the same, but, beyond that, the percentage varied substantially from one sampling location to the next due to the nature of the mail streams they each receive.
HotmailおよびTrusted Domain Projectからの個別の調査では、PRA（Sender IDで使用）とRFC5321.MailFromアドレス（SPFで使用）が異なる場合を比較しました。これらのテストの結果は、少なくとも50％の時間で、2つのアドレスは同じであったことを示していますが、それを超えると、パーセンテージは、それぞれが受信するメールストリームの性質により、サンプリング場所ごとに大幅に異なります。
Further, The Trusted Domain Project analyzed approximately 150,000 messages and found that in more than 95% of those cases, Sender ID and SPF reach the same conclusion about a message, meaning either both protocols return a "pass" result or both return a "fail" result. Note that this does not include an evaluation of whether "fail" meant spam or other abusive mail was thus detected or that "pass" mail is good mail; it is merely a measure of how often the two protocols concurred. The data set yielding this response could not further characterize the cases in which the answers differed.
さらに、Trusted Domain Projectは約150,000のメッセージを分析し、それらのケースの95％以上で、Sender IDとSPFがメッセージについて同じ結論に達したことを発見しました。つまり、両方のプロトコルが「合格」の結果を返すか、どちらも「失敗"結果。これには、「失敗」がスパムまたは他の不正なメールが検出されたことを意味するか、または「合格」メールが良いメールであるかどうかの評価は含まれません。これは、2つのプロトコルが一致した頻度の尺度にすぎません。この応答を生成するデータセットは、回答が異なる場合をさらに特徴付けることができませんでした。
A second analysis of the same nature by Hotmail found that the two protocols yielded the same result approximately 80% of the time when evaluated across billions of messages.
Hotmailによる同じ性質の2番目の分析では、2つのプロトコルが数十億のメッセージにわたって評価された場合、時間の約80％で同じ結果が得られることがわかりました。
Anecdotally, the differences in conclusions have not been noted as causing significant operational problems by the email-receiving community.
事例では、結論の違いは、メール受信コミュニティによる重大な運用上の問題を引き起こしていると指摘されていません。
Given the six years that have passed since the publication of the Experimental RFCs, and the evidence reported in the earlier sections of this document, the following analysis appears to be supported:
試験的RFCの発行から6年が経過し、このドキュメントの前のセクションで報告された証拠を考慮すると、次の分析がサポートされているようです。
1. There has not been substantial adoption of the RRTYPE 99 (SPF) DNS resource record. In all large-scale surveys performed for this work, fewer than 2% of responding domains published RRTYPE 99 records, and almost no clients requested them.
1. RRTYPE 99（SPF）DNSリソースレコードは実質的に採用されていません。この作業のために実行されたすべての大規模な調査で、応答したドメインの2％未満がRRTYPE 99レコードを公開し、ほとんどのクライアントがそれらを要求しませんでした。
2. Of the DNS resource records retrieved, fewer than 3% included specific requests for processing of messages using the PRA algorithm, which is an essential part of Sender ID.
2. 取得されたDNSリソースレコードのうち、3％未満には、送信者IDの重要な部分であるPRAアルゴリズムを使用したメッセージ処理の特定の要求が含まれていました。
3. Although the two protocols often used different email address fields as the subject being evaluated, no data collected showed any substantial operational benefit, in terms of improved accuracy, to using one mechanism over the other.
3. 2つのプロトコルは、評価対象として異なる電子メールアドレスフィールドを使用することがよくありますが、収集されたデータでは、一方のメカニズムをもう一方のメカニズムよりも使用することで、精度の向上という点で運用上の大きなメリットはありませんでした。
4. A review of known implementations shows significant support for both protocols, though there were more implementations in support of SPF than of Sender ID. Further, the SPF implementations showed better upkeep and current interest than the Sender ID implementations.
4. 既知の実装を確認すると、両方のプロトコルが大幅にサポートされていることがわかりますが、SPFをサポートする実装はSender IDよりも多くありました。さらに、SPF実装は、Sender ID実装よりも優れた維持と現在の関心を示しました。
5. A survey of running MTAs shows fewer than 5% of them advertised the SUBMITTER extension, which is a Sender ID enabler. Only three implementations of it were found.
5. 実行中のMTAの調査では、Sender IDイネーブラーであるSUBMITTER拡張機能を宣伝したMTAは5％未満でした。その実装は3つしか見つかりませんでした。
6. There remain obstacles to deployment of protocols that use DNS RRTYPEs other than the most common ones, including firewalls and DNS servers that block or discard requests for unknown RRTYPEs. Further, few if any web-based DNS configuration tools offer support for RRTYPE 99 records.
6. ファイアウォールや不明なRRTYPEの要求をブロックまたは破棄するDNSサーバーなど、最も一般的なプロトコル以外のDNS RRTYPEを使用するプロトコルの展開には、依然として障害があります。さらに、RRTYPE 99レコードのサポートを提供するWebベースのDNS構成ツールはほとんどありません。
In light of the analysis in the previous section, the following conclusions are supported:
前のセクションの分析に照らして、次の結論がサポートされています。
1. The experiments comprising the series of RFCs defining the SUBMITTER SMTP extension (RFC4405), the Sender ID mechanism (RFC4406), the Purported Responsible Address algorithm (RFC4407), and SPF (RFC4408), should be considered concluded.
1. SUBMITTER SMTP拡張（RFC4405）、送信者IDメカニズム（RFC4406）、Purported Responsible Addressアルゴリズム（RFC4407）、およびSPF（RFC4408）を定義する一連のRFCで構成される実験は、結論と見なされるべきです。
2. The absence of significant adoption of the RRTYPE 99 DNS Resource Record suggests that it has not attracted enough support to be useful.
2. RRTYPE 99 DNSリソースレコードが大幅に採用されていないことは、有用なサポートを十分に引き付けていないことを示しています。
3. Unavailability of software implementing the protocols was not a gating factor in terms of the selection of which to use.
3. プロトコルを実装するソフトウェアが利用できないことは、どちらを使用するかを選択するという点で重要な要素ではありませんでした。
4. The absence of significant adoption of the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that there is not a strong community deploying and using these protocols.
4. [SUBMITTER]拡張、[SENDER-ID]、および[PRA]の大幅な採用がないことは、これらのプロトコルを展開および使用している強力なコミュニティがないことを示しています。
5. [SPF] has widespread implementation and deployment, comparable to that of many Standards Track protocols.
5. [SPF]は、多くのスタンダードトラックプロトコルに匹敵する幅広い実装と展開を持っています。
Appendix A is offered as a cautionary review of problems that affected the process of developing SPF and Sender ID in terms of their use of the DNS.
付録Aは、SPFおよびSender IDの開発プロセスに影響を与えた問題の、DNSの使用に関する注意レビューとして提供されています。
This document contains information for the community, akin to an implementation report, and does not introduce any new security concerns.
このドキュメントには、実装レポートに似たコミュニティ向けの情報が含まれており、新しいセキュリティ上の懸念は紹介されていません。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[PRA] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[PRA]リヨンJ.、「電子メールメッセージでサポートされる責任のあるアドレス」、RFC 4407、2006年4月。
[SENDER-ID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[SENDER-ID] Lyon、J。およびM. Wong、「Sender ID：Authenticating E-Mail」、RFC 4406、2006年4月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF] Wong、M。およびW. Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 4408、2006年4月。
[SUBMITTER] Allman, E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, April 2006.
[提出者] Allman、E。およびH. Katz、「電子メールメッセージの責任ある提出者を示すためのSMTPサービス拡張」、RFC 4405、2006年4月。
[DNS-EXPAND] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009.
[DNS-EXPAND] IAB、Faltstrom、P.、Austein、R。、およびP. Koch、「DNSを拡張するときの設計上の選択」、RFC 5507、2009年4月。
[DNS-IANA] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.
[DNS-IANA] Eastlake 3rd、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6195、2011年3月。
[OPENSPF] "Sender Policy Framework: Project Overview", <http://www.openspf.net>.
[OPENSPF]「送信者ポリシーフレームワーク：プロジェクトの概要」、<http://www.openspf.net>。
[SID-IMPL] "Sender ID Framework Industry Support and Solutions", October 2007, <http://www.microsoft.com/mscorp/safety/ technologies/senderid/support.mspx>.
[SID-IMPL]「Sender ID Framework業界のサポートとソリューション」、2007年10月、<http://www.microsoft.com/mscorp/safety/technology/senderid/support.mspx>。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
SPF was originally created by a community of interested developers outside the IETF, with the intent of bringing it to the IETF for standardization after it had become relatively mature and ready for the IETF Standards process.
SPFは、もともとIETFの外部の関心のある開発者のコミュニティによって作成されたもので、比較的成熟してIETF標準プロセスの準備が整った後、標準化のためにIETFに持ち込むことを意図しています。
At the time of SPF's initial development, the prospect of getting an RRTYPE allocated for SPF was not seriously considered, partly because doing so had high barriers to entry. As a result, at the time it was brought to the IETF for development and publication, there was already a substantial and growing installed base that had SPF running using TXT RRs. Eventually, the application was made for the new RRTYPE as a result of pressure from the DNS experts in the community, who insisted upon doing so as the preferred path toward using the DNS for storing such things as policy data.
SPFの初期の開発時には、SPTYPEにRRTYPEを割り当てる見込みは真剣に検討されていませんでした。その結果、開発と公開のためにIETFに持ち込まれた時点で、TXT RRを使用してSPFを実行するインストールベースがすでにかなり増えていました。結局、アプリケーションは、ポリシーデータなどを格納するためにDNSを使用することへの優先パスとしてそうすることを主張したコミュニティのDNS専門家からの圧力の結果として、新しいRRTYPEのために作成されました。
Later, after RRTYPE 99 was assigned (long after IESG approval of [SPF], in fact), a plan was put into place to effect a gradual transition to using RRTYPE 99 instead of using RRTYPE 16. This plan failed to take effect for four primary reasons:
その後、RRTYPE 99が割り当てられた後（実際には[SPF]のIESG承認後ずっと）、RRTYPE 16を使用する代わりにRRTYPE 99を使用するように段階的に移行する計画が導入されました。主な理由：
1. there was hesitation to make the transition because existing nameservers (and, in fact, DNS-aware firewalls) would drop or reject requests for unknown RRTYPEs (see Section 3 for evidence of this), which means successful rollout of a new RRTYPE is contingent upon widespread adoption of updated nameservers and resolver functions;
1. 既存のネームサーバー（および実際にはDNS対応のファイアウォール）が不明なRRTYPEの要求をドロップまたは拒否するため（これの証拠についてはセクション3を参照）、新しいRRTYPEの正常なロールアウトが条件となるため、移行を躊躇しました。更新されたネームサーバーとリゾルバー機能の広範な採用。
2. many DNS provisioning tools (e.g., web interfaces to controlling DNS zone data) were, and still are, typically lethargic about adding support for new RRTYPEs;
2. 多くのDNSプロビジョニングツール（DNSゾーンデータを制御するためのWebインターフェイスなど）は、新しいRRTYPEのサポートを追加することに通常は無気力です。
3. the substantial deployed base was already using RRTYPE 16, and it was working just fine, leading to inertia;
3. 実質的な配備基地はすでにRRTYPE 16を使用しており、正常に機能していて慣性につながりました。
4. [SPF] itself included a faulty transition plan, likely because of the late addition of a requirement to develop one -- it said:
4. [SPF]自体に、誤った移行計画が含まれていましたが、これはおそらく、開発計画の追加要件が遅れて追加されたためです。
An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type.
SPF準拠のドメイン名には、両方のRRタイプのSPFレコードが必要です（SHOULD）。準拠ドメイン名には、少なくとも1つのタイプのレコードが必要です。
which means both can claim to be fully compliant while failing utterly to interoperate. Publication occurred without proper IETF review, so this was not detected prior to publication.
つまり、どちらも完全に準拠していると主張しながら、完全に相互運用することができません。公開は適切なIETFレビューなしで行われたため、これは公開前に検出されませんでした。
It is likely that this will happen again if the bar to creating new RRTYPEs even for experimental development purposes is not lowered, and handling of unknown RRTYPEs in software becomes generally more graceful. Also, important in this regard is encouragement of support for new RRTYPEs in DNS record provisioning tools.
これは、実験的な開発目的であっても新しいRRTYPEを作成するための基準が低下せず、ソフトウェアでの不明なRRTYPEの処理が一般的に優雅になった場合に再び発生する可能性があります。また、この点で重要なのは、DNSレコードプロビジョニングツールでの新しいRRTYPEのサポートの推奨です。
Fortunately, in the meantime, the requirements for new RRTYPE assignments was changed to be less stringent (see [DNS-IANA]). Also, the publication of [DNS-EXPAND] has provided some useful guidance in this regard. However, there is still a common perception that adding new types of data to the DNS will face resistance due to the lack of appropriate software support.
幸いなことに、当面の間、新しいRRTYPE割り当ての要件はそれほど厳しくないように変更されました（[DNS-IANA]を参照）。また、[DNS-EXPAND]の公開は、この点に関していくつかの有用なガイダンスを提供しています。ただし、適切なソフトウェアサポートがないために、新しいタイプのデータをDNSに追加すると抵抗に直面するという一般的な認識はまだあります。
There are DNS experts within the community that will undoubtedly point to DNS servers and firewalls that mistreat queries for unknown RRTYPEs, and to overly simplistic provisioning tools, and claim they are broken as a way of answering these concerns. This is undoubtedly correct, but the reality is that they are among us and likely will be for some time, and this needs to be considered as new protocols and IETF procedures are developed.
コミュニティ内には、不明なRRTYPEのクエリを誤用し、過度に単純化したプロビジョニングツールを使用するDNSサーバーとファイアウォールを間違いなく指摘し、これらの懸念に答える方法として壊れていると主張するDNSエキスパートがいます。これは間違いなく正しいですが、実際にはそれらは私たちの中にあり、しばらくの間はそうなる可能性があり、これは新しいプロトコルとIETFの手順が開発されるときに考慮する必要があります。
The following provided operational data that contributed to the evidence presented above:
上記の証拠に貢献した運用データは次のとおりです。
Cisco: contributed data about observed Sender ID and SPF records in the DNS for a large number of domains (DNS survey #1)
シスコ：多数のドメインのDNSで観測されたSender IDおよびSPFレコードに関するデータを提供（DNS調査＃1）
Hotmail: contributed data about the difference between RFC5321.MailFrom and RFC5322.From domains across large mail volumes, and a survey of DNS replies observed in response to incoming mail traffic (DNS survey #3)
Hotmail：RFC5321.MailFromとRFC5322.Fromのドメイン間の大きなメールボリュームの違いに関するデータ、および受信メールトラフィックへの応答で観察されたDNS応答の調査（DNS調査＃3）
John Levine: conducted a survey of DNS server logs to evaluate SPF-related query traffic
John Levine：SPF関連のクエリトラフィックを評価するためにDNSサーバーログの調査を実施
McAfee: provided details about their SUBMITTER implementation and usage statistics
McAfee：送信者の実装と使用統計に関する詳細を提供
Santronics: contributed data about the use of the SUBMITTER extension in aggregate SMTP client traffic
Santronics：集計されたSMTPクライアントトラフィックでのSUBMITTER拡張機能の使用に関する寄稿データ
The Trusted Domain Project: contributed data about the difference between Sender ID and SPF results, conducted one of the detailed TXT/SPF RRTYPE surveys including collecting timing data (DNS survey #2), and conducted the MTA SUBMITTER survey
Trusted Domain Project：Sender IDとSPFの結果の違いに関するデータの提供、タイミングデータの収集を含む詳細なTXT / SPF RRTYPE調査の1つ（DNS調査＃2）、MTA SUBMITTER調査の実施
The author would also like to thank the following for their contributions to the development of the text in this document: Dave Crocker, Scott Kitterman, Barry Leiba, John Leslie, John Levine, Hector Santos, and Alessandro Vesely.
著者はまた、この文書のテキストの作成に貢献してくれたDave Crocker、Scott Kitterman、Barry Leiba、John Leslie、John Levine、Hector Santos、およびAlessandro Veselyに感謝します。
Author's Address
著者のアドレス
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA
Murray S. Kucherawy Cloudmark 128 King St.、2nd Floor San Francisco、CA 94107 USA
Phone: +1 415 946 3800
EMail: superuser@gmail.com