AWSでメールサーバ環境を構築した話。
個人的にはメールサーバ構築作業はあまり行ったことがありませんでした。以前Pleskプレインストールのホスティング環境を愛用していた頃はメールサーバ環境構築済みの状態でのコンパネからの設定作業程度でしたし、例外的に一度だけPostfix＆Dovecotインストール含めて自力構築したことがありますが、この時は試行錯誤でごちゃごちゃと作業した結果、結局正解の手順はどうだったかということが曖昧のまま経験値を稼げずに終わっています。
今回、AWSを使用するということでPleskと同様にサクッとできてしまうかと思いきや、意外に右往左往しましたので（結果的にメールサーバの構築自体は簡単だったのですが）その辺のことを書いてみたいと思います。
そもそも「メールサーバ」とは？
メールサーバとは単純に言えばメールの送受信を行うサーバ機能ですが、これでは何の説明にもなっていないので、もう少し掘り下げてみます。
なお、下記はネット情報を読みかじった知識なので、不正確な点はあると思います。概要把握の意味では支障はないと思いますが、正確なところはGoogle先生に聞いてください。
メールの送受信に関連する機能は主に以下の４つに分類できるかと思います。
- MUA（Mail User Agent）
- MTA（Mail Transfer Agent）
- MDA（Mail Delivery Agent）
- MRA（Mail Retrieval Agent ）
MUAはユーザに対して直接的にメール操作のインターフェイスを提供する機能で、いわゆる「メーラ」のことです。
送信に関して言えばユーザが書いたメールを最寄りのMTAに渡します。
受信に関して言えば最寄りのMRAから自分宛のメールを取得します。
MTAは宛先までメールを転送する機能で、受け取ったメールの宛先が自分の管理下であればMDAに、違っていれば転送先に当たるMTAに渡します。
MDAは管理下のアドレス宛のメールを分類・管理する機能ですが、実質的には受信したメールを宛先（ユーザ）ごとのディレクトリ配下のファイルとして管理しておく、くらいの機能かと思います。
MRAはMUA（メーラ）からの要求に従ってMDAにより管理されているメールを取得・参照できるようにする機能です。
通信手段（プロトコル）としてPOP/IMAPを使用して当該機能を実現しています。
認証を伴うことが一般的かと思います。
上記はあくまでメールの仕組みを概念的に機能分類したもので、一般的にはMTAとMDAはセットとなっているケースが多いかと思います（と言いますか、個人的にはMDAを独立した機能と考えたことはなく、MTAの一部のように考えていましたが）。Postfixは本機能に該当します。
一方で、MRAに該当するのがDovecotです（蛇足ながらDovecotって「ドベコット」と読んでいましたが「ダヴコット」が正解らしいですね）。
上記を踏まえていただいた上で、MUA（メーラ）を除いたMTA+MDA+MRAくらいの機能をざっくりと「メールサーバ」と呼んでいると考えて良いかと思います。
SESって…
Google先生に「AWS メールサーバ」で問い合わせると、主にSES（Simple Email Service）の記事がヒットするかと思います。
名前も「Simple Email Service」と、いかにもそれっぽいです。
ただ、先に整理したメールサーバの機能に関して見ていくと、SESにはMRAの機能な含まれていないんですね。
以下、現在のAWS公式サイトの説明。
Amazon SESには、Eメールを受信するためのPOPサーバーやIMAPサーバーは含まれていません。つまり、Microsoft OutlookなどのEメールクライアントを使用してEメールを受信することはできません。Eメールクライアントを使用して送信と受信の両方が可能なソリューションが必要な場合は、Amazon WorkMailの使用を検討してください。そもそもSESは当初は送信専用のサービスだったようです。メルマガのようにメール送信に特化したサービスのための環境構築が主目的だったのではないかと推測します。
なお、WorkMailのサービスが開始されたのが2015年頃、SESでのメール受信が可能になったのも同じく2015年頃のようです。「メールサーバ」として、これら2つの機能の住み分けがどのように考えられていたのか、今一つ理解できていません…
いずれにしても、メーラを使ったメールの送受信もできるようにしたいので、Amazonさんが推奨するようにWorkMailを使用することにします。
（以下、蛇足ながら）
ネット上でSESに関する環境構築ネタを見ていると、往々にして最初に「Identity Management」で送信元（From）に当たるメールアドレスを登録しましょう的な記事が出てきます。この時、登録されたメールアドレスにはメールが送られて、そのメール上にあるリンクをクリックすることで指定したアドレスの有効性が確認されると言う手順になっているようですが、これは「メールサーバ」を構築すると言う目的から考えると奇妙な話です。
新規にドメインを取得し、そのドメインに関するメールサーバ環境を構築しようとしているのですから、つまりは当該ドメインでメールを受信できる環境はまだ存在していないことになります。そのメールサーバ環境構築に当該ドメインのメールアドレス（Fromとして使用するもの）で受信可能なものを指定する必要があるとなると明らかに矛盾があります。卵が先か鶏が先かと言ったような話です。
なお、その後の確認でSESの環境構築において必ずしもメールアドレスを指定する必要はなく、ドメイン指定でも環境構築ができそうな点は分かったのですが、どうも世の中的には未だにSESをメール送信機能として捉えているような印象です。
POP/IMAPに対応できていない点も含めて、単純に「メールサーバ」で調べた時にSES関連の記事がヒットしてしまうこと自体が不適切のようにも思われるのですが、その辺はどうなんでしょう？
WorkMailの設定
改めてWorkMailを利用するための設定を行います。
今回は事前に独自ドメインを持つWebサーバ環境が構築済みで、名前解決に関してはRoute53で設定済みとします。
このRoute53を用いて名前解決を行なっている状況からのWorkMailの設定は極めて簡単です。
まずリージョンを選択します。
残念ながら東京リージョンは未サポートで現状選択可能なリージョンは３つくらいなのですが、WorkMailでの利用に限らず海外のリージョンを選択する場合はオレゴンが良いとの噂です。地理的な条件が影響しているのか、メジャーなリージョンであるバージニア（東部）とオレゴン（西部）を比較すると、オレゴンの方が若干応答時間が短い模様。
と言うことで、オレゴンを選択しました。
次に「Organization」なるものを生成します。この「Organization」が管理上どのような意味を持つかは今一つ不明ですが、とりあえず必要らしいので作ります。
まずは「Email domain」として複数の選択肢が提示されていますが、Route53に設定済みのドメインを対象とするため「Existing Route 53 domain」を選択します。
上記結果、「Route 53 hosted zone」が指定可能になりますが、設定済みドメインが選択できるようになっていますので、対象ドメインを選択します。
最後に「Alias」なる情報を指定します。WorkMailの機能としてWebメーラが使用可能になるのですが、同メーラのURLが「XXXX.awsapps.com」（XXXXの部分がここで指定する文字列）になります。
これだけ！
上記操作により当該ドメインに関するRoute53の設定にメール関連のレコードが追加されます。
ただ、SPFとDMARCに関するレコードのみは未設定です。
WorkMailで当該Organizationを選択し、左メニューから「Domains」を選択すると設定済みのドメイン一覧が表示されますので、Organization生成時に指定したドメインを選択します。その結果表示される「Domain verification status」において「Mail setup (recommended)」の欄を見るとSPFとDMARCに関するTXTレコードの設定が「Missing」になっていると思います。ただ、ご丁寧なことにそれぞれのレコードとして設定すべきホスト名（レコード名）と値のサンプルまで表示されています。よって、このサンプルに従ってRoute53にTXTレコードを追加して、改めて当該画面を表示するとSPFとDMARCに関する状態が「Verified」になっていると思います。
ここまで親切にしてくれるのであれば、最初からSPFとDMARCに関するレコードも自動生成してくれれば良いと思うのですが…
メールユーザー登録
先の操作で対象ドメインに関するメールサーバとしての環境構築ができたとして、実際にメールを送受信するにあたっては「誰が」と言う情報が必要になります。その「誰が」を登録します。
WorkMailで当該Organizationを選択し、左メニューから「Users」を選択し、「Create user」を実行します。
「Add the details for your new user」画面では「User name」「First name」「Last name」を指定します（「Display name」は「First name」と「Last name」を指定すると、それらから自動生成されます）。
「Set up email address and password」画面では、まずは「Email address」のドメインを変更します。デフォルトでは「XXXX.awsapps.com」が指定されていますので独自ドメインに変更します（選択できるようになっているはずです）。
また、パスワードを指定します。
これでメールを送受信するユーザーが生成されました。
メール送受信テスト
上記までのわずかな設定作業でメールサーバ環境が構築できてしまいました。
最後に実際にメールの送受信を行なって見ましょう。
WorkMailにはWebメーラ機能が含まれており、当該Organizationを選択し、左メニューから「Organization settings」を選択して表示される画面の「Web Application」として表示されているURL（リンク）でメーラが呼び出せるようになっています。
同URLにアクセスするとログインを求められますが、ここで先に作成したユーザーの名前とパスワードを指定すると、同ユーザでメールの送受信が行えるWebメーラが使用可能になります。
本画面から、既存の他アドレスとの間でメールの送受信を確認します。
総括
SES関連の調査で時間を浪費しましたが（最初に書いた右往左往とはこの辺のこと）、WorkMailの設定に入ってからはサクサクと作業が進みました。
Route53でドメイン設定済みとの前提はありますが、慣れた人であれば10分かからず環境構築できてしまうのではないかと思います。
なお、メールの送受信が確認できたことで「メールサーバ」構築の主目的は達成できましたが、先にメールサーバを構成する機能として定義したもののうちMRA（WorkMailではIMAPを使用するようですが）に関しては未確認です。この点は改めて普段使用しているメーラ（Thunderbird）とWorkMailの連携を確認してみたいと思います。
また、EC2上に構築したWebシステムからメールを送信し、応答メールはWorkMail側で受けると言うような構成も考えたいですが、特に送信に関しては再度SESを担ぎ出して、EC2（Postfix？）、SES、WorkMailの三者の連携を検討する必要があるのかもしれません。
上記残件に関しては次回までの宿題ということで。
