世界を動かす技術を、日本語で。

1984年のようにセルフホスティングのメールを運用する

概要

  • メールサーバーのセルフホスティング の魅力と注意点を解説
  • PostfixとOpenDKIM による基本構成と設定例を紹介
  • TLS証明書やDNSレコード のポイントを整理
  • 実際のメール送受信例 とトラブル対処法を説明
  • 次回はPythonによるメール自動化 を予告

メールサーバーのセルフホスティング入門

  • セルフホスティングの用途 :メーリングリスト、ニュースレター、メール認証APIの自動化
  • 最大の課題 :メールの受信・配信の信頼性低下リスク
  • 個人プロジェクト向き :配信失敗を許容できる場合に限る
  • コスト面の利点 :既存サーバーに追加パッケージ導入のみで、ほぼ無料運用
  • リソース消費 :ストレージや電力消費は最小限
  • 難易度の誤解 :実際はSaaSメール設定と大差ない手間
  • マルチユーザーWebメールは未導入 :アカウント管理やDB不要の簡易構成
  • メール送受信方法 :SSH経由でmailxやMuttなどCLIツール利用
  • 今後の拡張性 :必要に応じてWebメール導入や自作も検討

PostfixによるSMTPサーバー構築

  • 必要なパッケージ :Postfix(SMTPサーバー)、OpenDKIM(認証強化)
  • ポート開放 :25番ポートを開ける
  • Postfix設定ファイル例 :main.cfの主な項目
    • compatibility_levelmyhostnamemyoriginmydestination
    • TLS設定 :証明書パス指定、暗号化プロトコル制限
    • DKIM連携 :smtpd_milters指定でOpenDKIMを利用
  • master.cf :デフォルト設定のまま運用
  • POP3/IMAP未導入 :Dovecot設定の難しさから省略、SSH+mailxで十分な運用

TLS証明書の運用ポイント

  • TLS導入理由 :メール通信の暗号化
  • 証明書の取得 :Let's EncryptなどでMXホスト名向け証明書を1枚取得
  • 証明書更新の手間 :自動化ツールは複雑化要因、legoパッケージの手動DNSチャレンジを利用
  • メールドメインごとの証明書不要 :SMTP通信の暗号化はMX名のみで十分
  • Fromヘッダーの自由度 :TLSは経路暗号化のみ、送信元認証は別途DKIM等が必要

DKIM・SPF・DMARCの設定

  • 認証技術の重要性 :Gmail等での迷惑メール判定回避
  • OpenDKIMの導入 :各ドメインごとに鍵ペア生成し、DNSに公開鍵登録
  • 鍵のローテーション :推奨されるが必須ではない
  • 必要なDNSレコード
    • SPF :送信許可サーバー定義
    • DKIM :公開鍵登録
    • DMARC :認証失敗時の処理指示
  • OpenDKIM設定ファイル例 :UserID、Socket、KeyTable、SigningTable、TrustedHostsなど
  • DKIM鍵生成コマンド :opendkim-genkeyの利用例
  • DNSレコード例
    • MX :example.com → mx.idx.cy
    • SPF :v=spf1 mx a -all
    • DKIM :v=DKIM1; k=rsa; p=(公開鍵)
    • DMARC :v=DMARC1; p=reject; rua=mailto:postmaster@idx.cy

逆引きDNS(PTR)と配信到達率

  • 逆引きDNSの効果 :サーバー信頼性向上、ISPによる設定が必要
  • 未設定でも配信成功例 :Gmail/GMX/Outlookで迷惑メール扱いされず
  • 到達率重視の場合 :PTRレコードは実質必須

Gmailへのテスト送信と受信

  • sendmailコマンド例 :テストメール送信方法
  • Gmail側の確認 :SPF/DKIM/DMARCすべて合格、TLS通信も確認
  • mailxでの受信例 :Heirloom Mailの利用とコマンド例
  • トラブル時の対処
    • DNSレコード再確認
    • TLS証明書・DKIM鍵の権限確認
    • Postfix/OpenDKIMログの活用
    • OpenDKIM設定のスペルミス注意

今後の展望

  • 次回予告 :Pythonを用いたメールアプリケーション開発
  • 質問・感想受付 :max@idx.cyまでメール連絡歓迎

Hackerたちの意見

自分でメールをホスティングしたい人へのアドバイスだよ。まずは、その自分のメールアドレスを使ってアカウント登録をしてみて。プライベートなやり取りには使わなくても大丈夫。Mail-in-a-boxを使えば、すぐに始められるよ。指示に従えば、数時間で設定できるし、あとはそのまま動くはず。数年後には、プライベートなやり取りも新しいメールに切り替えられるかもね。[1] https://mailinabox.email./

MIABを数年使ってるけど、一般的には良い感じで、レンタルのクラウドマシンと「クリーン」なIPを使って送信者として運用してるよ。Outlookのユーザーにメールが届かない時があって、その時はMicrosoftのポストマスターに連絡したこともあるけど、意外と親切に対応してくれて、それ以降は順調に動いてる。DKIM/SPF/DMARCの設定を学ぶにはいい練習になるよ。ただ、Mailinaboxでのアカウント登録メールの受信は本当に面倒くさい!グレイリスティングのスパム対策機能は、未知の送信者を弾いて再試行を待つんだけど、正当なサイトの多くは再試行をしないんだよね。だから新しいアカウントのメール確認や2FA関連のメールが届くのに時間がかかることが多い。MIABはスパムフィルタリングを一時的に無効にする簡単な方法がないから、ほんとにイライラする時がある。

Stalwartをおすすめするよ。[1] これは外部依存がほとんどない、単一のバイナリに含まれた完全なメールサービスで、インストールやアップデートがすごく簡単なんだ。過去にいくつかのプロジェクトを見たり試したりしたけど、Stalwartが一番設定が簡単で、今のところ問題もないよ。[1] https://github.com/stalwartlabs/stalwart

現代のメールプロバイダー、特にISPが提供するものは、自己ホスティングのプロバイダーが批判されるのと同じ問題を抱えてることが多いんだよね。Googleだって問題があるし。例えば、私はよくShopifyを使っている会社から注文するんだけど、ShopifyからのメールがGmailのスパムに直行しちゃうんだよね。スパムじゃないって何度もマークしてるのに。(これらはdmarc/spf/dkimを通過してるから、何が起こってるのか分からない。) メールの配信や受信は難しくないけど、どのプロバイダーを使っても完璧にはならないのが現実。悪質な業者が多すぎて、今の状態で機能してるのが逆に驚きだよ。

その行動が問題の根本だよ。自己ホスティングや小規模なメールプロバイダーを使うと、攻撃的な非Gmailフィルターによってメールがブロックされたりフィルタリングされる可能性がかなり低くなる。面白いことに、Gmailアドレスからは大量のスパムが送られてくるから、プロバイダーでフィルタリングしてもあまり意味がないんだよね。でもGoogleはそれを続けるって言ってる。

これらはdmarc/spf/dkimを通過してるから、何が起こってるのか分からない。スパムとは関係ないよね?スパムは内容に関するもので、これらは信頼性に関するものだから。誰でも本物のゴミや、認証されていない金を送れるからね。

不思議なことに、最近のGmailのスパムアルゴリズムは、企業からのマーケティングメールに対して過剰に敏感になってる気がする。こんなことで文句を言うとは思わなかったけど、実際にメールが欲しい時にそれが来ないのは超イライラするよね。10年前くらいは逆の問題があった気がするけど、今はちょっと行き過ぎてる感じ。最近受け取るスパムのほとんどは、個人のメールアドレスからの少量のコールドメールなんだよね…企業からの大量送信じゃなくて。新しいGmailの配信停止機能はマーケティングメールには効果的だけど、コールドメールのスパムには全く役に立たない。なぜかそれはスパムに入ることがほとんどないんだよね。

自分のメールを約20年間自己ホスティングしてるけど、10年か15年くらいは全部Gmailに転送してた。でも、重要なメールがスパムに振り分けられちゃうから、ローカルに戻さざるを得なかった。最初はemacsでローカルメールを使ってたけど、空港での航空券の問題を解決するためにimapdに切り替えたんだ。会話の途中で、相手からの返信が消えちゃうことがあったからね。自己ホスティングの方がずっといいよ。SPFなどを設定するのに何度か試行錯誤が必要だったけど。

「例えば、私は定期的にShopifyを使って注文してるんだけど、今はそのShopifyのメールがGmailのスパムに直行してるんだ。スパムじゃないって常にマークしてるのに。」これ、Shopifyがユーザーがスパムとしてマークするメールをたくさん送ってるか、そういう誰かと同じメールサーバーを使ってるからだと思う。スパムじゃないってマークしても、送信者の評判が悪すぎて、スパムフォルダから出られないんだよね。

(フラグが付いた親コメントの下から自分のコメントを掘り起こさなきゃいけなかった) 自分でホスティングして20年以上経つけど、諦めるつもりは全然ないよ。セルフホスティングは誇りの証だからね。政府も首相も内務省も外務省も、自分たちのメールをホストできてないのが現実。最後に確認したときは、州のセキュリティだけがセルフホスティングしてた。運が良かったのか、配信の問題はほとんどなかったよ。最後に問題があったのは数年前で、Microsoftがメールを飲み込んじゃったやつで、古いeximと*.protection.outlook.comでのTLS証明書の検証の組み合わせが原因だった。どこかのSOで見つけた設定オプションで解決したけどね。正直、メンテナンスはほとんど必要ないし、メンテ作業があるときは新しいことを学ぶチャンスだと思ってる。今年は、古くなったDebian jessieのセットアップをArch Linuxに替えることにしたし、cronジョブをすべてsystemdタイマーに書き換えた。重要なメールを送るときは、エラーログを確認するけど、たまにログを手動でチェックするのはいいことだと思ってる。最後に一つアドバイス:セルフホスティングは趣味みたいに楽しんでやるべきだよ。それと、Debian用のExim設定をデザインした人は、無駄にした時間の分、地獄に特別な場所を与えられるべきだね。DebianでEximを設定するなら、上流のexim設定を使って自分のニーズに合わせて調整する方法を見つけてね。

「古くなったDebian jessieのセットアップをArch Linuxに替えることにしたし、cronジョブをすべてsystemdタイマーに書き換えた。」ああ、20年前の自分の1%のモチベーションがあれば、こんなことできたのにな。フルタイムの仕事、妻、子供がいる前はね。

私の最初のメールの使い方は大学時代、WWWが始まる前だった。その後、ISPのメールサービスを少し使ったけど、その頃はストレージが非常に限られていてPOP専用アカウントだったから、常時接続のインターネットがなくてもメールを受信するためにリレーとダイナミックDNSを使って自分でホスティングを始めた。今は小さなVPSを使ってメールをルーティングして受信してるけど、最終的な保存先は自宅のサーバーだ。これまでの数年、他の人と同じように、Outlookや他のプロバイダーにIPやドメインのブロック解除を頼むこともあったけど、それは稀だった。世界中のメールをたった2、3社だけが運営する世界には住みたくないから、これが私の小さな抵抗の行動なんだ。

dmarcレポートを設定してみて。これがあれば、誰があなたのメールを飲み込んだのか、理由を自動的に教えてくれるよ。

セルフホスティングを趣味のように扱って楽しむことが大事だよ。これが私が多くのセルフホスティングから離れた理由だね。時間や注意を他のことに向けてしまった。でも、どうやら時間とお金のバランスが少し変わってきたみたいだから、戻る価値があるかも。特にメールのセルフホスティングに対する最大のためらいはスパムの処理なんだ。最近の状況はどうなってるの?何かアドバイスある?

私は約25年間セルフホスティングをしています。protection.outlook.comの問題を覚えています。ある銀行が暗号化を試みたとき、期限切れの証明書を使っていたことがありました。でも、問題を伝えたら、支払いをしている顧客にとっての問題だと分かって、実際に修正してくれました。サーバーログを確認できるのはとても便利です。例えば、誰かに「そのメールはあなたのドメイン名を使ったサーバーに配信されたよ」と、その時のIPアドレスと一緒に伝えられます。

私にとってメールは重要なサービスで、約15年間セルフホスティングをやめた理由は次の通りです。1. 定期的な監視で一貫したバックアップと復元を保証できなかったこと、2. 災害復旧計画がなく、他のメールプロバイダーを利用する方が高くつくこと、3. セキュリティを常に把握していなかったこと(一緒にコロケーションしていた友人もメールサーバーを運営していて、彼のシステムはランサムウェアに襲われたが、バックアップはなく、DRもなかった;私はFreeBSDを使っていたので、比較的無傷で済みました)。メンテナンスは少ないとはいえ、一度ハッピーパスから外れると、大変なことになりかねません。

以前はこれをやってた。最終的にやめた理由は評判じゃなくて、100%の稼働時間が必要だったから。そうしないとメッセージを失ったり、アドレスがブラックリストに載ったりするリスクがあったから。メールはダウンタイムに強いはずだけど(リトライとか、各MXレコードを試すとか)、大手のメールプロバイダーはバウンスしてそのまま放置することが多い。さらに悪いことに、GitHub(2016年と2018年)では、一度バウンスしただけで受信者を「利用不可」として、そのアドレスへの通知を送らなくなった。最近は状況が改善されて、サポートもかなり助けになったけど、現代のSMTP送信者は受信者が「常にオンライン」であることを期待してるのが明らかだね。これはプロトコルが発明されたときにはなかったことだ。

「100%の稼働時間が必要だったから、メッセージを失うリスクがあった。」Q: サーバーが数時間オフラインになったら、どうして「メッセージを失う」ことになるの?自分のメールサーバーを確認したら「219日稼働中」だよ。正直、私たちが普段やってることに比べたら、これはそんなに難しくないよね。

これは恐怖を煽るだけだね。私のメールはいつも数時間後か1日後に再送されてた。問題が自分の側にあるのか、送信者の側にあるのか、どこか中間にあるのか、メールが一度配信されなかった理由を知るのは絶対に不可能だし、標準のサーバー設定がそれを単に捨てることはないよ。自分のメールをホストしてみて。私はdkimとspfを正しく設定してるから、99%の配信率を得てるよ。「複雑さ」に惑わされないで。正しく設定すれば、全然できるから。ちなみに、プライベートなcaldavも手に入るよ。

私のサーバーには「グレイリスティング」という機能があって、ドメインから最初に受け取ったメールを意図的に拒否します。これまで、誰も「メールが届いていない」と主張したことはありません。かなりの量のメールを受け取っているのにね。再試行は仕様に組み込まれていて、本当に心配なら、優先度を下げた別の「受信」SMTPサーバーをインターネットに置いて、LMTPでバックホールさせることもできます。——— メールは、ホスト同士が常に接続されていなかった時代に設計されました。

わかるよね。「彼らは俺の息子に何をしたんだ?」って、弾だらけの息子の遺体を見つめるような感じ。

セルフホスティング: 現在、メール送信のためのセルフホスト型代替サービス「Hyvor Relay」のベータテストを行っています。私たちは、観察性(DKIM/SPFの監視、DNSBLの定期的なクエリ)やDNSの自動化にもっと焦点を当てています。シンプルなdocker compose upで、そこそこ動く環境が整います。

現在のセルフホスティングについて、Debian Trixieを使ったドイツ語の解説があります。https://krei.se/Doc 自分でやって、正しくやれば楽しいですよ。自動更新と自動再起動があって、systemdを調整してすべてがうまくいくようにして、メールでステータス報告も受け取れます。完全に幸せで、簡単に2~3年、Trixieを使えば5年は触らなくても大丈夫です。成熟したソフトウェアです。自分でホストしましょう!心の平穏とコントロールは本当に価値があります。

完全なセットアップを探している人には、IMAPサーバーを含むこちらのガイドがいいと思います。普通のメールクライアント(Thunderbirdなど)でも使えます。https://workaround.org/ispmail-bookworm/ 私もこのガイドに従って自分のサーバーを設定しましたが、データベースは使わずにプレーンテキストファイルにしました。自分だけのユーザーなのでシンプルにしたかったんですけど、上のガイドは大規模な企業のセットアップにも対応できるはずです。

私もこのガイドを使っていますが、PostgreSQLに切り替えました。最近のTrixieへのアップグレードで新しいDovecotが導入され、設定に破壊的な変更がありました。それを解決するのはちょっと面倒でしたが、今はすべてうまく動いています。

自分でホスティングしてるのは、もう10年か15年くらいかな。安いKimsufiボックスに、OpenSMTP、Dovecot、あとからRSPAMDを使って、特に問題はなかったよ。ある時、telekom.deが俺のメールサーバーをブロックしたことがあって、postmaster@telekom.de(だったかな)に連絡して、Kimsufiボックスが怪しいことで有名だけど、これはちゃんとしたメールサーバーだって説明したら、すぐにホワイトリストに入れてくれたんだ(あれは驚いたな、スムーズに行ったから)。だから、みんなが言ってるようなトラブルは確認できないな。ただ、Kimsufiボックス(とそのIP)を長いこと持ってるから、単に運がいいだけかもね。

もう10年以上、自分のメールをホスティングしてるよ(昔のメールに関するHNスレッドのコメントをいくつかリンクするつもり)。最近は、Digital OceanのIPブロックが突然悪いとマークされちゃったから、AmazonのSESを使って送信することに戻ったんだ。新しいIPの評判を改善するほどのボリュームもないしね。Gmailを無料のスパム収集ツールとして使って、自分のスパムフィルターをトレーニングしてるよ。でも、ここで他の人が言ってるように、グレイリスティングはこの分野ではめっちゃ役立つ。正当なサーバーは必ず再試行するからね。唯一の例外は電力会社で、彼らは紙の請求書を送ることになるけど、Gmailでもそれに引っかかることがある。これが、最大1週間のダウンタイムを心配しない理由の一つでもある。受信サーバーとストレージサーバーの2つのメールサーバーを持ってて、受信サーバーは簡単に再デプロイできるから、必要なら数分で対応できるよ。グレイリスティングについては、https://github.com/stevejenkins/postwhite(古いけど、まだ重要だと思う)を使うのが、面倒な2FAメールに対してすごく役立った。メールはこの用途には向いてないって強く主張するけど、これはまた別の話だね。

長々とした言い訳だけど、Googleのメールサービスにお金を払うのもアリだよね。

最近、Amazon SESからの受信メッセージ(幸い重要じゃないやつ)を見逃しちゃったんだ。54.240.27.30のアドレスがbl.spamcop.netにリストされてたから。Amazonはグレイリスティングに引っかかりながら、いろんなアドレスを試してたんだけど、そのアドレスを試したときに拒否されたみたい。大手プロバイダー間で送信する場合は、あまり問題にならないかもしれないけど(例えば、AmazonからGmailへ)、メッセージ配信を確実にするための完璧な解決策ではないみたいだね。

無料のリソースを使いながら、少なくとも管理権は維持してるよ。昔、完全に自己ホスティングするルートを考えたけど、それには関わりたくなかった。今は、真逆の友達と関わってるんだけど、彼は精神的に厳しくなって、デバイスも失くしちゃった。前の管理者に支払いもしてないし、デジタルロックアウト状態だよ。これから回復するのは悪夢だし、盲目的に操作してる。普通の人には無理だろうね。