業務で使えるメール技術の教科書

「電子メールをビジネスに使うのはやめるべきだ」と日々の業務の中で言っている私ですが、実際のところは電子メールは無くなりません。皆さんも認識の通り、SlackやLINEなど、もっと使いやすく安全性が高いコミュニケーションツールは今やたくさんあります。それでも電子メールが無くならないのは、一企業に属さない汎用的なコミュニケーション手段（開発側の観点から見ると「統一されたプロトコル」）として世界中に普及していることと、そして多くのWebサービスにとってはログインID兼認証手段（メールアドレスに送信されるワンタイムパスワードや検証用URL）になっているからだと考えます。

この本の最初にもあるように、メールについての技術を学ぶ際、

Linuxなどのサーバー構築についての本→メールサーバの構築
DNSについての本→ドメインやIPアドレスの知識
セキュリティについてのほん→暗号化や認証、ウィルス、スパムなど

個別の技術が分散して紹介されます。そのため各個の知識については知っていても、それを組み合わせ、体系的にメールの送信、受信について学ぶということができていない、と感じていました。

まずはメール送信・受信の理解を深めます。「送信者→送信者のSMTPサーバー→受信者のSMTPサーバー→受信者」という流れは、最もシンプルで直接的なケースですが、現実のインターネット上では、セキュリティや管理上の理由から、複数のSMTPサーバーを介してメールが転送されることはよくあります。大きなISPは当然サーバが1つということはなく、クラスター化しています。あるいはスパム検知用のサーバが挟まっていることも考えられます。また最近はWebメールが主流なので、送信者→送信者のSMTPサーバへの通信はSMTPではなく（ThunderbirdやOutlookなどツールの場合はこの間の通信もSMTPを使用する）HTTPSを利用します。

本書はメールの技術、その根幹にあるIP層のプロトコルについても現実のモノを例示するなどして分かりやすく解説しています。一度覚えたものの忘れてしまっている用語も多いです。メールには直接関係ない話ですが、今一度DNS正引きの流れを思い出しました。

1.PCやスマートフォンが、DNSリゾルバ（キャッシュDNSサーバ）にwww.example.comのIPアドレスを問い合わせる（DNSリゾルバはフルサービスリゾルバとも呼ばれる） ↓ 2.DNSリゾルバは、まずルートDNSサーバに.comのTLD DNSサーバの場所を尋ねる ↓ 3.次に、.comのTLD DNSサーバにexample.comの権威DNSサーバ(セカンドレベルドメインDNSサーバ)の場所を尋ねる ↓ 4.最後に、example.comの権威DNSサーバにwww.example.comのIPアドレスを尋ねる。このサーバは、ドメインの情報を正式に管理しているため、最終的なIPアドレスを返す。

＜用語解説＞

ルートDNSサーバ → TLD DNSサーバの場所を教える
TLD DNSサーバ → 権威DNSサーバの場所を教える
権威DNSサーバ（セカンドレベルドメインDNSサーバ） → 最終的なIPアドレスを教える

また、サブドメイン（セカンドレベルドメイン）に対しての、DNSの委任（委譲）ついても復習しました。具体的にビジネス内で設定する作業に置き換えて解説します。

お名前.comで購入したドメインexample.comのサブドメインtest.example.comをRoute53で定義し、お名前.com側でtest.example.comのNSレコードをRoute53のNSレコードに設定することがあります。
さらに、CloudFlareのDNSでsub.test.example.comドメインを定義し、Route53にsub.test.example.comのDNSレコードを設定してsub.test.example.comのNSレコードをCloudFlareのNSサーバに設定することがあります。

これは裏では何が起こっているかというと

お名前.com から Route 53 への委任このプロセスは、example.comドメインの管理を「お名前.com」が、そのサブドメインであるtest.example.comの管理を「Route 53」に任せることを意味します。

お名前.comでの設定: test.example.comのNSレコードに、Route 53が提供するネームサーバー（ns-xxx.awsdns-xx.comなど）の情報を設定します。

これにより、インターネット上のDNSリゾルバがtest.example.comのIPアドレスを調べようとしたとき、example.comの権威DNSサーバー（お名前.com）に問い合わせると、「test.example.comの情報はRoute 53のネームサーバーに聞いてね」という返答が返ってくるようになります。

Route 53 から Cloudflare への委任このプロセスは、さらにtest.example.comドメインの管理を「Route 53」が、そのサブドメインであるsub.test.example.comの管理を「Cloudflare」に任せることを意味します。

Route 53での設定: sub.test.example.comのNSレコードに、Cloudflareが提供するネームサーバーの情報を設定します。

これにより、DNSリゾルバがsub.test.example.comのIPアドレスを調べようとしたとき、Route 53に問い合わせると、「sub.test.example.comの情報はCloudflareのネームサーバーに聞いてね」という返答が返ってきます。

全体の流れ DNSの問い合わせは、以下のように階層をたどって最終的なIPアドレスに到達します。

ユーザーのDNSリゾルバ（キャッシュDNSサーバ）がsub.test.example.comを問い合わせる。
- DNSリゾルバ（キャッシュDNSサーバ）は回線事業者（ISP）内部のモノを使うのが一般的ですが、Google Public DNS（8.8.8.8）、Cloudflare DNS（1.1.1.1）など、一般に公開されている無料のDNSサービスを参照する設定も可能です。またローカルPCやルータにも小さいキャッシュDNSサーバが存在するとのことです。キャッシュがあればそれを返します。キャッシュにない場合はルートDNSサーバに問合せします。 ↓
ルートDNSサーバーが.comのTLDネームサーバーを教える。 ↓
TLDネームサーバーがexample.comの権威DNSサーバー（お名前.com）を教える。 ↓
お名前.comが、test.example.comの管理を委任したRoute 53のネームサーバーを教える。 ↓
Route 53が、sub.test.example.comの管理を委任したCloudflareのネームサーバーを教える。 ↓
Cloudflareが、最終的なsub.test.example.comのIPアドレスを返す。

このように、複数のサービス間でドメインの管理を階層的に分割することが、DNSの委任です。これは、組織内でのドメイン管理を細分化したり、異なるサービス（AWSのEC2とCloudflareのCDNなど）を組み合わせて利用する際に一般的に行われます。

DNSによる名前解決ははインターネットのすべてのサービスに関係します。

メールに話を戻します。メールを送信する際にはSMTPサーバの設定が必要です。Gmailなどフリーのメーラーを使っている人は、GoogleのSMTPサーバの設定がGmailの設定画面で設定されているのを見たこともあるかもしれません。SMTPサーバに向けてメールを送信するにはIDとパスワードが必要で、これはGoogleのログインアカウント（つまりメールアドレス）とパスワードが設定されています。一方でメールの受信にはPOP/IMAPという別のプロトコルが利用されており、昔OutlookやThunderbirdなどのメーラーを使ってメールの受信を行っていたころは、SMTPとは別に設定画面で自分で設定していたことを思い出しました。今はgmailやyahooメールがいい感じにやってくれていますね。なのでこの辺りの細かい仕様はさらっと流しました。

ところでみなさん、メール送信用プロトコルSMTPはユーザの認証なくても利用できる、ご存じでしたか？自分はすっかり忘れていましたw SMTPは元々、信頼できるネットワーク内でのメール転送を想定して設計されました。そのため、送信者の身元確認を厳格に行う仕組みが当初は含まれていませんでした。しかし、インターネットが普及するにつれて、誰でも自由にメールを送信できるようになり、スパムや迷惑メールが深刻な問題となりました。現代のSMTPはSMTPプロトコル自体が拡張され、SMTP AUTH（SMTP Authentication）という認証機能が標準的に使われるようになりました。まだその拡張が無かったころは、メールプロバイダやISP（インターネットサービスプロバイダ）は、「POP before SMTP」や「IMAP before SMTP」など、受信は認証が必須なのを利用して、受信が成功した場合一定期間送信を許可する、という設定をユーザが見えない場所で実装していました。メーラーを使っていたころ経験則で「メールが送信できない時は一度受信ボタンを押してから再送する」などとやっていたものです。

次に実際にメールサーバ（SMTPサーバ、POSサーバ、IMAPサーバ）の構築について解説。人が動く工数を考えるとメールサービスに独自ドメインを利用可能なメールサービスを利用するほうが便利なので、現代ではメールサーバを自分で建てることは稀と思いますが、メールサービスという雲の中の中身ではこういうサーバが動いていると知っておくのは有効です。

他にもいろいろと勉強になる内容が書かれていますが、この本を手に取った最大の理由は「スパムメールを防ぐ技術」の章。そもそもメール本文のFrom句は自由に記載できます。皆さんのメーラーにも送信元がメールアドレスではなく、相手の方の名前で表示されることもあるでしょう。これは連絡帳にそのように登録されているからで、まっとうなユーザーが使うのであれば便利な機能ですが、悪用することもできます。普通にメールを送受信している時はあまり意識しないのですが、電子メールには「エンベロープ」という概念があります。「Envelope」は「封筒」の意味です。封筒（エンベロープ）には宛先（エンベロープTo）と差出人（エンベロープFrom）が書かれていて、SMTPサーバはこの情報だけを見てメールを届けます。いっぽう封筒の中身（ヘッダーと本文）にも宛名（ヘッダーTo）と差出人名（ヘッダーFrom）が書かれていて、こちらは受け取った人が読むためのものです。そしてヘッダーFromは一般のメーラーでも好きな内容で表示できることが可能で、悪い人による偽装も可能です。

”じゃあ最初からメーラーもヘッダーFromを表示すればいいじゃないか”、という話なのですが、エンベロープFromは、メールが不達になった場合に返送されるバウンスメールの送信先として使われます。これは、必ずしもユーザーが期待する「送信者」とは限りません。例えば、メーリングリストやニュースレターの場合、ヘッダーFrom:は読者にとって分かりやすい「ニュースレター名 newsletter@example.com」になる一方、エンベロープFromはバウンスメールの管理用アドレス「bounce-info@example.com」を指定したりします。もしメーラーがエンベロープFromだけを表示すると、ユーザーには「bounce-info@example.comからメールが届いた」と表示され、誰からのメールか分からず混乱します。このように、ヘッダーFromは人間が理解するための情報、エンベロープFromは機械が配送管理するための情報として、それぞれの役割が分担されています。ヘッダーFromは偽装のリスクがあるものの、ユーザーの利便性を最優先に設計されています。

メールのソースを表示すると、実際にはメールは以下のような文法で送られていることが分かります。

MAIL FROM:bounce@example.com
RCPT TO:recipient@destination.com
DATA
From: “News Service” news@example.com
Subject: News Update

MAIL FROMがエンベロープFrom、FromがヘッダーFromです。RCPT TOがエンベロープTo。ヘッダーToは省略可能で、省略した場合はエンベロープToの値が指定されます。

なりすまし対策その1、SPFによるメールサーバのドメインの認証。これにエンベロープFromを使います。 SPF自体はメールのドメインに以下のTXTレコードを1行追加するだけです。以下はGmailを使う場合の例です。

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

SPFを使うだけなら簡単です。しかしエンジニアとして正しく理解したい。これが何を意味するのか、AIと何回も壁打ちを行いました。このレコードの意味は、

1.メールが届いたとき、受信側のサーバーはSMTPセッションから直接、メールを送ってきたサーバーのIPアドレス（例：203.0.113.123）を把握する。 2.受信サーバーは、MAIL FROMコマンドで指定されたエンベロープFromのアドレス（例：test@example.com）から、ドメイン名（example.com）を特定する。 3.example.comのDNSレコードから、SPFレコードを取得する。 4.取得したSPFレコードに記載されている許可リスト（ip4やincludeで指定されたIPアドレス群※）の中に、SMTPセッションの接続元IPアドレス（203.0.113.123）が含まれているかを照合

※ include:_spf.google.com と記すことで、_spf.google.comのSPFレコードで指定されているIPアドレス群をすべて含めることができます。includeはネストされており、_spf.google.comにもinclude句が指定されています。この階層化により、Google保有の大量のIPアドレスが送信元になっていることを許可します。

加えて、~allと書くことで、それ以外のIPアドレスから送られてきたメールはSoftfailと判定します。受信側のサーバーは通常、このメールを迷惑メール（スパム）フォルダに振り分けるか、何らかの警告を付けて受信箱に置きます。一方で-allと書くと、それ以外のIPアドレスから送られてきたメールは「Fail」として扱います。これは、メールが確実に詐欺メール（なりすまし）であると宣言し、受信側のサーバーは、このメールを即座に拒否し、受信箱に届けることはありません。厳密である一方、厳しい判定となります。

送信元とされているドメインのSPFレコードに記載されているIPアドレスからメールが送られてきていることをチェックするのがSPFです。

なりすまし対策その2、DKIM。こちらは公開鍵暗号方式（ディジタル署名）の理屈を知っていれば、比較的容易に理解できま・・・せん！けっこう複雑です。

1.署名（送信側）メール送信サービスの管理者は、秘密鍵を厳重に管理しています。メール送信時、サービスは送信メールのヘッダーと本文を基にハッシュ値を計算し、そのハッシュ値を秘密鍵で暗号化して「デジタル署名」を作成します。この署名は、DKIM-Signatureというヘッダーとしてメールに付与されます。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=google; h=from:to:subjectmessage-id; bh=j9m2x+Q/4n7s6y1v8z0w3x5f2q8p7o3d9k0l4t2u6; b=abcdefg…

上記はDKIM-Signatureの例。d=example.comがメールのドメイン。s=googleの”google”が2で出てくるセレクターになります。 DKIMはhタグにリストされたヘッダーと、bhタグの値の両方を署名の対象としたうえで、これらの情報（ヘッダーと本文のハッシュ）を正規化（c=relaxed/simpleがそれに当たる）して、一つの最終的なハッシュ値を計算します。この最終的なハッシュ値を、送信サーバーの秘密鍵で暗号化し、bタグへ格納します。

hタグ (Signed Headers): 署名対象となるヘッダーフィールドを指定します。h=from:subject:dateと書かれていれば、From、Subject、Dateの各ヘッダーがハッシュ化の対象となります。
bhタグ (Body Hash): メール本文全体のハッシュ値です。

2.公開鍵の登録メールサービスの利用者は、その秘密鍵と対になる公開鍵をサービスから受け取り、自身のドメインのDNSレコードにTXTレコードとして登録します。このとき、複数の鍵を識別するためにセレクターという文字列を使用します。

例：selector._domainkey.yourdomain.com TXT "v=DKIM1; p=公開鍵の情報"

セレクターは、鍵のローテーション（定期的な更新）や複数の送信サービスを使い分ける際に、どの公開鍵を使用すべきかを指定するために重要です。これにより、受信側は適切な公開鍵をDNSから簡単に取得できます。

3.検証（受信側）メールを受信したサーバーは、メールヘッダーのDKIM-Signatureからデジタル署名とセレクターを抽出し、そのセレクターを使ってDNSから公開鍵を取得します。

4.認証受信サーバーは、取得した公開鍵でデジタル署名を復号し、元のハッシュ値を取得します。同時に、送信側と同じルールでメールのヘッダーと本文を再度ハッシュ化し、この二つのハッシュ値が一致すれば、メールは署名後に改ざんされておらず、秘密鍵を持つ正規の送信元から送られたことが証明され、DKIM認証は成功となります。

そして第3の対策、DMARC。私はこの本を読むまでは、SPFとDKIMの認証結果を基にDMARCがなりすましか否かを判定したレポートを指定したメールアドレスに送るもの、と認識していたのですがぜんぜん違っていました。SPFとDKIMは一定の効果があるものの、受信側が送信元を認証するための技術であり、第三者によって成り済ましたメールが勝手に送信されていても、送信側が検知できません。。そのため、SPFとDKIMに加え、ヘッダーのFromの情報を組み合わせて送信ドメイン認証を実現する技術がDMARCです。レポート用の設定ではなかったのか…。

DMARC認証は、以下の4つの要素を同時に調べ、最終的に単一のPassまたはFailを判断します。

SPF認証: エンベロープFromのドメイン(ルートドメイン)のSFPレコードに指定されたIPアドレスと、メールを送信したIPアドレスが一致するかを調べます。
DKIM認証: デジタル署名が有効であるかを調べます。
SPFアライメント: SPF認証がPassした場合に、エンベロープFromのドメインとヘッダーFromのドメインが一致するかを調べます。
DKIMアライメント: DKIM認証がPassした場合に、署名ドメインとヘッダーFromのドメインが一致するかを調べます。

DMARC認証は、SPFとDKIMのどちらか一方でも認証とアライメントの両方に成功すれば、最終的にPassとなります。そうでなければ、Failと判断されます。DMARCが設定されていれば、従業員が個人的なジョークで送信元を偽装しようとしても、そのメールはほぼ確実に相手に届かなくなります。そしてその処理結果をレポートとしてDMARCレコードで指定したメールアドレスに送信してくれる便利機能があります。

認証条件	説明	XMLレポートでの判定キー
SPF認証	SPFレコードに、メールの送信元IPアドレスが記載されているか。	→ → (pass または fail)
DKIM認証	DKIMのデジタル署名が有効であるか。	→ → (pass または fail)
SPFアライメント	SPF認証がPassの場合に、エンベロープFromのドメインとヘッダーFromのドメインが一致しているか。	→ → と → を比較
DKIMアライメント	DKIM認証がPassの場合に、署名に使用されたドメインとヘッダーFromのドメインが一致しているか。	→ → と → を比較

DMARCレポートで判定する方法をまとめました。そして条件が分かれば、XMLを入力に認証がpassしたかfailしたかを判定するプログラムを作成するのも容易です（ただし作成するのが自分とは言っていませんｗ）

加えて、ARC（Authenticated Received Chain）という仕組みがあります。DMARCは厳密に運用しようとするとメーリングリストの中に別のドメインのメーリングリストを入れる多段MLを運用する場合や、転送サービスを活用する場合、SPFやDKIMが壊れることで知られています。ARCは、メールが受信者に届くまでの間に中継された各サーバーにおける認証結果を保持するため、最終的な受信者が認証履歴を元にそのメールの信頼性を判断できるようになります（ただし途中の認証で失敗すると、ARCでもFAILになる点は注意）。これにより、エンドツーエンドであればDMARC FAILとなっている送信メールも、ARCがPASSすることで、DMARCレコードのp=rejectを回避することができます。

あとはメールの通信や中身の暗号化の暗号化の方法、DNSSECなどについても本書で学べました。この辺りは地震でメールサーバやDNSサーバを構築することは無いので、サービスプロバイダがしっかりやってくれている、ということを理解しました。今やメールは自前でサービスを構築せず、Amazon SESやGoogleのGmailなど、マネージドなWebメールを使うのが当たり前なのですが、裏では安全に利用できるために様々な技術が利用されていることが分かりました。短い本ですがAIとの壁打ちでなかなか疲れました。