電子メールの基礎と迷惑メール対策（送信ドメイン認証）

2022-06-13

今はSNSやチャットアプリも豊富にありますが、導入コストも低くオフィシャルな場面では使われる機会の多いメール（電子メール）です。メールアドレスの取得から利用まで簡単にできるため、詳しい仕組みを知らない人も多いと思います。

先日、業務で注文したことのある企業から送られてきた販促メール（キャンペーン情報）が、Gmailの迷惑メールフォルダに入っていました。

よくある事なのであまり気にせず開いてみると、何だか雰囲気が違います。

なりすましメールに振り分けられたメールのスクリーンショット

いつもはこんな感じで迷惑メールに振り分けられています。

違いは何だろう？と思って調べたところ、DMARCの検証失敗でGmailがなりすましメールに振り分けているようでした。

顧客に届くための迷惑メール対策で取り入れた送信ドメイン認証で、逆にもっとやっかいな扱いになるのも残念です。とは言え、電子メールの脆弱性対策や送信ドメイン認証は情報処理安全確保支援士試験の学習で必要でしたが、仕組みの理解が足りていなかったことが分かったので改めて復習しました。

電子メールの基礎知識

一般的な電子メールの送受信は、メールクライアントソフトから送信されたメールをメールサーバ（SMTPサーバ）が目的ドメインのメールサーバまで中継、受け取ったメールサーバは宛先ユーザ用のメールボックスに保存します。

宛先ユーザはメールクライアントソフトを使ってメールサーバへ接続し、メールボックスに保存されたメールを閲覧、又はローカルに転送します。

この時、送信者のメールクライアントソフトがMUA（Message User Agent）として電子メールの作成・送信（SMTPサーバへの接続・データ転送）を担当します。

その後、受け取ったSMTPサーバはMSA/MTA（Message submission agent/Message Transfer Agent）として受信したメールを目的ドメインのメールサーバまで転送し、受信先のメールサーバがMTA、MDA/MRA（Message Delivery Agent/Message retrieval agent）として宛先ユーザのメールボックスに保存します。

最後に、宛先ユーザーが送られたメールを閲覧する際は、宛先ユーザーが使うMUAがメールサーバーに接続し閲覧できる状態にします。

送信者のMUAから宛先メールサーバーまでの転送はSMTP（Send Mail Transefer Protocol）に則って送られ、宛先ユーザーから受信メールサーバーへの接続はPOPまたはIMAPで行われます。

メールヘッダ

先ほどのMUA、MTA、MDAがSMTPのプロトコルに則って送信、転送される際の一連の処理内容がメールヘッダに記載されます。そのため、メールヘッダの内容を見ることで「どこから」「どこを経由して」送られて来たのかを確認することができます。

メールヘッダ

メールヘッダの解析ツール

メールエンベロープとメールヘッダ

電子メールでは、先ほどのメールヘッダ以外にもエンベロープ（封筒）に記載されている情報も使われています。

例えば、メールクライアントソフトで表示される差出人（FROM）はメールヘッダに記載されている「ヘッダFROM」ですが、SMTPでは実際の送信元は「エンベロープFROM」となり、メールヘッダではReturn-Pathとして記載されています。

また、メールエンベロープはMTAが記載するため、一般的に使われるメールクライアントソフト（MUA）では指定ができないようになっています。

柔軟な運用が可能になるようにエンベロープFROM（TO）とヘッダFROM（TO）が分かれていますが、そのためにヘッダFROMは自由に指定ができ、なりすましメールの原因にもなっています。

SendmailコマンドでエンベロープFROMの指定

迷惑メール対策

必要のない第三者中継の禁止

かなり初期のインターネットでは送信先メールサーバに直接接続することができない場合もあったため、別のサーバを介してメールを配送する機能（第三者中継）がSMTPに残っています。

しかし、現在ではほとんどの場合で直接接続できるため「発信元 or 送信先メールアドレスがメールサーバの管理しているドメインの範囲」のメールだけの中継が原則となっています。その際、認証機能が無いと発信元メールアドレスの偽装で中継に使われるため、「SMTP-AUTH」や「POP before SMTP」などのユーザ認証と合わせて利用します。

メールリレーサービス

大量のメールを一度に送信する必要があるなどの場合は、メールリレーサービスを必要な中継として使います。

OP25B

OP25B（Outbound Port25 Blocking）はISP（インターネットサービスプロバイダ）が行う迷惑メール対策で、ISPのメールサーバを経由せずにインターネット側（外向き：Outbound）に出ていくSMTP通信（25番ポート）を遮断します。

ISPのメールサーバを経由したSMTP通信は正常に送られますが、相手先メールサーバに直接接続するための通信は遮断されるため、迷惑メールの送信ができなくなります。

ただ、このままではISPのメールサーバを経由しないとメールを送信できないため、ISP以外のメールサーバを使ってメールを送信する場合は、サブミッションポート（587番）を使ってメールを送信します。

送信ドメイン認証

これまでは、主に送信側（中継）が行う迷惑メール対策でしたが、送信ドメイン認証は受信側で行う迷惑メール対策になります。ただ、受信側と言っても設定自体は送信側が行う必要があり、受信時の検証・認証結果に応じた対処をします。

送信元ドメインのDNSサーバにSMTPサーバのIPアドレスを登録して発信元SMTPサーバの検証を行う「SPF」と、送信時に秘密鍵でデジタル署名を付与し、DNSサーバに公開鍵を登録してSMTPサーバとデジタル署名の検証を行う「DKIM」が現在使われています。

また、SPF・DKIMの検証結果を基に送られた認証失敗時の対応策をあらかじめ決めておくDMARCも合わせて使われています。

結論

今回の場合、SPFは検証されていますがDMARCが検証失敗になっています。原因としては、メールヘッダを確認したところ、メール送信サービスを利用しているようでヘッダFROMとエンベロープFROMが一致していませんでした。

DMARCに準拠するには、ヘッダFROMとエンベロープFROMを一致させる必要があるようです。

メールヘッダーに含まれる From アドレスのドメインは、送信側メールサーバーが受信側メールサーバーに指定する MAIL FROM ドメインと合致する必要があります。ドメインの DMARC ポリシーが SPF で strict アラインメントを指定している場合、From ドメインと MAIL FROM ドメインが完全に一致する必要があります。ドメインの DMARC ポリシーが SPF で relaxed アラインメントを指定している場合、From ヘッダーに指定されたドメインのサブドメインを MAIL FROM ドメインにすることができます。

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dmarc.html#send-email-authentication-dmarc-spf

理由を知っていればとても簡単な事でしたが、やっぱり仕組みの理解は必要だと思った事例でした。

また、相手先の企業も今まではSPFだけで送信されていたメールに、新たにDMARCを加えたために迷惑メールに振り分けられたようでした。

連絡したところ社内で検討しますとの事だったので、そのうち普通に届くとは思っています。

情報セキュリティE-mail

Posted by ううら