web-dev-qa-db-ja.com

SPFの「ハードフェイル」にもかかわらずメールが正常に配信されるのはなぜですか？

電子メールにSPF hardfailのマークが付けられているのに、偽造された電子メールが主要な電子メールプロバイダー（gmail.com、Outlook.com）に配信される理由を理解しようとしています。メールはMicrosoft Exchangeにも配信され、同じSPFレコードに対してPermErrorがスローされます。

壊れたSPFレコードを定義するSOME_DOMAIN.comドメインを使用してメールを送信しています。電子メールは、SOME_DOMAIN.comのSPFレコードに明示的にリストされていない自分のIPアドレスから送信されます。 SOME_DOMAIN.comのSPFレコードには次の3つのプロパティがあり、最初の2つはSPF RFC-4408の違反です。

  1. include:のため、SPFレコード全体を解決するには10を超えるDNSクエリが必要です。
  2. SPFレコードの1つに構文エラーがあり、python-spfが解析エラーをスローします。
  3. SPFレコードには、ルール~allと-allの両方が含まれ、すべてのアドレスのセットはsoftfailとhardfail

Outlook @ comのアドレスになりすましてadmin@SOME_DOMAIN.comになりすましたメールは、配信されたメールのSMTPヘッダーに次のエラーが含まれます。このメールは通常はユーザーの受信トレイに配信されます：

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmailもユーザーの受信トレイにメールを配信しますが、別のSPFエラーをスローします。

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

ここで何が起こっているのでしょうか？ SPF hardfailにもかかわらずメールが配信されるのはなぜですか？壊れたSPFレコードがあるということは、他のSMTPサーバーがSPFを完全に無視するということですか？または私がここで見逃しているものがあります...

emailexchangesmtpspf
9
Rook

多くのサイトでSPFの設定が非常に悪いため、MTAを受信するとhardfailは通知のみとしてカウントされ、スパム検出スコアに含まれるだけです。最終的には、SPF障害がどのように処理されるかは、MTAの管理者次第です。

16
Flup

SPFエラー状態は、目的のポリシーについて何も示していません。そのため、メッセージを受け入れるかどうかについてのガイダンスはありません。意図されたポリシーが+allである可能性があります。この場合、メールの受付は正常です。 Googleはこのドメインが標準に準拠していないことに寛容であるようです。

送信者アドレスを検証する場合、SPFポリシーの拒否（-all）も信頼できません。このようなメールを拒否することが不適切である場合がいくつかあります。

  • 契約メーラーから送信されたメール（これらの人々は、ポリシーに違反した場合に報酬を受け取ります。）;
  • Webフォームおよびその他の自動システムから送信されたメール。
  • メーリングリストまたはその他の転送メカニズムによって転送されたメール。そして
  • SPFレコードの単なる誤った構成（一般的ではありませんが、十分ではありません）。

ハードフェールを延期できるかなり小さいサーバーを実行しています。これにより、正当な失敗をホワイトリストに登録できます。送信者がメールが配信されないことに気付いた場合、設定を修正することがあります。場合によっては、関連するpostmasterへの連絡を試みますが、多くのドメインにはpostmasterアドレスがありません。

より強力なポリシーを適用したいユーザーは、まだ標準ではないDMARCを使用できます。メールは引き続き配信される可能性がありますが、そのポリシーで指定されているように隔離または拒否される場合があります。ポリシーに失敗したメールは、通常の受信トレイではなく、スパムフォルダに配信される可能性があります。

SPFハード障害は、送信サーバーのIDを検証するために信頼できるようです。私は少し前に調査しましたが、HELO名のソフトフェイルでも、着信メッセージを失敗または延期する合理的な理由であることがわかりました。

多くのメールサーバーにはSPFレコードがありません。メールサーバーにSPFレコードがない場合は、親ドメインに対してSPFレコードを確認します。これは非標準ですが効果的です。メール管理者には、PTRレコードにリストされているサーバーIPのSPFレコードがあることを確認することをお勧めします。サーバーは、PTRレコードから返された名前で自身を識別する必要もあります。逆引きDNS検証に対応するAレコードがあることを確認します。

6
BillThor