
IMAP対応のWebメーラーをNASで実現。複数の独自ドメインメールを一箇所で管理
はじめに
以前、Ferdiumの公式サーバーが落ちるので、NASにAPIサーバーを立てたという記事を書きました。
今回はその続編です。Ferdiumは複数のチャットツールやWebサービスを1つのアプリにまとめられる便利なツールですが、実はある弱点があります。それは「普通のメールソフトのようにIMAP/SMTPで直接メールを送受信することができない」という点です。
Ferdiumがやっているのは、あくまで「Webサービスの画面をアプリの中に埋め込む」ことだけです。GmailやOutlook.comのようにWeb版が用意されているサービスなら埋め込めますが、レンタルサーバーのメールアドレスのような「普通のIMAPメール」はそのままでは追加できません。
そこで今回は、NAS上にWebメールクライアント(ブラウザでメールが見られるソフト)を立てて、それをFerdiumに登録するという方法を試しました。同じNAS・同じドメインを使い回せるので、前回のFerdiumサーバー構築の資産がそのまま活きています。

この記事でできるようになること
普通のIMAPメールアドレスを、Ferdiumの中の1タブとしてまとめて見られるようになる
NASを使って、無料で自分専用のWebメールサーバーを持てるようになる
複数のメールドメイン(会社用・個人用など)を1つのWebメール画面にまとめられるようになる
想定環境
Synology NAS(本記事ではDS923+を使用。Container Manager〈旧Docker〉が使えるモデルなら基本的に同じ手順でOKです)
独自ドメインを1つ持っている(本記事ではexample.comを例にします)
前回の記事でSynologyのDDNS設定が済んでいること(未設定の場合は前回記事を参照してください)
IMAP/SMTPで使える既存のメールアドレス(レンタルサーバーのメールなど)
全体の流れ
使うWebメールソフトを選ぶ(今回はSnappyMailを採用)
サブドメインを決めて、DNSを設定する
Container ManagerでSnappyMailを構築する
リバースプロキシを設定する
SSL証明書を取得し、正しく割り当てる
SnappyMailの管理画面で初期設定をする
Domains設定でIMAP/SMTPの接続先を登録する
Ferdiumにカスタムサービスとして追加する
順番に見ていきましょう。
1. なぜSnappyMailなのか
「ブラウザで見られるメールソフト(Webメールクライアント)」にはいくつか選択肢がありますが、今回はSnappyMailを選びました。理由は次の2つです。
動作が軽く、レスポンシブ(画面サイズに応じて表示が調整される)なので、Ferdiumのようなアプリの中に埋め込んでも違和感がない
未読件数をブラウザのタブタイトルに表示する機能があり、Ferdium側で未読バッジとして拾いやすい
スマホでも使える
異なるドメインのメールアドレスを一局集中管理ができる
似たソフトに「Roundcube」もありますが、より機能が多い分やや重めなので、今回はシンプルさを優先しました。
2. サブドメインを決めてDNSを設定する
前回、Ferdiumサーバー用にferdium.example.comというサブドメインを作りました。同じ命名ルールに揃えて、今回は
webmail.example.comというサブドメインを使うことにしました。
「mail.」から始まる名前にしなかったのは、そのドメイン本来のメールサーバー(送受信の心臓部)に使われる名前と紛らわしくなるのを避けるためです。あくまで「Webでメールを見るための画面」という位置づけなので、webmailという名前がしっくりきます。
DNS設定(ドメイン管理画面での作業)
ドメインを管理しているサービス(エックスサーバードメインなど)のDNS設定画面で、以下のレコードを1つ追加します。
ホスト名: webmail
種別: CNAME
内容: 既存のDDNSホスト名(前回作成済みのxxxx.synology.meのようなもの)
ポイント: 新しくDDNSを作る必要はありません。1つのDDNSホスト名に対して、ferdium.example.comとwebmail.example.comのように、複数のサブドメインをCNAMEで束ねて向けることができます。
設定後、反映まで数分〜1時間ほどかかることがあります。

3. Container ManagerでSnappyMailを構築する
3-1. データ保存用フォルダを作成
File Stationで、Ferdium-serverの時と兄弟関係になるようなフォルダを作っておきます。
/volume2/docker/snappymail/data補足: 「なぜ/volume2なのか」と気になる方もいるかもしれませんが、これはNASの構成によります。もしNASにボリュームが1つしかない場合は、そもそも選択の余地なく/volume2(またはそのNASに存在する唯一のボリューム)を使うことになります。複数ボリュームがある環境では、既存のDockerコンテナ用データと同じボリュームに揃えておくと管理がしやすくなります。
3-2. プロジェクトを作成
Container Manager → プロジェクト → 作成
プロジェクト名: snappymail
パス: 先ほど作成したフォルダ
以下のdocker-compose.ymlを貼り付け
version: "3.8"
services:
snappymail:
image: djmaze/snappymail:latest
container_name: snappymail
restart: unless-stopped
ports:
- "8888:8888"
volumes:
- /volume2/docker/snappymail/data:/var/lib/snappymail/data「次へ」→「実行」でコンテナ起動

3-3. 起動確認
Container Managerの「ログ」タブで、以下のような表示が出ていれば正常に起動しています。
[INFO] Snappymail ready at http://localhost:8888/
[INFO] Snappymail Admin Panel ready at http://localhost:8888/?admin
NOTICE: ready to handle connectionsphp-fpmやnginxといった内部のプログラムが次々と「RUNNING state」になっていくログが流れていれば、エラーなく立ち上がった証拠です。
前回のFerdium-server構築で学んだ教訓(Dockerイメージが実際にデータを書き込む場所を、慣習で思い込まずに確認する、というもの)を踏まえ、今回はSnappyMailの公式イメージのドキュメントで正しいマウント先(/var/lib/snappymail/data)を事前に確認してから設定しました。おかげで今回はマウント先の思い込みミスは発生せず、スムーズに進みました。
4. リバースプロキシを設定する
「リバースプロキシ」というのは、外部からのアクセスを一旦NASの窓口(受付)で受け取り、「このアドレス宛てのアクセスは、この内部サービスに案内する」という振り分けをしてくれる仕組みです。今回のケースで言うと、「webmail.example.com宛てのアクセスが来たら、NAS内部の8888番ポートで動いているSnappyMailに案内してね」という設定になります。
設定手順
コントロールパネル → ログインポータル → 詳細 → リバースプロキシ → 作成
全般タブ
プロキシ名: webmail
Target(外部から見える側)
プロトコル: HTTPS
ホスト名: webmail.example.com
ポート: 443
送り先(内部側)
プロトコル: HTTP
ホスト名: localhost
ポート: 8888
前回作成したferdium.example.com用のエントリ(3333番ポートへの転送)と共存させる形になります。同じ443番ポートでも、アクセス先のホスト名によって自動的に振り分けてくれるので、競合の心配はいりません。


カスタムヘッダータブ
SnappyMailが「今アクセスしてきているのはHTTPS経由なのか」「本当のアクセス元IPアドレスは何か」を正しく認識できるように、以下の3つのヘッダーを追加しておきます。
X-Forwarded-Proto: $scheme
X-Real-IP: $remote_addr
X-Forwarded-For: $proxy_add_x_forwarded_for
これを設定しないと、リバースプロキシ経由でアクセスした際にSnappyMail側がHTTP接続だと誤認識し、Cookie周りの挙動がおかしくなることがあります。

5. SSL証明書を取得し、正しく割り当てる(つまずきポイント)
ワイルドカード証明書は作れない
最初、「*.example.comのようなワイルドカード証明書を1枚取っておけば、サブドメインを増やすたびに証明書を取り直さなくて済むのでは?」と考えました。
しかし、DSM標準の「コントロールパネル→証明書→追加→Let's Encryptから取得」の画面では、ワイルドカード証明書は作れません。理由は、ワイルドカード証明書の取得には「DNS-01チャレンジ」という、DNS側にAPI連携して所有権を証明する仕組みが必要なのに対し、DSM標準機能は「HTTP-01チャレンジ」というサブドメインごとの個別検証方式しかサポートしていないためです。
今回はドメインを都度追加していくペースを考え、シンプルに個別のサブドメインごとに証明書を取得する方針にしました。
証明書の取得手順
コントロールパネル → セキュリティ → 証明書 → 追加
「Let's Encryptから証明書を取得する」を選択
ドメイン名: webmail.example.com
メールアドレス: 任意(更新期限の通知用)
完了
これで証明書一覧にwebmail.example.comが新規追加されます。

「証明書は取得しただけでは自動的に正しく紐付かない」という教訓
ここが今回の一番のつまずきポイントでした。
証明書を取得した直後、「デフォルトの証明書」というチェックが付いていたので、てっきり自動的に正しいサービスに割り当てられるものと思い込んでいました。しかし実際にブラウザでhttps://webmail.example.com/にアクセスしてみると、証明書エラーが表示されました。
証明書ビューアで詳細を確認すると、提示されていた証明書の発行先(CN)はwebmail.example.comではなく、別サービス用に取得したはずのferdium.example.comの証明書でした。
原因を確認するため、コントロールパネル→セキュリティ→証明書→設定 で「構成」タブを開くと、サービスごとの証明書の割り当て一覧が表示されました。そこで初めて分かったのですが、webmail.example.comというサービス行に対して、誤ってferdium.example.comの証明書が割り当てられていたのです。
正しい手順
コントロールパネル → セキュリティ → 証明書 → 設定
「構成」タブのサービス一覧から、対象のサービス行(今回であればwebmail.example.com)を探す
その行の証明書プルダウンをクリックし、正しい証明書(同名ドメインで取得したもの)を選び直す
「OK」で保存

教訓: 「既定値としての証明書に設定します」というチェックボックスは、あくまで「どの証明書にも一致しないアクセスがあった場合の予備」を決めるものであり、個々のサービスへの割り当てを保証するものではありません。証明書を取得したら、必ずこの「構成」一覧を開いて、対象のサービス行に意図した証明書が入っているか目視で確認する習慣をつけることをおすすめします。
修正後、ブラウザで再度アクセスし、証明書ビューアの発行先(CN)がwebmail.example.comになっていることを確認して完了です。
6. SnappyMail管理画面の初期設定
管理者パスワードが分からない場合の対処法
https://webmail.example.com/?adminにアクセスし、初期パスワードとしてよく案内されているadmin/12345を試したところ、ログインできませんでした。
これは、SnappyMailの公式Dockerイメージが、初回起動時にランダムな管理者パスワードを自動生成して、コンテナ内のファイルに保存する仕様になっているためでした。実際にContainer Managerのログにも、次のような一文が流れていました。
Creating Snappymail admin password file: /var/lib/snappymail/_data_/_default_/adm...このファイルの中身を確認するため、Container Managerのターミナル機能を使いました。DSMの日本語表示では、この機能が「端末」という名前になっています。「ターミナル」を探しても見つからないので、メニューでは「端末」を目印にしてください。
Container Manager → コンテナ → snappymailを選択
「操作」→「端末を開く」
「作成」ボタンの右の矢印から「bash」を選んで起動

表示されたターミナルに以下を入力
ls -la /var/lib/snappymail/_data_/_default_/すると、admin_password.txtというファイルが見つかったので、続けて中身を確認します。
cat /var/lib/snappymail/_data_/_default_/admin_password.txt表示されたランダムな文字列を使って、無事に管理画面へログインできました。ログイン後は、画面上部に表示される「デフォルトのパスフレーズを使っています。今すぐ変更してください」という警告に従い、すぐに管理者パスワードを覚えやすいものへ変更しておきました。
7. Domains設定でIMAP/SMTPを登録する(もう1つのつまずきポイント)
管理画面の左メニューから「Domains」を選び、実際に使っているメールアドレスのIMAP/SMTP接続先を登録します。
登録する項目
ドメイン名
IMAPのサーバー名・ポート(SSL/TLSの場合は通常993)
SMTPのサーバー名・ポート(SSL/TLSの場合は通常465)
これらの情報は、レンタルサーバーの管理画面(「メールソフト設定」のようなページ)に記載されています。

ここでハマった点: ドメイン名の欄に「メールアドレス全体」を入れてしまっていた
Domainsの新規追加画面に進んだところ、登録名の欄にうっかり
taro@example.jpのように、メールアドレス全体を入力してしまっていました。IMAP/SMTPのサーバー情報は正しく入力できていたのですが、実際にこのメールアドレスでログインしようとすると、次のようなエラーが出ました。
サーバーへ接続できません
Server message: Can't connect to host "tcp://localhost:143"これは、SnappyMailがログイン時に入力されたメールアドレスの「@より後ろの部分」を見て、Domains側に登録されている名前と一致するかどうかを照合する仕組みになっているためでした。登録名がtaro@example.jpという文字列そのものだと、ログイン時のexample.jpという部分とは一致せず、結果としてどのドメイン設定にもマッチせず、デフォルトの(何も設定されていない)localhost:143へ接続しようとしてしまっていたのです。
正しい設定: Domainsの登録名には、メールアドレス全体ではなく、「@より後ろのドメイン名だけ」(例: example.jp)を入力します。
この部分を修正して保存し直したところ、無事にログインでき、実際のメールが受信箱に表示されました。
8. Ferdiumにカスタムサービスとして追加する
最後に、完成したWebメールをFerdiumに登録します。
Ferdiumで「Add New Service」を選択
SnappyMailは公式レシピの一覧には無いはずなので、「Custom Website」を選ぶ
Name: 任意の名前(例: マイWebメール)
URL: https://webmail.example.com
保存
これでFerdiumのサイドバーにアイコンが追加され、他のチャットツールと同じように未読件数のバッジも表示されるようになります。
複数のメールドメインをまとめたい場合
もし会社用・個人用など、複数のドメインのメールアドレスを持っている場合も、この仕組みは1つのWebメールサーバーで両方扱えます。
Domains設定に、もう1つ別のドメイン名(例: example.co.jp)を追加登録する
SnappyMailの通常ログイン画面(管理画面ではない方)の設定メニューから「アカウント」→「追加」で、もう1つのメールアドレスをログイン情報として追加する

こうしておけば、SnappyMailの画面内でアカウントを切り替えるだけで両方のメールを見られるようになり、Ferdium側は何も変更する必要がありません。Ferdiumが見ているのはhttps://webmail.example.comという1つのURLだけで、その裏側で複数ドメインを振り分けているのはSnappyMailの役目だからです。
まとめ: 今回の教訓
Ferdiumは「Webサービスの画面を埋め込む」ツールであり、素のIMAPメールをそのまま追加することはできない。IMAP対応のWebメールクライアント(SnappyMailなど)を自分のサーバーに立てて、そのURLをFerdiumに登録するのが解決策になる
Let's Encryptのワイルドカード証明書は、DSM標準機能だけでは取得できない(DNS-01チャレンジが必要なため)。サブドメインごとに個別取得する方が現実的
証明書は「取得しただけ」では正しいサービスに自動で紐付くとは限らない。取得後は必ず「証明書の設定」画面の構成一覧を開き、対象サービスに意図した証明書が割り当てられているか目視で確認する
Dockerコンテナの初回起動時に自動生成されるパスワードは、コンテナ内のファイルに保存されていることがある。ログの案内やターミナル機能を使って中身を確認する習慣を持つとよい
Webメールクライアントの「ドメイン」設定欄には、メールアドレス全体ではなく「@より後ろのドメイン名だけ」を入力する。ログイン時の照合はこのドメイン名の文字列一致で行われている
前回のFerdiumサーバー構築、今回のWebメール構築と、同じNAS・同じドメインの上に少しずつ「自分専用のインフラ」が育ってきました。次に何かサービスを自分のNASで動かす際も、この一連の型(サブドメイン発行→Docker構築→リバースプロキシ→証明書→動作確認)がそのまま使えそうです。