SPFは、Google、Yandex、Mail.Ru、Microsoft、Ramblerなどの大手企業に採用されています。 YahooはSPFをサポートしていませんが、DKIMの開発を促進しようとしていますが、あまり成功していません。
だから-SPFはどのように機能しますか？
仕事の一般原則
基本的な考え方は、アドレスのホストが、どのアドレスからメールが期待されるべきか、および非準拠の場合のエラーの解釈方法を示すということです。 このデータは送信者による確認の推奨事項にすぎないことを理解することが重要です。 はい、はい、もちろん、標準は受信側が結果を処理する方法を説明していますが、何らかの理由で、受信側は完全に準拠する、独自の方法で解釈する、または推奨事項を完全に無視するために、彼らが好きなことを実際に行うことができます。
技術的な詳細
データを配置するには、DNSのTXTフィールドを使用します。 そのため、IANAはSPFにコード99のDNSフィールドを割り当てました。 SPFフィールドの形式はTXTと同じです。 一般に、TXTフィールドの使用は最適ではありませんが、問題はすべてのDNSサーバーとクライアントが新しいSPFレコードタイプを理解するわけではないことです。 したがって、TXTとSPFの併用は優れたアプローチと見なされ、相互運用性と将来の開発を保証します。
標準では、SPF要件を満たすドメインに両方のタイプのレコードを含めることを推奨しています。 ただし、少なくとも1つのエントリが存在する必要があります。 2つのエントリがある場合、それらは同一でなければなりません。 例：
example.com。 IN TXT "v = spf1 + mx a：colo.example.com/28 -all"SPFレコードが設定されている場合、TXTレコードは無視する必要があります。
example.com。 IN SPF "v = spf1 + mx a：colo.example.com/28 -all"
相互作用メカニズム
SPFを使用したメール交換は、次のアルゴリズムに従って行われます。
mx.example.comメールサーバーは、user @ example.netに電子メールを送信します。 example.com DNSレコードには、次の行が含まれています。
mx.example.com。 IN A 208.77.188.166
example.com。 MX 10 mx.example.comで。
example.com。 IN TXT "v = spf1 + mx -all"
そのため、mx.example.comはexample.net SMTPへの接続を確立し、そこから受信します。
>> 220 example.net ESMTP Service（Mailer v1.0）ready at 07/30/2009 12:28:21 UTCその後、mx.example.comがHELO / EHLOを通じて送信されます。
<< HELO mx.example.comホストの設定によっては、このプレゼンテーションの後に、提示された名前がSPFルールに準拠しているかどうかのチェックが既に行われている場合がありますが、この場所では必要ありません
>> 250 example.net Hello mx.example.com。、はじめましてしかし、この場所では、MAIL FROMが送信者によって発行された後、必須のチェック、結果の解釈、およびそれに対する反応が続きます。
<<メール送信元：<user@example.com>
現時点では、SPFをチェックするモジュールは次のことを行います。 DNSクエリが進行中です。 SPFおよびTXTフィールドが要求されます。 受信した応答にSPFルールが含まれている場合、それが解析され、コンプライアンス分析が実行されます。 この例では、このルールは「v = spf1 + mx -all」です。 ルールに従って、MXレコードがチェックされ、レコードで指定されたIPアドレスが取得されます。これは、接続された送信者のDNS名とIPアドレスの表現から取得されます。 この場合、すべてが一致し、コントロールがメーラーに返され、メーラーはメッセージの受信を開始します。
接続された送信者の実際のIPが突然異なる場合、アナライザーはメーラーに着信メッセージが無効であることを通知し、まったく受け入れないか、極端な場合は個別にマークする方がよいでしょう。
記録フォーマット
SPFエントリは次のようになります。
example.com。 IN SPF "v = spf1 + mx a：colo.example.com/28 -all"
このエントリには次の情報が含まれます。
SPFバージョン-1（ところで、これまでに使用された唯一のもの）
レターには、example.comのMXレコードに対応するIPアドレスを持つ送信者がいる場合があります
レターには、colo.example.com / 28サブネット上のアドレスの1つに対応するIPアドレスを持つ送信者がいる場合があります
他のすべての場合、アドレスがリストされた条件を満たさない場合、送信者が無効であると見なします。
一般に、条件には2つの部分があります-決定要因とメカニズムです。
修飾子は、「+」合格、「-」失敗、「〜」SoftFail、「？」です。 ニュートラル
メカニズム：all、include、A、MX、PTR、IP4、IP6、exists
条件チェックの結果は、次の特定の結果になります。
*なし-ドメインにレコードがないか、ドメインをまったく検証できないことを意味します。 一般に、明確な回答はありません。
*ニュートラル-ドメイン所有者がIPが許可されているかどうかを望んでいない、または判断できない状況で発生します。 この結果は、なしと同じ方法で処理する必要があります。
*合格-すべてが正常であり、受信者が手紙を受け入れることができることを意味します。
*不合格-手紙が受け入れられないことを明確に示します。 証明書利用者は、レターにマークを付けるか、ドロップすることができます。
* SoftFail-FailとNeutralの間にあります。 受信者は、この結果のみに基づいて手紙を破棄しないでください。
* TempError-検証時にクライアントが一時的なエラーを受け取った場合に発生する結果。 メッセージは受け入れられるか、一時的に拒否されます。
* PermError-送信者のDNSレコードを正しく解釈できない場合に発生するエラー。
たとえば、実際のドメインを考えてみましょう。 Google.comとしましょう。 TXT要求が返されます
「V = spf1 include：_netblocks.google.com〜all」
_netblocks.google.comエントリからルールを有効にする必要があると書かれています。 興味深いことに、_netblocks.google.comにはAレコードはなく、TXTレコードのみがあります。 ここにあります：
「V = spf1 ip4：216.239.32.0/19 ip4：64.233.160.0/19 ip4：66.249.80.0/20 ip4：72.14.192.0/18 ip4：209.85.128.0/17 ip4：66.102.0.0/20 ip4：74.125。 0.0 / 16 ip4：64.18.0.0/20 ip4：207.126.144.0/20？すべて»
Googleのメールサーバーを配置できるサブネットが一覧表示されます。 ニュートラル修飾子を使用した最後のallメカニズムは、送信者アドレスが許可された範囲内にない可能性があることをアナライザーに伝えます。 外部アドレス空間からの手紙は、追加でチェックすることをお勧めします。無条件に拒否しないでください。 Googleのような大規模な構造の場合、これは正しい決定です。作業中に一時的な障害や予備への切り替えなどで住所が変わる可能性があるためです。 また、アドレスは転送によって異なる場合があります。
ランブラーの巧妙なSPFレコード：
「V = spf1 ip4：81.19.66.0/23 ip4：81.19.88.0/24 -exists：％{ir} .spf.rambler.ru -exists：％{l} .u.spf.rambler.ru〜all」
ここでは、メールの受信を許可する2つのサブネットと、メールのFailチェックの結果のソースの2セットがあります。
配送の問題
次のスキームを想像してください-ユーザーがvasily@xyz.comからpupkin@mylo.ruにメールを送信すると、pupkin @ gmail.comに自動転送されます。 また、xyz.comドメインにはSPF“ v = spf1 + mx -all”があります。 その結果、gmail.comの最終受信者はチェックを行い、実際の送信者のアドレスと指定されたアドレスとの不一致を受け取り、SPFの規則に従ってレターを受け入れません。 この問題を解決するために、SRS：Sender Rewriting Schemeがあります。 一言で言えば-フォワーダーはreturn-pathヘッダーを書き換えます。
一般的に、この瞬間は非常に物議を醸すと信じています。 中間メールボックスを使用して別のメールボックスにトラフィックをリダイレクトすることは、スパム攻撃に非常に似ています。 たとえば、私はボックスを登録し、可能な限りそれを消し、100万のメーリングを購読し、スパムで埋めたい特定のボックスにリダイレクトを配置します。 送信者がSPFを持ち、転送メーラーにSRSがない場合、ターゲットはこれらのフローをスパムとして拒否しますが、SRSを実行すると、完全に「正当な」メールフローを受信します。
おわりに
SPFは、送信されるメールの正当性を評価するためのシンプルでかなり効果的な方法です。 メールサーバーの管理者は、最小限のジェスチャーを使用してDNSにSPFレコードを追加する必要があります。 主要な一般的なMTAによる実装とサポートの容易さにより、SPF配信がますます広くなり、すべてのメールユーザーにメリットがあり、メールトラフィックが減少し、一般的に世界がより良い場所になります:)