結果ラベルは診断ではありません
パーメエラー 永続的なエラーを示します SPF 評価されますが、固有の欠陥は特定されません。不正な形式の選択されたポリシー、複数適用可能 SPFレコード、再帰ポリシーが欠落しているか、評価制限を超えていると、別のルールによってこの結果が生成される可能性があります。すべてのpermerror 「 DNSルックアップが多すぎる」と変換するサポート応答は、管理者を間違った修復に誘導し、有効な送信者の認証を損なう可能性があります。
まず、評価に使用される ID と入力を保存します。接続アドレスを記録し、 HELO または メール送信元 コンテキスト、評価されたドメイン、送信者の引数、および時刻。次に、実際のDNS応答と選択したSPFポリシーを保存します。これらの入力がなければ、2 つの異なるレポートは、同じポリシーについての意見の相違ではなく、異なる ID または異なるスナップショットに関係する可能性があります。 RFC 7208 、セクション 2.3、2.4、および 8.7
最初にレコードの選択と構文を確認してください
SPFポリシーの選択には特定のルールがあります。複数のSPFレコードを選択するとpermerrorが発生します。それらはより大きなポリシーに統合されるものではなく、サプライヤーを分割するための便利な方法として扱われるべきではありません。 1 つのレコード内のTXT文字列は、複数の独立したレコードとは異なります。レビュー担当者がプレゼンテーションの詳細と実際の選択問題を区別できるように、レコードの境界を保持します。
構文についても、ポリシーの完全なレビューが必要です。 RFC 7208では、メカニズムの評価の前に構文チェックが必要です。したがって、たとえ以前のメカニズムが一致することを期待していたとしても、無効なメカニズムが問題になる可能性があります。認識されないメカニズムと無視された認識されない修飾子は、互換性のあるカテゴリではありません。見慣れないトークンをすべて削除するという曖昧なガイダンスは避けてください。エラーかどうかを判断する前に、文法上の役割と標準の処理を確認してください。 RFC 7208 、セクション 3.2、4.5、4.6 および 6
次に、評価予算の失敗を分類します。
DNS の原因となる期間全体のバジェットには、評価中に a、mx、ptr、existing、およびリダイレクト数が含まれます。制限は 10 で、それを超えるとpermerrorが生成されます。これは、単にDNSパケットの数、トップレベル インクルードの数、または一意のサプライヤーの数ではありません。再帰はバジェットを共有し、キャッシュは論理的に評価された用語を削除しません。
他の制限には独自のラベルが必要です。 Void 応答の SHOULD レベル制限は 2 で、許可された設定と、設定可能な場合の推奨デフォルト値は 2 です。該当する制限を超えるとpermerrorが発生します。 MX処理には追加の必須制約があります。 「レコードには 9 つのインクルードしか含まれていない」という記述は、これらの他の原因を除外するものではなく、生のパケット数が多いということだけでは、全体の 10 タームの制限を超過したことを証明するものではありません。 RFC 7208 、セクション 4.6.4
エラー結果を認証結果から分離する
失敗は、クライアントが評価された ID に対して許可されていないことを表明します。 Permerror は、永続的なエラーのため、評価で意図した認可結果が得られなかったことを意味します。 温度エラー 一時的なエラーを表します。 None も別個の結果であり、インクルードまたはリダイレクトを通じて検出された場合は特別なマッピングが行われます。修正措置を説明する場合、これらのラベルを単一の「 SPF失敗」バケットにまとめてはいけません。
受信者は、独自のポリシーに基づいて結果を処理する方法を決定します。証拠がそのリンクをサポートしない限り、拒否されたメッセージは、どのSPF欠陥が拒否の原因となったかを証明しません。同様に、受信されたメールはポリシーが有効であったことを証明するものではありません。認証診断と配信処理を別のフィールドに保管し、1 回のDNS修復ですべての配信問題が解決すると約束するのは避けてください。 RFC 7208 、セクション 5.2、6.1、および 8
明示的な停止理由を含むトリアージ ワークシート
選択、解析、評価に分かれたワークシートを使用します。選択では、クエリ名、応答、 TXTレコード 選択されたSPFレコードの境界と数。解析では、正確な連結されたレコード テキスト、パーサー バージョン、問題のあるトークン (存在する場合)、およびルール違反が保持されます。元の証拠を保存する前にエラーを正規化して除去しないでください。
評価では、到達した各メカニズムまたは修飾子、現在のドメイン、拡張されたターゲット、累積用語数、応答分類、再帰的な子の結果、および継続の決定を記録します。無効な合計と補足制限を区別してください。サポートされている最初の停止理由をマークします。パーサーが評価前にポリシーを拒否した場合、別の考えられる問題を示すためだけに、評価者が実行しなかったパスを作成しないでください。
提案された修正では、対処する欠陥、意図された承認を確認する所有者、および引き続き機能する必要があるルートを指定する必要があります。未解決の二次的所見を個別に記録します。不正なポリシーには過度の依存関係グラフが含まれている可能性もありますが、調査者はどの結論が観察され、どの結論が有効な評価が保留されるまで静的な懸念として残るかを説明する必要があります。
架空の診断: 2 つの同一のラベル、異なる修理
架空のケース A では、ドメインは 2 つの個別のTXTレコードを発行し、どちらもSPFポリシーとして認定されます。有用な診断は、過剰な検索数ではなく、レコード選択エラーです。提案された修復では、すべての正当なルートを確認した後、目的の認可を 1 つのサポートされているポリシーに調整する必要があります。任意のレコードを削除すると、必要なサービスがサイレントに削除される可能性があります。この場合、実際のDNS応答や修正は収集されませんでした。
架空のケース B では、構文的に有効な 1 つのポリシーが、一致する前に 11 番目に数えられる DNS の原因となる用語を試行するネストされたルートに従います。有用な診断は、全体の予算を超過していることです。ポリシーはすでに 1 つの選択されたレコードであるため、 TXT文字列を結合してもこの問題は解決されません。代わりに、レビューには正確な依存関係パスと、送信者の範囲を維持するサポートされる再設計が必要です。
3 番目の架空のレポートには、「 permerror 」のみが記載されており、レコードのスナップショットやトレースは含まれていません。正しい結果は証拠が不十分であり、A と B の間の推測ではありません。プライベート メッセージのコンテンツと不要なアドレスを除外した、承認されたチャネルを通じて最小限の診断バンドルを要求します。これらのシナリオは概念的な比較であり、実行されたフィクスチャ、レシーバーの結果、または指定されたプロバイダーが誤って構成されているという証拠ではありません。
受け入れおよびリリースの基準
修理の請求は「 SPFが修正されました」よりも狭い範囲にする必要があります。レコードの選択、構文、特定の評価パス、または特定のサプライヤーの依存関係が修正されたかどうか、またその主張を裏付ける証拠は何かを述べます。提案された変更が意図しない送信者を許可したり、正当な送信者を除外したりしないことを検証します。別途確認されない限り、受取人の最終的な納品結果はクレームの対象外としてください。
このドラフトでは、カウントされた各用語と正確な失敗した分岐を示す必要な注釈付きパスは未処理のままです。実際の問題が解析または選択である場合は、その主要な証拠も保持し、それが記事の意図された範囲をどのように満たしているかについて人間によるレビューを受けてください。メカニズムが処理される前に停止するエラーに対して評価されたパスを作成しないでください。
ここでは、スキャン、パーサーの実行、 DNS変更、メッセージ テストは実行されませんでした。オリジナルの証拠、人間によるレビュー、ソースの適用性、生産ルート、視覚的なアクセシビリティ、および所有者の公開は未解決のままです。この原稿では、トリアージのフレームワークと架空の推論の例を提供していますが、運用診断が完了したという主張は明示的に差し控えられています。