インシデントの後、私は答えが見つからないという質問があります。実際のヘッダーはクライアントからのものなので提供できません。
メールサーバーとしてOffice365テナントを使用している会社を考えてみましょう。ドメインはexample.comで、メールアドレスは[email protected]です。したがって、従業員全員が[email protected]アカウントを持っています。
会社はデフォルトのOffice365 SPFを公開しました:v=spf1 include:spf.protection.Outlook.com -all
同社はDKIMを発行しておらず、DMARCポリシーも持っていません。
ランダムなOutlookアカウント([email protected])でSMTPプロトコルを使用してsmtp-mail.Outlook.comまたはOutlook.office365.comに接続し、name @ example.comを使用して電子メールを作成することはできますか?
メールが適切なサーバーから送信されると、SPFは通過します。問題は、MicrosoftがSMTPサーバー経由で送信された電子メールに対してアクセス制御を実行することについての詳細です。
この質問は、パブリックにアクセス可能な電子メールもホストする、あなたのためにメールを管理している他の企業におそらく存在するでしょう。
ランダムなOutlookアカウント([email protected])でSMTPプロトコルを使用してsmtp-mail.Outlook.comまたはOutlook.office365.comに接続し、name @ example.comを使用して電子メールを作成することはできますか?
通常はありません。デフォルトでは、O365へのすべてのSMTP接続は最初に認証される必要があります。
認証されていないSMTPコネクタが設定されているドメインの場合、通常、特定のIPアドレス、つまり、ドメインにメールを送信すると信頼できるアドレスからのメールのみを受け入れるように制限されます。
サードパーティの電子メールプロバイダーは認証を異なる方法で処理する場合があり、実際にはこのタイプのなりすましの影響を受ける可能性があります。
anyメールサーバーをSPFレコードに含める場合、指定するのはあなたはそのサーバーを信頼するであり、許可を得てメールを送信するだけです。
単一のドメインexample.com
に対してSMTPサーバーを実行し、そのサーバーへのログインをさまざまなユーザーに提供する場合を考えます。あなたは学生のプレースメントを引き受け、それらにアドレス[email protected]
を与えます。彼らはあなたがサーバーのセキュリティを台無しにしたことを発見し、拒否されたり書き換えられたりすることなく[email protected]
からメールを書くことができます。 SPFはdomainをserverに結び付けるだけであり、sersの知識がないため、この乱用を検出できません。
複数のドメインを実行するサーバーにSMTPサービスを委任する場合、状況は事実上同じです。どのユーザーがどのドメイン(およびそのドメインのどのアドレス)からの送信を許可されているかを判断するのは、そのサーバー次第です。 MicrosoftがOffice365でこれを実行できなかった場合、重大なセキュリティ違反と見なされますが、SPFはそれを検出しません。
同じことがDKIMにも当てはまることに注意してください。クライアント(Outlook、Thunderbirdなど)によってメールが送信された後、署名は一般に共有サーバーに追加されるため、あなたはそのサーバーを信頼しています署名のみ正当なメッセージ。
この信頼の層を削除できる唯一の方法は、SMTPサーバーに送信する前に(たとえば、GPGまたはS/MIMEを使用して)メッセージを署名または暗号化することですメールクライアント内。ただし、これに対するサポートは普遍的ではなく、特定の公開キーに対してメッセージをチェックする必要があることを人々に通知する方法が必要であるため、毎日のスパム防止には特に役立ちません。
SPFは適切に機能しますが、大きな制限があります。マルチテナントの電子メールサーバーの場合、サーバーを承認された送信者として指定すると、その送信者を使用するすべてのユーザーも承認されます、ただし、電子メールがそのサービスからホストするドメインに送信できないことを確認する内部チェック。ただし、この種のチェックは、顧客を保護するためのビジネスロジックチェックであり、各メールホスティングサービス次第です。
具体的には、Office 365の場合 初期ドメイン用にDKIMを設定します 。これにより、説明した問題が少なくとも1つのレベルで解決されます。ユーザーが独自の中央署名プロセスで電子メールに署名する場合(兆候はそうであることが示されています)、偽装されたヘッダーが有効になるため、DKIMでも役に立ちません。