web-dev-qa-db-ja.com

ドメイン経由でのスパムメールですが、SPFレコードが存在します

[email protected]はG Suite内の単なる配布グループですが、「via」[email protected]からランダムな人物の名前からメールが届きました。

Googleから追加された最新のSPFレコードがあり、他の人が自分のドメインを介してメールを送信できる方法や方法がよくわかりません。

私のドメインや受信者に具体的な情報を提供することなく、メッセージソースからのいくつかの参照を次に示します。

Date: Mon, 01 Apr 2019 23:41:44 -0500
Subject: Mass Shootings orchestrated to pass gun control for the Federal
 Reserve Shareholders planned U.S. Holocaust- How can your industry help?
From: 'Random Person' via Info <[email protected]>
<snipped>
Message-ID: <[email protected]>
Thread-Topic: Mass Shootings orchestrated to pass gun control for the Federal
 Reserve Shareholders planned U.S. Holocaust- How can your industry help?
Thread-Index: AWY0NTc5UrmPA22gl2edULFwYvLC7TIwMTU5
References: <[email protected]>
Mime-version: 1.0
Content-type: multipart/alternative;
    boundary="B_3637013229_1574776269"

ここでは関係ないと思いますが、すべてのユーザーが2FAを有効にしています。 [email protected]はドメイン内に登録されたアカウントではないため、これは明らかに電子メールで送信されます（確認されただけです）。

これがどのように起こったのか、それを防ぐ方法はありますか？

また、このメッセージには、Yahooを利用してドメインの「代理」でメールを送信する可能性があったこと以外は、重要な情報が含まれていないようです。

spoofingspf
9
LewlSauce

DNSレコードにSPFレコードを含めると、recipientがドメインに適したメールサーバーを知るのに役立ちます。受信者は有効なサーバーIPの送信ドメインを検索し、電子メールをどう処理するかを決定します。

  1. 送信IPがリストにある場合、電子メールはおそらくOKです。

  2. 送信IPがリストにない場合は、疑わしい扱いが必要です。

このチェックロジックでは、受信電子メールサーバーがSPFレコードをチェックするように構成されている必要があります。 SPFレコードをチェックしていない場合、SPFチェックプロセス全体は実行されません。

電子メールヘッダーにSPFフィールドが含まれていない場合、電子メールサーバーはSPFをチェックするように設定されておらず、この方法で会社を保護していません。

SPFチェックをオンにする方法を理解するには、電子メールサービスのドキュメントを調べる必要があります。

17
schroeder

SPFレコードがあるだけでは、だれもあなたの電子メールアドレスを、なりすましメッセージの要求された受信者として使用できないわけではありません。

最初に、SPFはSMTPエンベロープのみを考慮し、メールヘッダーのFromフィールドは考慮しません。両者が異なるメールを送信しても問題ありません。 SMTPエンベロープが何であったか（通常はメールヘッダーのReturn-Pathフィールドとして表示されます）についての質問の情報はありませんが、実際には、メールをスプーフィングするときに両方が異なることが一般的です。 Fromを気にするためには、DMARCをセットアップする必要があります。

また、SPFとDMARCの両方が設定されている場合でも、メールの受信者は実際にこれを確認する必要があります。多くの場合SPFをチェックしますが、ほとんどはDMARCをチェックしません。

詳細については、 DKIM用にすでに設定されている場合にSPF用にDMARCを設定するのはなぜですか？ も参照してください。

7
Steffen Ullrich

実際、SPFレコードは、ドメインを使用する正当なメールがどのサーバーから送信されたかを通知するだけです。ここでは、メール内のFrom行（RFC2822）ではなく、エンベロープ情報（SMTP/RFC2821）について話しています。

メールプログラムの内部では、通常、メールの内容（RFC2822）しか表示されないため、From行にドメインを使用するメールは、実際には別のエンベロープ送信者を使用して送信されている可能性があり、見る場合にのみ表示されます。 「X-Apparently-From」のような行がメールの配信に使用された送信者を明らかにするヘッダー。

また、SPFで指定されているサーバーの1つが危険にさらされている場合、ドメインを使用するメールは非常に合法的に送信される可能性があります。

2
P. Goetterup

ヘッダーの最初の行は常に
Received: from sender.hostname (203.0.113.0) by your.hostname
[〜＃〜] mta [〜＃〜] は、MTAを含むメッセージを受信するたびに、このヘッダーを付加することになっています。

[〜＃〜] mta [〜＃〜] によって受信されたすべてのメッセージには、少なくとも1つあります。なしにする唯一の方法は、SMTPで受信しないしないことです。誰かがこのメッセージをローカルのメールボックス/ maildirコピーに直接追加して、SMTPサーバーをバイパスした可能性はありますか？

0
user185953