メールサーバーのセルフホスティングは、多くの専門家が推奨しない理由があります。ある技術者が実際に挑戦したところ、設定の複雑さや外部からの信頼獲得の困難さ、そしてプロバイダによるポートブロックといった予期せぬ壁に直面し、その難しさを痛感したと報じられています。本記事では、その具体的な体験談を通じて、個人がメールサーバーを自前で運用する際の現実的な課題を深掘りします。
セルフホスティングへの再挑戦：シンプルな目的から始まったサーバー構築
筆者は過去にメールサーバーのセルフホスティングで失敗し、IPアドレスがブラックリストに載るという苦い経験がありました。それ以来、メールサーバーはセルフホスティングすべきではないと考えるようになっていたといいます。しかし、所有するドメインとインフラストラクチャを使って、自身のWebアプリケーションからアラートメールを送信する必要が生じたため、VPS（仮想プライベートサーバー）と適切なDNS設定、そしてモダンで軽量なメールサーバーを用いて、再度挑戦することを決意しました。
今回の目標は、ごくシンプルなものでした。特定のメールアドレスから送受信できること、送信メールがスパム扱いされないこと、自身のコードと統合できるメールサーバーであること、そして既存のCloudflareでホストされているドメインを利用することです。
軽量なオープンソース「Stalwart」の採用
メールサーバーとして選ばれたのは、オープンソースの「Stalwart」でした。Mailcowのような他のオープンソースソリューションが多くの計算資源（例えば6GBのSWAP）を要求するのに対し、Stalwartは軽量でありながら、TLS証明書やDKIM署名といった現代的な機能を標準でサポートしている点が決め手となりました。
基本的なインストールは比較的スムーズに進みました。Ubuntuサーバーを構築し、一般的なLinuxサーバーのセキュリティ強化策を施した後、メール関連のポートをUFWファイアウォールで開放。Dockerを利用してStalwartを起動し、CertbotとLet’s EncryptでTLS証明書を取得して手動でインポート、サーバーを再起動しました。ウェブ管理パネルから初期設定とアカウント作成を行い、一見すると完全に機能するメールサーバーが完成したように見えました。
外部との対話に必要なDNS設定と信頼の確立
Stalwartがローカルで動作するようになった後、次の課題は、インターネット上の他のメールシステムにその存在を認識させ、信頼してもらうことでした。このため、Cloudflare DNSでの詳細な設定が必要となりました。
重要なDNSレコードの数々
- MXレコード：ドメイン宛のメールをどこに送るべきかを他のメールサーバーに指示します。
- SPFレコード：どのサーバーがそのドメインからメールを送信することを許可されているかを示します。
- DKIM：Stalwartが設定時に生成したRSAおよびEd25519キーを用いて、送信メールに暗号署名することを可能にします。これにより、メールの改ざんがないことを証明します。
- DMARC：受信サーバーに対し、SPFとDKIMのチェック結果に基づいてメールをどのように扱うべきか（拒否、隔離、許可など）を指示します。
これらの設定は、特に難しいものではないものの、細心の注意と多くの確認作業を要しました。これは、他のメールシステムがメールを検査し、スコアを付け、拒否したりスパムフォルダに振り分けたりする際の「公開された身元」を構築する上で不可欠なプロセスです。
オープンリレーの回避：セキュリティの基本
筆者は過去の失敗から、オープンリレー（無関係な第三者からのメールを他の外部ドメインへ中継してしまう設定）の危険性を熟知していました。オープンリレーはスパム送信に悪用され、即座にIPアドレスがブラックリストに登録される原因となります。そのため、Gmailアドレス宛に外部の差出人からテストメールを送信し、サーバーが中継を拒否することを確認しました。この「Relay not allowed」という拒否メッセージは、サーバーが正しく設定され、スパムの温床となる可能性がないことを示す重要な証拠でした。
Thunderbirdでの設定と最終的な壁「ポート25のブロック」
サーバー側の設定が完了し、信頼性も確認された後、筆者はメールクライアント「Thunderbird」での設定に取り掛かりました。IMAP（受信）とSMTP（送信）のポートが正しく機能していることを確認し、テストメールを送信しましたが、ここで問題が発生しました。
クライアント側の設定トラブルシューティング
Thunderbirdは当初、メールサーバーを認識したものの、テストメールの送信がタイムアウトしてしまいました。Windowsからポートの開放状況を確認すると、IMAPの993番ポートとSMTPの465番ポートは開いていることが確認されました。しかし、ThunderbirdのSMTP設定には隠れた落とし穴があり、デフォルトでSTARTTLSの587番ポートが設定されているのを、TLS/SSLの465番ポートに手動で変更する必要がありました。この変更後、テストメールは無事に送信され、スパムフォルダにも入らずにGmailアカウントに届きました。
プロジェクトを阻んだ最大の壁：ISPによるポート25のブロック
送信は成功したものの、受信メールが一切届かないという新たな問題が発生しました。サーバー側ではDockerがSMTPの25番ポートを公開し、ファイアウォールも開放されており、Stalwartもローカルでは正常に応答していました。DNSレコードも問題ありません。しかし、外部から25番ポートへの接続を試みると、接続が失敗することが判明しました。
この原因は、筆者のISP（インターネットサービスプロバイダ）が25番ポートをブロックしていたことにありました。ISPに問い合わせたところ、セキュリティポリシー上の理由から、静的IPアドレスであっても25番ポートのブロックを解除できないと告げられました。これにより、メールサーバーは送信はできるものの、外部からのメールを受信できないという、致命的な状況に陥ってしまいました。
【管理人の視点】日本のユーザーにとってのメールサーバーセルフホスティング
今回の事例は、メールサーバーのセルフホスティングが単なる技術的な設定だけでなく、外部環境に大きく左右されることを明確に示しています。特に日本のユーザーにとって、この問題はより顕著かもしれません。
まず、多くの国内ISPは、スパム対策やセキュリティ上の理由から、個人ユーザーのインターネット接続における25番ポートの利用を制限しています。これは、今回の記事で筆者が直面した問題と全く同じです。仮にVPSを利用したとしても、そのVPSプロバイダが25番ポートを制限している可能性も十分に考えられます。このため、セルフホスティングを検討する際は、事前にプロバイダのポリシーを確認することが不可欠です。
また、メールサーバーの運用には、DNSSEC、DMARC、SPF、DKIMといった複雑なDNSレコード設定の知識が求められます。これらを適切に設定しないと、送信したメールが相手に届かなかったり、スパムとして扱われたりするリスクが高まります。さらに、サーバーのセキュリティ対策、バックアップ、障害対応など、専門的な知識と継続的なメンテナンスが必要です。これらは個人の時間的・金銭的コストを大きく増大させます。
信頼性やセキュリティを重視し、本業に集中したいのであれば、Google WorkspaceやMicrosoft 365、または国内のレンタルサーバーが提供するメールサービスなど、プロフェッショナルな有料サービスを利用するのが現実的な選択と言えるでしょう。これらは設定の手間が少なく、スパム対策やセキュリティも専門家によって管理されているため、安心して利用できます。セルフホスティングは、特定の技術的な挑戦や学習目的、あるいは非常にニッチな要件がある場合に限定されるべきであり、一般的な用途には推奨されません。
まとめ
メールサーバーのセルフホスティングは、技術的には可能であるものの、その道のりには多くの困難が伴います。筆者の体験談から明らかになったのは、モダンなメールサーバーソフトウェアの導入やDNS設定自体は、適切な知識があれば乗り越えられるということです。しかし、最終的にプロジェクトを頓挫させたのは、ISPによる25番ポートのブロックという、個人ではコントロールできない外部要因でした。
この事例は、メールシステムが単一のサーバーだけでなく、「信頼の連鎖」によって成り立っていることを浮き彫りにします。セルフホスティングされたメールサーバーがインターネット全体から信頼されるためには、DNS設定の正確性、セキュリティ対策、そして何よりもISPや他のメールプロバイダからの信頼が不可欠です。時間とコスト、そして技術的な課題を考慮すると、多くのユーザーにとって、プロフェッショナルなメールサービスを利用することが、より現実的かつ賢明な選択肢であると言えるでしょう。
情報元：makeuseof.com
