Appendix A. Collected ABNF .......................................42 Appendix B. Extended Examples ....................................44 B.1. Simple Examples .............................................44 B.2. Multiple Domain Example .....................................45 B.3. DNSBL Style Example .........................................46 B.4. Multiple Requirements Example ...............................46
目次
1. はじめに 4
1.1. プロトコルの状態 4
1.2. 本文書で使われる慣例 5
2. 運用 5
2.1. HELOアイデンティティ 5
2.2. MAIL FROMアイデンティティ 5
2.3. 権限の公開 6
2.4. 権限の検査 6
2.5. 結果の解釈 7
2.5.1. None 8
2.5.2. Neutral 8
2.5.3. Pass 8
2.5.4. Fail 8
2.5.5. SoftFail 9
2.5.6. TempError 9
2.5.7. PermError 9
3. SPFレコード 9
3.1. 公開 10
3.1.1. DNSリソースレコードタイプ 10
3.1.2. 複数のDNSレコード 11
3.1.3. 単一のDNSレコード中の複数行 11
3.1.4. レコードのサイズ 11
3.1.5. ワイルドカードレコード 11
4. check_host() 関数 12
4.1. 引数 12
4.2. 結果 13
4.3. 処理の開始 13
4.4. レコードの検索 13
4.5. レコードの選択 13
4.6. レコードの評価 14
4.6.1. 要素の評価 14
4.6.2. 機構 15
4.6.3. 変更子 15
4.7. デフォルトの結果 16
4.8. ドメインの定義 16
5. 機構の定義 16
5.1. “all” 17
5.2. “include” 18
5.3. “a” 19
5.4. “mx” 20
5.5. “ptr” 20
5.6. “ip4”および“ip6” 21
5.7. “exists” 22
6. 変更子の定義 22
6.1. redirect：問い合わせのリダイレクト 23
6.2. exp：説明 23
7. Received-SPFヘッダフィールド 25
8. マクロ 27
8.1. マクロの定義 27
8.2. 展開の例 30
9. 影響 31
9.1. 送信ドメイン 31
9.2. メーリングリスト 32
9.3. 転送サービスとエイリアス 32
9.4. メールサービス 34
9.5. MTA中継 34
10. セキュリティに関する考察 35
10.1. 処理制限 35
10.2. SPFで認証された電子メールが他の偽称アイデンティティを持つ可能性 37
10.3. 偽称されたDNSとIPデータ 37
10.4. ユーザ横断偽称 37
10.5. 信頼できない情報源 38
10.6. プライバシーの露出 38
11. 貢献してくれた人々とお礼の言葉 38
12. IANAに関する考察 39
12.1. SPF DNSレコードタイプ 39
12.2. Received-SPFメールヘッダフィールド 39
13. 参照資料 39 （40）
13.1. インターネット標準にかかわる参照資料 39 （40）
13.2. 情報に関する参照資料 40 （41）
付録A. ABNF記法のまとめ 42
付録B. 拡張された例 44
B.1. 単純な例 44
B.2. 複数ドメインの例 45
B.3. DNSBL様式の例 46
B.4. 複数の要求がある例 46
1. Introduction
The current E-Mail infrastructure has the property that any host injecting mail into the mail system can identify itself as any domain name it wants. Hosts can do this at a variety of levels: in particular, the session, the envelope, and the mail headers. Although this feature is desirable in some circumstances, it is a major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). Furthermore, many domain name holders are understandably concerned about the ease with which other entities may make use of their domain names, often with malicious intent.
1. はじめに
現在の電子メールインフラストラクチャには、メールをメールシステムに送出するホストが、使いたいドメイン名を何でも自分のアイデンティティに設定できるという特性がある。ホストは、セッション、エンベロープ、メールヘッダなど、様々なレベルでこれを実行できる。この特徴は状況によっては望ましいが、UBE（迷惑メール、またはスパム）削減の大きな障害である。さらに、多くのドメイン名所有者は当然、自分のドメイン名を他の誰かが、多くは悪い意図で、簡単に利用できてしまうことを問題視している。
This document defines a protocol by which domain owners may authorize hosts to use their domain name in the "MAIL FROM" or "HELO" identity. Compliant domain holders publish Sender Policy Framework (SPF) records specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction.本文書は、ドメイン所有者がホストに対し、“MAIL FROM”や“HELO”アイデンティティ中で自ドメイン名を使う権限を与えられるようなプロトコルを定義する。本文書に準拠するドメイン所有者は、自ドメイン名の使用を許可するホストを定義した送信者ポリシフレームワーク（Sender Policy Framework：SPF）レコードを公開し、本文書に準拠するメールサーバは、公開されたSPFレコードを使って、メールトランザクション中に、対象の“HELO”または“MAIL FROM”アイデンティティを用いて送信MTA（メール転送エージェント）の権限をテストする。
An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses. Furthermore, if a claimed identity fails verification, local policy can take stronger action against such E-Mail, such as rejecting it.メール受信者にはさらに、アイデンティティの使用が認証された後、メールに関するローカルポリシの決定を、ホストのIPアドレスではなく送信者のドメインに基づいて行えるという利点もある。これが利点となるのは、ホストのIPアドレスの評判よりもドメイン名の評判の方がより正確なことが多いためである。さらに、名乗っているアイデンティティの認証に失敗した場合、ローカルポリシはそのような電子メールに対して、拒否するなど、強気な動作を取れる。
1.1. Protocol Status
SPF has been in development since the summer of 2003 and has seen deployment beyond the developers beginning in December 2003. The design of SPF slowly evolved until the spring of 2004 and has since stabilized. There have been quite a number of forms of SPF, some written up as documents, some submitted as Internet Drafts, and many discussed and debated in development forums.
1.1. プロトコルの状態
SPFは2003年の夏から開発されており、2003年12月に開発者たちが実験運用を始めたことがわかっている。SPFの設計は2004年春までゆっくりと行われ、それ以来以停滞している。SPFにはかなり多くの形式があり、一部は文書として記録され、一部はインターネットドラフトとして提出され、多くは開発フォーラムで議論された。
The goal of this document is to clearly document the protocol defined by earlier draft specifications of SPF as used in existing implementations. This conception of SPF is sometimes called "SPF Classic". It is understood that particular implementations and deployments may differ from, and build upon, this work. It is hoped that we have nonetheless captured the common understanding of SPF version 1.本文書の目的は、以前のSPFドラフト仕様によって定義されたプロトコルを、既存の実装で使われている通りに明確に記録することである。このSPFという概念はしばしば「SPFクラシック」と呼ばれる。既存の実装や配備は本文書とは異なったり、本文書に基づいていることが分かっている。それにもかかわらず、SPF第1版の共通理解を捉えたいと考える。
[Page 4]
| 《PREV》 |