この記事はPREVENTアドベントカレンダー1日目の記事です。
はじめに
今回はメール技術について書いていきたいと思います。実務でもメール関連の機能を扱うことがあり、メール技術の教科書という本を読んだり、それに伴って調べたりしたことについて書いていきたいと思います。
メールが届く仕組み
そもそもメールはどうやって送信者から相手に届いているのでしょうか？まずはそこから書いていきたいと思います。メールを送信する側からすると送信ボタンを押しているだけですが、その裏側では複数のサーバーがメールをリレーして、最終的に受信者に届けています。具体的には以下のような流れになっています。
-
ユーザーがメールクライアントの送信ボタンを押す
ユーザーがメールソフトでメールを作成し、送信ボタンをクリックします。このユーザーが直接操作するメールソフトなどのことをメールクライアントと言います。例えばOutlookなどです。 -
メールクライアントが自分の送信サーバーに SMTP でメールを渡す
メールクライアント自身は、メールを宛先まで届けるわけではなく、「送信サーバー」に渡す役割を担っています。メールクライアントは、送信者が契約してある「送信サーバー」の情報（ホスト名、ポート、ユーザー名、パスワードなど）を使って、サーバーへ接続します。接続には SMTPプロトコルが使われます。このとき、宛先のメールアドレスや、件名、本文、添付ファイルといった一式が送信サーバーに渡されます。 -
送信サーバーがDNSサーバーに問い合わせ、MXレコードを取得する
送信サーバーは、宛先メールアドレスのドメイン部分を見てDNSサーバーに問い合わせを行い、MXレコードを取得します。 -
相手側の受信サーバーへ SMTP でメールを転送（複数サーバーを経由することもある）
送信サーバーは、MXレコードに記載されているホスト名に対応するIPアドレスのメールサーバーに対してメールを送信します。ここでのメール送信にもSMTPプロトコルが使用されます。途中で、中継専用のメールサーバーを経由することもあります。もし相手のサーバーが一時的にダウンしていたり、混雑している場合、数分〜数時間おきに再送を試みます。 -
受信サーバーがメールボックスにメールを保存する
受信サーバーは、届いたメールの宛先を見て、対応するユーザーのメールボックスにメールを保存します。ここまででメールは受信サーバーに届いている状態です。 -
受信者がメールを取りに行く
あとは、受信者がメールソフトを開いてPOPまたはIMAPというプロトコルを使ってメールを取りに行きます。
ここまでの流れを図に表すと以下のようなイメージになります。
メールが届く仕組み
最近ではブラウザ上でメールを管理するWebメールの仕組みもよく使われています。Gmailなどがその代表です。Webメールの場合はユーザーはメールソフトをインストールせず、ブラウザ経由でHTTPSでメールアプリのWebサーバーにアクセスします。そしてメールアプリのWebサーバーがSMTPでメールサーバーにメール送信を行い、IMAPで受信側のメールアプリがメールを受信します。Webメールの場合、メールはメールアプリのWebサーバーで管理するので、IMAPで複数の端末からメールソフト経由でメールを確認できるのと同じように、複数の端末からブラウザ経由でメールを確認することができます。Webメールの仕組みを図に表すと以下のようになります。
Webメールの仕組み
POPとIMAPの違い
メールの受信にはPOPもしくはIMAPと言うプロトコルが使用されます。POPとIMAPの大きな違いは受信したメールを管理する場所が違うことです。
POPは利用者がメールをパソコンなどで受信する操作を行うと、メールサーバー上からメールを削除し、利用者側のパソコンなどで管理します。IMAPは利用者がメールを受信する操作を行ってもメールサーバー上にメールは残ったままになります。
そのためPOPとIMAPでは以下のような違いが出てきます。
-
POP
サーバーからメールをダウンロードして手元に保存するので、一度受信してしまえばネットワークにアクセスしなくてもメールの内容を確認できる。ただし、特定の端末でしかメールの内容は確認できなくなる。 -
IMAP
サーバー上のメールボックスにメールを保存するので、メールを確認するためには毎回インターネットへのアクセスが必要。インターネットに接続できる環境であれば複数の端末からメールの内容を確認できる。
近年ではサーバーの容量が多くなったことや、1人で複数の端末（スマホやパソコン）を管理することが当たり前になってきたためIMAPを使うことが一般的になってきています。これもGmailをイメージするとわかりやすいと思います。
メールが届かないときにどんなことが起きているか
メールでよくあるのが送ったはずのメールが相手に届かないというトラブルです。
この場合、以下のような問題が発生している可能性があります。
-
DNSで送り先のサーバーが解決できない
先ほども書いたように、送信サーバーは、宛先メールアドレスのドメイン部分を見てDNSサーバーに問い合わせを行い、MXレコードを取得します。ところが DNS に問い合わせても、「ドメインが見つからない」「そのドメインにMXレコードがない」「DNSサーバーが応答しない、タイムアウトする」といった状態になると、送信側サーバーは送り先サーバーを特定できず、送信を開始できません。その結果、送信元には「ホストが見つからない」「ドメイン名を解決できない」といった内容のバウンスメール（配信エラー通知)が戻ってきます。
この事象の主な原因は以下のようなものが挙げられます
- 宛先メールアドレスのドメインが間違っている
- ドメイン側のDNS設定ミス
- MXレコードを登録していない
- DNSの障害や、相手のドメインが何らかの理由で失効している
など。
-
メールボックスの容量超過で受け付けてくれない
受信側のメールサーバーには、容量上限が存在します。この容量を超えてしまうと、新しいメールを保存する余地がなくなるため、新しいメールの受信が拒否されてしまいます。この場合も、送信者の元には「受信者の受信トレイに空き容量がありません。」という内容のバウンスメールが返ってきます。 -
受信メールサーバー側のセキュリティ設定で拒否された
最近のメールサーバーは、スパムやウイルス、なりすましメールを防ぐためにかなり厳しめのセキュリティ設定が行われています。その結果、特定の条件をもとに危険な可能性があると判断されたメールは、受信段階でそもそも拒否されることがあります。
例えば、
- 送信元IPアドレスの評価（レピュテーション）が低い
- 送信元ドメインがブラックリストに登録されている
- 添付ファイルにマルウェアが含まれていると判断された
- 受信側で禁止されている添付ファイルが添付されている（.exe やマクロ付きOfficeファイルなど）
といった条件に当てはまると、受信サーバーがSMTPレベルでエラーコードを返し、メール自体を受け取らない場合があります。このケースでも、多くは「メールの送信が拒否されました」といった内容のバウンスメールが返ってきます。
-
スパム判定されて迷惑メールフォルダに入っている（※相手にメールが届いていないわけではないです）
メールは受信サーバーまで届いているが、受信トレイではなく迷惑メールフォルダに振り分けられているパターンです。迷惑メールを送信する業者は多く存在するので、多くのメールソフトでは受信したメールの中身を見て、自動的にスパムメールかどうかを振り分ける機能を備えています。
メールソフトは次のような情報を総合的に見てスパム判定を行います。
- SPF/DKIM/DMARCの設定・検証結果
- メールの内容に不審なものが含まれている
- 例：本文に不審なURLが含まれている、大量の画像だけでテキストが少ない、など
- 迷惑メール業者が頻繁に使う言葉や単語（例えば無料、緊急など）が多く含まれている
- 受信者側の行動履歴（受信者が過去にその送信元のメールをスパム報告しているなど）
- 新規のIPアドレスで配信履歴が無いのにいきなり大量のメールを送信している
特に件名や本文に含まれる文言からスパムメールかどうかを検出するために行われる代表的な処理は統計的な処理であり、その中でもベイジアンフィルタと言う手法がよく使われます。ベイジアンフィルタはメールに含まれる単語などの特徴を使ってスパムメールを判定するアルゴリズムです。ベイジアンフィルタについての解説は以下のような情報がネットに色々上がっているので、興味があれば調べてみてください。
メールが届かない原因はSMTPのエラー内容を見れば簡単に特定できることも多いです。以下のようなサイトが参考になるでしょう。
メールの構造
次にメールの構造について解説していきます。メールの中身の構造は郵便で言う封筒と、封筒の中身の手紙をイメージするとわかりやすいと思います。
メールは以下の要素から成り立っています。
エンベロープ
郵便でいう封筒の表書きにあたる部分です。SMTPではメールの本文部分に書かれている送信者や受信者のメールアドレスではなく、エンベロープに書かれている情報を使ってメールを送信します。そのため、エンベロープに書かれたFrom、Toとメール本文のFrom、Toは異なることもあります。例えばTo、Cc、Bccでそれぞれアドレスを指定した場合、エンベロープのToに1人ずつのアドレスを指定してメールが送信され、メールの本文にはToとCcの内容が書かれている、という形になります。
メールヘッダー
封筒の中身の手紙に書かれた、「差出人」「宛先」「件名」「日付」などの情報です。実際にメールクライアントが表示している「From: 〜」「To: 〜」「Subject: 〜」はここに書かれています。それ以外にもメールのIDや経由したサーバーの情報など、ユーザーが指定した内容以外の情報も多く書かれています。ヘッダーの原文の内容は多くのメールソフトで確認できるようになっているので、興味のある方は確認してみてください。
ボディ
手紙の本文そのものにあたる部分です。プレーンテキスト、HTMLメール、画像やPDFなどの添付ファイルもここに含まれます。MIMEというメールの形式を拡張する機能を使って、「本文」「HTML版」「添付ファイル」などを1通のメールとしてまとめています。複数のデータを1つのメールで送信するために、メールを「パート」と呼ばれる構造に分解して作成する方法が取られており、これをMIMEマルチパートと言います。
スパムメールと判定されることを防ぐためにできること
続いてスパムメールと判定されることを防ぐためにできることについて書いていきます。メール送信機能を実装していると避けては通れないのがこの問題です。上にも少し書きましたが、ここでより深掘った内容について書いていきます。
スパムフィルタは何を見ているのか
各プロバイダのフィルタの実装は非公開ですが、次のような要素を総合的にチェックしていると言われています。
-
差出人ドメインと送信元IPアドレスの評価（レピュテーション）
- IPレピュテーションとは、IPアドレスの信頼性を評価する仕組みのことです。このスコアが低いとそのIPアドレスから送信されるメールがスパムメールと判定される可能性が高くなります。
-
SPF/DKIM/DMARCの検証結果
- 送信ドメイン認証を行うのがSPF・DKIM・DMARC です。詳細は後述します。
-
コンテンツ（本文・件名）の内容
- スパムメールによく含まれている文言が含まれていないか、画像だけで本文がほとんど無い、短縮URLだらけなど、メールとして不自然な内容ではないかなどがチェックされます。
-
ユーザーの操作履歴
- その送信元から来たメールを過去に迷惑メールとして扱っていないか、過去のメールの開封率・クリック率が極端に低い、すぐ削除されているなど、ユーザーの操作履歴を確認します。
-
ブラックリストとの照合
- スパムメールを送信していると思われるメールサーバーのIPアドレスをリスト化し、そのIPアドレスからのメールの受信を拒否することができます。このリストのことをブラックリストと言います。このリストに送信元のIPアドレスが含まれていないかをチェックします。
このうち、SPF/DKIM/DMARC は送信者側で必ず整備すべき部分なので、まずここを固めることから始めるべきです。
SPF
SPFはSenderPolicyFrameworkの略で、メールが正規のメールサーバーから送られたものであるか（なりすましではないか）を確認するための「送信ドメイン認証」のための技術です。送信者側が設定することによって、メールのエンベロープFromのドメインと送信元のメールサーバーのIPアドレスが一致しているかを受信側のメールサーバーが確認できるようになります。SPFは送信側が管理するDNSサーバーに次のような項目を設定することで実現できます。
example.com. IN TXT "v=spf1 ip4:XXX.X.XXX.XX -all"
この例では、example.comと言うドメインが使用するSMTPサーバーのIPアドレスがXXX.X.XXX.XXだけであることを示しています。それ以外のサーバーから example.com のドメインで送信されたメールは不審なメールであると判断されます。
受信サーバーは、送信元IPとエンベロープFromのドメインを見てSPFを照会し、その結果をReceived-SPF: trueのようにヘッダーに追加します。
DKIM
DKIMはDomainKeysIdentifiedMailの略で、メール本文やヘッダーが途中で改ざんされていないことを電子署名で証明する仕組みです。電子署名の作成には公開鍵暗号方式を使用します。
流れは以下です。
- 送信側サーバーは、メールを送るときに、特定のヘッダー・本文に対して秘密鍵で署名する。
- その署名結果を
DKIM-Signatureヘッダーに埋め込んで、一緒に送信する。 - 受信側サーバーは、DNSに公開されている公開鍵（TXTレコード）を取得し、署名を検証する。
DNSには次のようなレコードを登録します
s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
-
s1は「どの鍵を使うか」を区別するためのセレクター名です。このセレクター名はドメインに対してユニークである必要があります。 -
p=には公開鍵をbase64で符号化したものが入ります。
検証に成功すると、受信サーバーはこのメールはexample.comのサーバーが送ったと考えられ、途中で改ざんもされていないと判断できます。
DMARC
SPFやDKIMは受信側のメールサーバーが送信元を認証するもので、第三者によってなりすましたメールが勝手に送信されていても送信側が検知することはできません。そこで、SPFとDKIMの情報と、ヘッダーのFrom情報を組み合わせて送信ドメイン認証を実現する技術がDMARCです。DMARCはDomain-based Message Authentication, Reporting and Conformanceの略で、SPFやDKIMの結果を踏まえてメールをどう処理するかを指定することができます。また、メールの処理結果のレポートを受信側から送信側に送付することも可能なため、スパムメールが送付されていることに気付ける可能性があります。具体的には以下のような設定を行うことができます。
- SPFかDKIMのどちらか（または両方）が成功していて、なおかつFrom ヘッダーのドメインと整合している場合だけ正当なメールとみなしてほしい
- 条件を満たさないメールは、迷惑メール行きにしてほしい／完全に拒否してほしい
- どんな結果になったかレポートを送ってほしい
これをDNSのTXTレコードで宣言します。
例：
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com;"
p=の部分で適用ポリシーを設定しています。ポリシーには以下の3種類があります。
| ポリシー | 内容 |
|---|---|
| none | 認証に失敗しても特に処理を変えず、メールは通常通り受信者に配信される。 |
| quarantine | 認証に失敗したメールを迷惑メールフォルダに振り分けるように、受信側サーバーに指示する。 |
| reject | 認証に失敗した場合受信者に配信しない。 |
rua=の部分でレポートを送信するメールの宛先を指定できます。
DMARC が見ているポイントは大きく2つです。
- SPFとDKIMの結果（認証に成功しているかどうか）
- それらの認証されたドメインと、実際のFromヘッダーのドメインが一致しているか
これにより、「SPF自体はpassしているが、実際のFromドメインとは別ドメインから送っている」というような、なりすましパターンを検出しやすくなります。
DMARCの設定を行う場合、以下のような点に注意する必要があります。
- DMARC は SPF/DKIM の上に乗る仕組みなので、SPFとDKIMが適切に設定されていることが前提になります。
- いきなり
p=rejectにすると、正当なメールまで弾いてしまうリスクがあります。そのため通常はnone→quarantine→rejectと段階的に厳しくしていくべきです。 -
ruaでレポートを受け取り、どの送信経路がDMARCに失敗しているかを分析すると、設定漏れなどを洗い出しやすくなります。
SPF、DKIM、DMARC はスパムメールと判定されないために必ず設定しておくべき項目です。この設定ができていないと最近のメールクライアントではスパムメール判定されるケースがほとんどです。2023年10月に公開されたGoogleのメール送信者のガイドラインにも明記されています。
この設定は必ず行ってスパムメールと判定される可能性を下げるようにしましょう。
最後に
今回はメール技術について書いてみました。普段からユーザーとしても使っているものの裏側がどうなっているか深掘るのはなかなか楽しかったです。参考にした以下の本もとても面白かったので気になる方は読んでみてください。
最後までご覧いただきありがとうございました。
Discussion