Appendix B. Changes from RFC 4408 (RFC 4408からの変更)
Appendix B. Changes in Implementation Requirements from RFC 4408 (RFC 4408からの実装要件の変更)
この付録は、RFC 7208がその前身であるRFC 4408に対して行った主要な変更をまとめています。
B.1 主要な変更
B.1.1 SPF RRタイプの廃止
RFC 4408の要件:
- TXTレコードとSPF(タイプ99)レコードの同時公開
- 実装は両方のレコードタイプをチェックする必要がある
RFC 7208の変更:
- TXTレコードのみを使用(タイプ16)
- SPF RRタイプはサポートされなくなった
- 実装と展開の簡素化
理由: SPF RRタイプの採用率が非常に低く、デュアルタイプシステムが相互運用性の問題を引き起こしていた。
B.1.2 DNSクエリ制限の明確化
RFC 4408:
- DNSクエリ制限の記述が不十分
- "void lookup"制限が未定義
RFC 7208:
- 10 DNSクエリ制限の明確な定義
- "void lookup"制限の追加(推奨2)
- MXおよびPTRメカニズムの追加制限の詳細な説明
具体的な制限:
- 総DNSクエリ: ≤ 10 (include, a, mx, ptr, exists, redirect)
- mxメカニズムごと: ≤ 10アドレスクエリ
- ptrメカニズムごと: ≤ 10アドレスクエリ
- Void lookups: ≤ 2 (推奨)
- 評価時間: ≥ 20秒 (推奨)
B.1.3 "local-part"の処理
RFC 4408:
- local-part処理が不十分
- 空のlocal-partの処理が未定義
RFC 7208:
- 明確な規定:
<sender>にlocal-partがない場合、"postmaster"を使用 - 空のリバースパス(
<>)の処理を改善
例:
MAIL FROM:<>
→ SPFはHELO識別を使用、local-partは"postmaster"
B.1.4 "ptr"メカニズムへの強い反対
RFC 4408:
- "ptr"メカニズムは許可されているが推奨されていない
RFC 7208:
- "do not use"(使用しない)として明確にマーク
- メカニズム名に警告を追加
- パフォーマンスと信頼性の問題を強調
理由:
- DNS逆引きクエリが遅い
- サードパーティ(IPアドレス所有者)の設定に依存
- .arpaネームサーバーに負荷をかける
B.1.5 マクロ構文の修正
RFC 4408:
- マクロ構文定義が曖昧
RFC 7208:
- ABNF定義の改善
- マクロ展開ルールの明確化
- 境界ケースの修正
B.1.6 "exp"修飾子のセキュリティ考慮事項
RFC 4408:
- セキュリティ考慮事項が不十分に詳細
RFC 7208:
- 外部説明文字列に関するセキュリティ警告を追加
- 説明文字列の長さを制限することを推奨
- 説明がサードパーティからのものであることを識別する必要性を強調
B.2 実装要件の変更
B.2.1 MUST変更(実装する必要がある)
新しい要件:
- 実装はTXTレコードのみをクエリする必要がある(SPF RRはもうない)
- 実装は総DNSクエリ数を10に制限する必要がある
- 実装は"void lookup"制限を処理する必要がある
- 実装は制限を超えた場合に"permerror"を返す必要がある
削除された要件:
- SPF RRタイプのサポートは不要
- デュアルタイプレコードの変換ロジックは不要
B.2.2 SHOULD変更(実装すべき)
新しい推奨事項:
- 評価タイムアウトを実装すべき(少なくとも20秒)
- "void lookup"を2に制限すべき
- HELOとMAIL FROM識別の両方をチェックすべき
- SMTPトランザクション中にチェックを実行すべき
B.2.3 MAY変更(実装してもよい)
新しいオプション:
- 非標準アルゴリズムを使用してもよい(結果が同じである限り)
- "void lookup"制限を設定してもよい
- 説明文字列の長さを制限してもよい
B.3 用語の変更
B.3.1 識別名の標準化
RFC 4408:
- 複数の名前を使用: "MAIL FROM", "SMTP MAIL FROM", "reverse-path"
- 一貫性のない用語
RFC 7208:
- "MAIL FROM"識別の統一使用
- RFC5321.MailFromとして明確に定義
- RFC 5598標準用語への参照
B.3.2 "ADMD"用語の採用
RFC 4408:
- "domain owner", "sending domain"を使用
RFC 7208:
- "ADMD"(Administrative Management Domain)の採用
- 責任者のより正確な記述
B.4 セキュリティ考慮事項の強化
B.4.1 新しいセキュリティトピック
-
クロスユーザー偽装(セクション11.4):
- RFC 4408ではカバーされていない
- RFC 7208はドメイン内ユーザー偽装問題を明示的に議論
-
プライバシー露出(セクション11.6):
- DNSクエリ内のマクロが機密情報を漏らす可能性
- 送信者情報を含むマクロを慎重に使用することを推奨
-
信頼できない情報源(セクション11.5):
- 外部ヘッダーと説明のリスクの詳細な議論
- 検証とフィルタリングの重要性を強調
B.4.2 DoS保護の強化
RFC 4408:
- 基本的なクエリ制限
RFC 7208:
- 多層保護メカニズム
- 明確な制限値
- タイムアウト推奨
- "void lookup"制限
B.5 IANA登録の変更
B.5.1 SPF RRタイプ
RFC 4408:
- SPF RRタイプの登録(タイプ99)
RFC 7208:
- SPF RRタイプを廃止としてマーク
- TXTレコードのみを使用することを推奨
B.5.2 修飾子レジストリ
RFC 7208新規:
- SPF修飾子レジストリの作成
- 新しい修飾子の標準化された登録プロセス
- 未知の修飾子を無視する必要があるという要件
B.6 相互運用性の改善
B.6.1 レコード選択の明確化
RFC 4408:
- 複数レコードの処理が不明確
RFC 7208:
- 明確な規定: 複数のSPFレコードは"permerror"になる
- バージョン文字列の一致ルールの改善
- レコード連結ルールの明確化(複数の文字列)
B.6.2 エラー処理の標準化
RFC 7208の改善:
- すべてのエラー状況に明確な結果
- DNS エラーの標準化された処理
- タイムアウト処理の改善
B.7 下位互換性
B.7.1 互換性のある変更
ほとんどの変更は下位互換性があります:
- TXTレコードフォーマットは変更なし
- メカニズムと修飾子の構文は本質的に同じ
- コアアルゴリズムは一貫性を保つ
B.7.2 互換性に影響を与える可能性のある変更
-
SPF RRタイプの削除:
- 古い実装はまだSPF RRをクエリする可能性
- 推奨: SPF RRレコードを削除し、TXTのみを保持
-
より厳格な制限:
- "void lookup"制限は新しく追加された
- 一部の古いレコードは新しい制限を超える可能性
- 推奨: 制限に準拠するようにSPFレコードを最適化
-
"ptr"メカニズムへの反対:
- まだサポートする必要があるが、強く非推奨
- 推奨: 他のメカニズムに移行
B.8 ドキュメント構造の変更
RFC 7208の改善:
- より明確な章の構成
- 拡張例の追加(付録A)
- 実装推奨事項の追加(付録C-G)
- ABNF定義の提示の改善
B.9 移行ガイド
RFC 4408からRFC 7208への移行:
公開者:
- SPF RRレコードを削除し、TXTレコードのみを保持
- DNSクエリ数を確認して最適化(≤ 10)
- "ptr"メカニズムを"ip4"または"ip6"に置き換える
- "void lookup"数を検証(≤ 2)
- レコードが512オクテットを超えるかテスト
受信者:
- SPF RRタイプのクエリを停止
- 新しいDNSクエリ制限を実装
- "void lookup"制限を実装
- エラー処理ロジックを更新
- 評価タイムアウトの実装を検討
テスト:
# SPF検証ツールを使用してレコードをテスト
# 例: https://www.kitterman.com/spf/validate.html
# DNSクエリ数を確認
dig +short example.com TXT | grep "v=spf1"
# レコードサイズを検証
dig example.com TXT | grep -A1 "ANSWER SECTION"
B.10 参照ドキュメントの更新
RFC 7208は更新された標準を参照:
- RFC 5321 (RFC 2821を置き換え)
- RFC 5322 (RFC 2822を置き換え)
- RFC 5234 (ABNF更新)
- RFC 5598 (メールアーキテクチャ用語)
- RFC 5890 (国際化ドメイン名)