自前でルーティング可能なIPv4ブロックから始める、あえて大変なメール自前ホスティング

• 1997年から運用されてきたRecoilメールインフラは、専用IPv4 /24 ブロック、Postfix、Dovecot、rspamd、Roundcubeなどを組み合わせ、受信・送信・アクセスを自前で処理するセルフホスト構成へ更新された
• メールの自前運用にはデータへのアクセス権と学習価値がある一方、信頼前提の弱いSMTP上でIPレピュテーション、DNSレコード、スパム防御を自分で管理しなければならない
• 受信経路はpostscreen、DNSBL、グレイリスティング、ClamAV、ベイジアンフィルタリング、LMTP、Sieveを経由し、ボットトラフィックや悪性メールを段階的に減らす構成になっている
• 送信の信頼性はSPF、DKIM、DMARC、SRSに依存しており、設定を誤るとGmailやOutlookのような受信側検査でスパム扱いされたり、黙って破棄されたりする可能性がある
• 2026年のメール自前ホスティングは依然として可能だが、IPv4の確保、複数のDNSレコード、セキュリティ更新、AIベースの脆弱性悪用に対応する多層防御が必要になる

---

なぜ自前でメールを運用するのか

• 自前サーバーの運用は、システムやネットワーキングを学ぶ教育的な体験であり、インターネットの仕組みやオープンソースへの参加を身につける入り口にもなる
• Webが少数事業者中心に集約される状況において、セルフホスティングは自分のデータに対する主権的なアクセスを維持する方法になる
• 2023年の分析では、メールトラフィックを読める主体はおおむねGoogleとMicrosoftに集約されていると評価されている
• メールは多くのオンラインアカウントのパスワードリセットに結びついているため、アカウント乗っ取りやフィッシングは他サービスへのアクセス権まで揺るがしかねない
• 自前のメール運用には長期的な管理が必要であり、ホームネットワークより安定したインターネットホスティングとレピュテーションの蓄積が求められる

メール受信の構成

• インターネットドメインはMX DNSレコードでメールを受け取るSMTPサーバーを指定し、recoil.org では pork.recoil.org がメールを処理する
• SMTPは1980年代のより信頼前提な設計から始まっており、送信者の身元を基本的に証明できないため、受信メールの送信元は簡単に偽装できる
• これに対するIETFの対応は複数の身元検証を積み重ねる方向に発展してきたが、設定を誤るとメール配信の信頼性が落ちる
• DNSベースのブロックリストはボットネット、侵害されたホスト、スパマーの情報を集約しており、メールサーバーはRBLを照会して疑わしいIPをふるい落とせる
• メールのレピュテーションはドメインではなくIPアドレスに蓄積されるため、クラウドで再利用されたアドレスや同一ブロックの近隣IPが評価に影響することがある

• 専用IPv4ブロックの確保とルーティング

  • Recoilは 185.33.27.0/24 の専用IPv4アドレスブロックを確保し、メールのレピュテーションを独立して積み上げられるようになった
  • RIPE NCCは2019年11月に未割り当てIPv4空間を使い果たしており、その後の直接割り当ては小規模な /24 待機リスト経由で行われている
  • /24 ブロックは約6か月の待機後に割り当てられ、欧州で直接申請するにはRIPE NCCの会費を支払い、LIRアカウントを開設する必要がある
  • 割り当てられたIPv4ブロックはRPKI ROAを作成してルーティング権限を指定し、RecoilのブロックはMythic Beasts AS44684に接続されている
  • 逆引きDNSも自前で制御でき、185.33.27.128 は pork.recoil.org に対応付けられ、メールレピュテーションのシグナルになる

ボットとスパムへの防御

• クリーンなIPv4ブロックを確保するだけでは不十分で、ポート25に入ってくるTCP接続の大半はスパム配送、オープンリレー探索、認証情報の推測、AI学習データ収集の試みである
• Postfix postscreen はポート25の手前でDNSBLの並列照会、pre-greet遅延、パイプライニングおよび非SMTPコマンドの検査を行う
• postscreen は正常に見えるクライアントだけを実際の smtpd に渡し、不正なクライアントは一時失敗で切断して誤検知側が再試行できるようにする
• Spamhaus、Spamcop、Barracudaのリストは重み付きで組み合わせられ、Spamhaus単独、または弱い2リストの同時判定で拒否するよう設定されている
• Apple iCloud送信MXプールは同じIPから再試行しないためpostscreenの許可リストと相性が悪く、17.0.0.0/8 全体を優先許可して回避するよう設定している

• グレイリスティングとコンテンツ検査

  • グレイリスティングは初見の送信元に一時失敗を返し、正常なMTAが数分後に再試行すれば通す方式である
  • 単発のボットネットは失敗後に次の対象へ移ることが多く、再試行キューを維持する正常な送信者と区別できる
  • postscreenとグレイリスティングを通過した時点で、元のボットトラフィックの99%以上が低いCPUコストで遮断される
  • rspamdはmilterプロトコルですべてのメッセージを検査し、怪しいメールを受理後にバウンスせず、送信サーバーが接続中の段階で拒否または遅延させる
  • ClamAVは既知のウイルス添付を検査して感染メッセージを即時拒否し、rspamdのベイジアン分類器はRedisに保存されたスパム・ハムのコーパスでメッセージをスコアリングする

ローカル配送・保存・フィルタリング

• 受信メッセージはpostscreen、グレイリスティング、rspamd、ClamAV、ベイジアン分類器を経た後、Dovecotへ配送される
• Postfixがユーザーのホームディレクトリへ直接書き込む代わりに、DovecotへLMTPで渡して、インデックス作成、クォータ、全文検索、Sieveフィルタリングを任せる
• virtual_alias_maps は [e-mail] のようなアドレスをローカル配送可能なアドレスへ変換する
• 保存形式は1998年から使っているMaildirで、各メールをユーザーの ~/Maildir 配下の単一ファイルとして保存する
• Maildirは tmp/、new/、cur/ の3つのサブディレクトリとPOSIXの原子的なrenameを使い、メールボックス全体をロックせずに新着メッセージを配送できる

• 検索インデックスとSieve

  • Stalwartのようなモダンなメールサーバーも検討したが、Maildirをサポートせず、RocksDBのような専用データベース保存を要求するため移行しなかった
  • Dovecotは別個の全文検索インデックスであるFlatcurveを通じて、Maildirの保存と検索性能を分離している
  • FlatcurveはXapianラッパーであり、メールボックスごとのXapianインデックスを ~/Maildir/fts-flatcurve 配下に置き、新着メール到着時に自動更新する
  • Sieveはメールフィルタリング専用の宣言的言語であり、DovecotのPigeonhole Sieveプラグインが配送時点のユーザーフィルタを実行する
  • システム全体のSieveスクリプトはrspamdが印を付けたメールを Junk に送り、ユーザーごとのスクリプトはフォルダー分類、休暇ルール、優先度、ヘッダー編集などを処理する

信頼できるメール送信

• メールを安定して送るには、受信防御と同じくらい送信認証が重要であり、大手受信者の検査のいずれか1つでも失敗するとスパムフォルダー送りや黙殺の原因になりうる
• SPFはドメイン直下のDNS TXTレコードで、@recoil.org からの送信を名乗れるIPアドレスを宣言する
• RecoilのSPFは v=spf1 a mx -all で、recoil.org のMXが指す pork.recoil.org だけが有効な送信者と見なされる
• Postfixは複数IPを持つホストでカーネルが任意のアドレスを選ばないよう、smtp_bind_address と smtp_bind_address6 で特定の送信元アドレスに固定されている
• DKIMはメッセージ本文と選択ヘッダーの正規化形式に暗号学的署名を付け、公開検証鍵をDNSの <selector>._domainkey.<domain> に置く

• DMARCとSRS

  • DMARCはSPFとDKIMで認証されたドメインが、ユーザーに見える From: ヘッダーと一致しているかを確認し、失敗時に受信者がどう扱うべきかを示す
  • RecoilのDMARCポリシーは p=quarantine で、rua= アドレスで集計レポートを受け取り、配送性の問題をデバッグしている
  • 主な受信者は1日1回程度、recoil.org 発信を名乗ったメッセージの要約XMLレポートを送り、Google、Microsoft、Yahoo、Fastmailなどが含まれる
  • 転送メールは元の送信者ドメインがRecoilのIPから送られる形になるため、SPFに失敗する可能性がある
  • SRSは送信エンベロープアドレスを SRS0=…=example.com=[e-mail] のような形に書き換え、宛先側のSPF検査がRecoilドメイン基準で評価されるようにする

ユーザーアクセスとWebメール

• ユーザーは通常のIMAPクライアントでDovecotサーバーに接続するか、自前ホスティングのWebメールをブラウザーで開いてメールにアクセスする
• Dovecotは pork のメールボックスアクセスを処理し、TLSでリスナーを暗号化して平文メールやパスワードが公衆ネットワークを通過しないようにする
• 証明書にはLetsEncryptを使い、imap.recoil.org、smtp.recoil.org のような複数のホスト別名はSNIで提供される
• DovecotはPostfixのSASLバックエンドも兼ねており、ユーザーはIMAPアクセスとSMTP送信で同じパスワードを使える
• RoundcubeはCaddyのTLSリバースプロキシの背後でDocker Composeサービスとして動作し、一般クライアントと同様にTLS/IMAPで pork に接続する

• Roundcubeプラグイン

  • Roundcubeの managesieve プラグインは、ブラウザーからSieveフィルタを編集できるようManageSieveプロトコルを使用する
  • markasjunk プラグインはWebメールの「Junk」ボタンをJunkフォルダーへの移動に変え、この移動がハム・スパム分類の学習をユーザーに見せずに機能させる
  • RoundcubeのManageSieve UIは生のSieve DSLを露出しない

残る作業とセルフホスティングの意味

• 現在の設定はここ数週間の日常利用ではかなり堅牢だったが、まだやるべき作業が残っている
• recoil.org はMX、A/AAAA、PTR、SPF TXT、DKIM TXT、DMARC TXTといったDNSレコードを組み合わせ、メールの受信・送信・検証を構成している
• MTA-STSは他のメールサーバーに対し、有効な証明書を持つTLSでのみ通信するよう知らせ、STARTTLSダウングレード攻撃を緩和する
• DANE/TLSAはHTTPSではなくDNSに固定されたTLS証明書ハッシュを使うが、DNSSEC署名済みDNSゾーンが必要なため、まだ導入されていない
• SRSは一部導入されているが、すべての転送経路で検証されているわけではなく、INRIA関連の失敗はDMARC失敗やドメインレピュテーションへの影響の可能性から懸念材料となっている

• JMAP、セキュリティ、今後のセルフホスティング

  • JMAPはHTTPSとJSONを使う、現代的なネットワーククライアントにIMAPより適したメールアクセスプロトコルである
  • DovecotはJMAPをネイティブサポートしておらず、評価した独立JMAPサーバー群もMaildirを捨てて独自のメールボックスストレージを要求した
  • 検討中の計画は、OCaml製JMAP実装をDovecotの前段に翻訳プロキシとして置き、JMAPリクエストをIMAP呼び出しにマッピングしてJSONレスポンスを返す方式である
  • 2026年にメールサーバーを運用するには少なくとも6種類のDNSレコードを正確に合わせる必要があり、RIPEでIPv4ブロックを確保するにはほぼ1年かかる
  • CVE公開からSMTP/IMAPリスナーを狙う実際のエクスプロイト投入までの間隔は、もはや数週間ではなく数時間単位で測られる可能性があり、特定アドレスへの固定、Webメールコンテナ隔離、グレイリスティング、DNSBLのような多層防御が必要になる

[GN⁺]

Lobste.rsの意見

• 何十年もやってきたことを不可能だと言い切る門番役を、相変わらず見かける
  実際には逆引きDNS、SPF、DMARC、MTA-STSを設定するだけで十分で、費用もそれほどかからず、難しくもないと言い続けている
  例のメールサーバー: https://poofydoof.zia.io/

  • 2008年ごろから自前のセルフホストメールを運用してきたが、いまだに不可能だと言う人が多くて戸惑う
    今は Debian + Postfix、Dovecot、rspamd の組み合わせで、自分の設定より職場の Google Workspace のほうが問題が起きることのほうが多い
  • 「何十年もやってきたこと」という部分が肝だと思う
    逆引きDNS、SPF、DMARC、MTA-STSだけでよいという話は、すでに評判の良いドメインとIPアドレスには100%当てはまる
    大手事業者からすでに信頼されているメールサーバーに新しいドメインを追加すれば評判はすぐ積み上がるし、既存ドメインを新しいメールサーバーIPへ移しつつ DKIM まで設定していれば問題ない
    しかし、新しいドメインと新しいメールサーバーIPでゼロから始める場合はかなり事情が違うと聞いており、大手事業者の機械学習システムが満足するまで自動的にスパム扱いされる可能性が高い
    そちらのシステムの利用者が自分のドメインにメールを送り、スパムフォルダから返信を取り出すといった行動が、しばしばうまく効くようだ
  • 3年ほどメールサーバーを運用してみて、難しいのは DNS、SPF、DMARC、MTA-STS の設定ではなく、トランザクションメール送信時にブロックリストに引っかからないようにすることと、一部のメールプロバイダで許可リスト登録ができないことだと感じた
    そういうことを追い回すのに時間を使うくらいなら、月5ドルほど払って誰かに任せるほうがよいと思う
  • 例のメールサーバーはすばらしいし、これも良い
    https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
    この構成の詳細がもっと気になる
    Mango Pi MQ-Pro は入手しづらそうだが、NetBSD/Linux のサポートが良いほかの超低価格デバイスがあるのかも気になる

• 自分でメールサーバーを運用するもう一つの理由は、誰かがすでに自分のドメインを使ってスパムを送っていることに気づけるからだ
  自分のドメインの一つが Google Domains の売却のせいで Squarespace に移管されたとき、Mailgun のアカウントを持っていなかったにもかかわらず、Squarespace が Mailgun 用の MX/SPF/DKIM DNS レコードを自動追加した
  誰かが Mailgun 上でそのアカウントを奪い取り、自分のドメインから送ったように見せかけて自分にスパムを送ってきた
  ありがとう、Google

• 特にIPv4割り当ての部分が興味深い
  ヨーロッパで自力でやるには、RIPE NCC の年会費を払ってローカルインターネットレジストリ（LIR）アカウントを開けと書かれているが、https://www.ripe.net/membership/payment/ によれば年1800ユーロだ
  かなり痛いが、これより安いとスパマーにもっと悪用されやすくなりそうでもある

  • 安くはないが、アドレスあたり年約12ポンドなので、地域の友人や家族向けサービスで分け合うなら、そこまで悪くない
    OCaml で BGP サーバーを書く楽しさは値段に換えられない :-)

• メールの送受信にIPv6を現実的に使えるのか気になる

  • いい質問だ
    記事を書く際に調べてはみたが、数年前に自分のメールサーバーで IPv6 を無効にしていたので、もっと経験を積むまでは見送ることにした
    https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters によれば、Gmail、Microsoft、Yahoo のようなメールプロバイダは、ドメイン評判とIP評判に異なる重みを与える独自のスパムフィルタを使っており、IPv6 サポートもまだ成熟途上だ
    Gmail は IPv6 メールに有効な PTR レコード、SPF、DKIM を求め、DMARC の使用も強く推奨している
    これらの要素なしに IPv6 で送られたメールは、スパムフォルダに入ったり遅延したりすることが多い
    Microsoft のフィルタリングシステムは IPv6 を SNDS と JMRP プログラムに含めているが、送信元の評判が確立していない場合、IPv6 メールを制限したり遅延させたりする可能性がある
    結局のところ IPv6 はもう一つの障害点であり、始めたばかりの段階でIPv4/IPv6混在配信ドメインを構成するのは、おそらく良い考えではない
    まだ IPv6 専用の SMTP エンドポイントは見つけられていない