これは、さくらインターネット Advent Calendar 2025 24日目の記事です。昨日は@zetta1985 さんの 「さくらのクラウドの「シンプルMQ」で始めるイベント駆動アプリケーション」でした。シンプルMQを本番で使う上で、運用を考慮したProtocol Bufferの採用や使用帯域節約のためのデータ圧縮は納得感が高い実践的な解説記事でした。実は私はシンプルMQの設計や開発に携わっているので、このような記事は私が書かないといけないところですが、すっかり放置してしまっておりまして、記事にしてもらって大変感謝です。ということで、私はメールサーバの話ですw
ずっと変わらない複雑さ
メールサーバを作る場合、多くのOSがサポートされていることから、MTAはPostfixでMDAはDovecotを使うことが多いでしょう。この場合、昨今、大手メールSaaSが取り組んでいる送信ドメイン認証やTLS通信の強化に対応するには、追加のミドルウェアが必要となります。
例えば、送信時のDKIM署名をするならOpenDKIMを利用し、転送でメールを改変するのならFromを書き換えにPostSRSdを利用し、そのまま転送するならARC署名をOpenARCを利用したり、あるいはDKIMもARCもrspamdを利用するか、などなど。OpenDKIMもrspamdのそれも、元はMTAのsendmail由来のmilterという拡張仕様によって実現されていて、野良を含めるともっといろんな選択肢があったりします。さらには、DMARCポリシー適応とレポートの運用や、DKIMなどの鍵のローテーション、受信時の送信ドメイン認証の検証や、TLSの強制をやろうとすると、考えないといけないことは盛りだくさんです。
昨今のソフトウェア開発において、技術選択をドキュメント化するプラクティスとしてADRという手法があります。メールサーバが必要なチームにおいて、メールにおける技術選択を正しく言語化しADRとして書き残せるチームは、はたして多いでしょうか。
メール技術はインターネットの前に作られたものなので、めちゃ古く、当時は、遅延はするものだし、中身は見え、改竄できるものでした。現在は、インターネットにおいてオープンなメッセージングツールとして広く普及しています。社会の基盤というインフラになっているため、メールの仕様は互換性を維持しつつも安全になるよう、継ぎ接ぎではありますが、追加仕様が多く積み上がっています。つまり、メールサーバをミドルウェアの組み合わせでちゃんと運用しようとすると技術が複雑でとても難しいのです。
そんな中、最初から安全に使えるというSecure by Designの思想を持ったオールインワンメールサーバがStalwartです。
Stalwartとは
Stalwartは、Rustで書かれたモダンなオールインワンメールサーバです。SMTP、IMAP、JMAP、POPなど、メールに関するプロトコルをネイティブにサポートし、単一のバイナリで動作します。
従来のPostfix + Dovecotの構成では、MTAとMDAが別々のソフトウェアであり、それぞれの設定ファイルを理解し、連携させる必要がありました。さらに、送信ドメイン認証やスパムフィルタリングを実装するには、OpenDKIM、OpenARC、Rspamd、PostSRSdなどの追加ミドルウェアを組み合わせる必要があり、運用の複雑さが増していました。
Stalwartは、これらの機能をすべて標準で組み込んでいます。DKIM署名と検証、SPF検証、DMARC検証、ARC署名、SRS（Sender Rewriting Scheme）、スパムフィルタリング、さらにはレート制限やグレイリスティングまで、メールサーバに必要な機能がすべて揃っています。
また、設定はTOMLファイルで一元管理され、人間が読みやすく、バージョン管理も容易です。データベースは組み込みのRocksDBを使うこともできますし、PostgreSQL、MySQL、SQLiteなど外部データベースとの連携も可能です。
何が嬉しいか
Stalwartを使って嬉しいポイントを挙げます。
シンプルな運用
最大のメリットは、複数のミドルウェアを組み合わせる必要がなくなることです。Stalwart一つで完結するため、設定箇所が減り、トラブルシューティングも容易になります。ログも一箇所に集約されるため、問題の原因特定がしやすくなります。
Secure by Design
Stalwartは最初からセキュリティを重視して設計されています。TLS通信は標準でサポートされ、Let's Encryptとの連携も簡単です。送信ドメイン認証（SPF、DKIM、DMARC、ARC）はすべて組み込まれており、追加の外部ミドルウェアなしで利用できます（DNS設定やポリシー設計は別途必要です）。
Container Ready
Stalwartはシングルプロセスでマルチスレッドかつ非同期処理を行うため、共有メモリ空間で状態を一元管理します。また、データは外部ストレージを利用するので、ステートレスで管理できます。これらの性質から、Stalwartはコンテナで容易に動かせ、クラウドネイティブ環境との親和性が高いと言えるでしょう。
ごく当たり前のように聞こえますが、Postfixはマルチプロセスのソフトウェアで、smtpdやqmgrといった複数の独立したプログラムが協調して動作します。メールSpoolはファイルで管理します。そのため、コンテナで動かすには、マルチプロセスによるゾンビプロセス問題や、データ問題があり、既存のオーケストレーションでは色々工夫する必要があります。
外部のセキュリティ監査をクリア
OSSとしては比較的珍しく、StalwartはRadically Open Securityという外部のセキュリティ専門組織によるセキュリティ監査を完了しているようです。これは、第三者の専門家によってコードベースが徹底的にレビューされ、潜在的な脆弱性や設計上の問題が検証されたことを意味します。多くのOSSプロジェクトは開発者自身やコミュニティによるレビューに依存していますが、独立した専門組織による監査は、より高い信頼性と透明性を提供します。特に、メールサーバのような重要なインフラストラクチャにおいて、この監査の完了は大きな安心材料となりますね。
仮想キューによる柔軟な送信制御
Stalwartは仮想キュー機能を提供しており、ポリシーに基づいてメール送信キューを分割できます。これは大規模送信者にとって特に重要な機能です。
例えば、複数のテナントや異なる優先度のメールを同じサーバーで扱う場合、一部の送信者が大量のメールを送信することで、他の送信者のメールが遅延してしまう「ノイジーネイバー問題」が発生することがあります。仮想キューを使えば、送信元ドメインや優先度、テナントごとにキューを分けて管理できるため、重要なメールが大量送信の影響を受けることなく配信されます。
また、配信先のドメインやレート制限ポリシーに応じたキュー管理も可能で、より細かい制御ができます。
容易なスケーリング
Stalwartは役割の異なる4種類のストレージを持っていて、それらを外部化することで、水平スケーリングも可能です。データストアの推奨のストレージは、分散型のトランザクションキーバリューストアのFoundationDBとなっていて興味深いです。ただし、FoundationDB自体の運用難易度は高いと聞きます。小規模環境ではRDBMSを採用する方が現実的な気がします。また、可観測性においても分散トレーシングやPrometheusメトリクスのエクスポートにも対応している模様で素晴らしいです。
モダンなアーキテクチャ
Rustで書かれているため、メモリ安全性が保証され、パフォーマンスも優れています。また、JMAPという新しいメールプロトコルをネイティブサポートしている点も見逃せません。JMAPはまだクライアントは少ないですが、IMAPの複雑さを解消し、よりモダンなメールクライアントの実装を可能にします。
graph TB
subgraph "Entrypoint"
MAIN[main]
end
subgraph "Protocols"
SMTP[smtp]
IMAP[imap]
JMAP[jmap]
POP3[pop3]
DAV[dav]
end
subgraph "Libraries"
COMMON[common:<br/>config, auth, listener]
STORE[store]
DIR[directory]
SPAM[spam-filter]
EMAIL[email]
UTILS[utils:<br/>crypto, TLS]
end
subgraph "Support"
SERVICES[services:<br/>background job]
TRC[trc:<br/>telemetry]
CLI[cli]
end
MAIN --> SMTP
MAIN --> IMAP
MAIN --> JMAP
MAIN --> POP3
MAIN --> DAV
SMTP --> COMMON
IMAP --> COMMON
JMAP --> COMMON
POP3 --> COMMON
DAV --> COMMON
COMMON --> STORE
COMMON --> DIR
COMMON --> UTILS
COMMON --> TRC
SMTP --> SPAM
SMTP --> EMAIL
JMAP --> STORE
IMAP --> STORE
COMMON --> SERVICES注意すること
Stalwartを使用する上で気にすべきことを挙げます。
新しいプロジェクトであることのリスク
Stalwartは2022年に最初のリリースがあった比較的新しいプロジェクトです。PostfixやDovecotのように数十年の実績があるわけではないため、何が起きるかわからないリスクがあり、本番環境に導入する際は十分な検討が必要です。特に、RFCに準拠していないメールやクライアントはブロックされてしまうかもしれません。
また、Postfixには長年の蓄積による膨大な知見やツールが存在しますが、Stalwartにはまだそれがありません。問題に遭遇したときに、コミュニティから答えを見つけられる可能性は低いでしょう。少なくともソースコードを追うにはある程度Rustを読める必要があります。
マイグレーションの手間
既存のPostfix + Dovecot環境からの移行は、設定の書き換えやデータの移行が必要になります。特に、複雑なフィルタリングルールや独自のカスタマイズを行っている場合は、検証を含め移行コストが高くなるでしょう。マイグレーションスクリプトを自作しなければならないかもしれません。ただ、ウェブサイトを見ると有償でStalwart社がやってくれそうな雰囲気はあります。
機能の差異
Postfix + Dovecotで実現できていた一部の機能が、Stalwartではまだサポートされていない可能性があります。導入前に、必要な機能がすべて揃っているか確認が必要です。
ライセンスの考慮
StalwartはAGPL-3.0ライセンスで提供されています。これは、Stalwartを改変して使用する場合、その改変内容を公開する必要があることを意味します。一方で、有償契約によってエンタープライズライセンスに切り替えることも可能です。エンタープライズライセンスでは、グラフィカルなダッシュボードやLLMによるフィルタリング、送受信メッセージの履歴機能といった追加機能が利用できるようになります。商用利用や改変内容を公開したくない場合は、エンタープライズライセンスの検討が必要です。
まとめ
これからメールサーバを構築するなら、Stalwartは有力な選択肢の一つです。特に、新規プロジェクトや、モダンな技術スタックを採用したい場合には適しています。
従来のPostfix + Dovecotの組み合わせは枯れた技術であり安定性は高いですが、設定の複雑さや、追加ミドルウェアの組み合わせによる運用負荷は無視できません。一方、Stalwartはオールインワンのアプローチにより、これらの課題を解決しています。
ただし、本番環境に導入する際は、十分な検証を行い、チームがStalwartの設計思想や設定方法を理解していることが重要です。また、エコシステムがまだ小さいため、問題解決には自力で取り組む覚悟も必要になります。
メールサーバの技術選択は、プロジェクトの要件、チームのスキルセット、運用体制などを総合的に考慮して行うべきです。Stalwartは、シンプルで安全なメールインフラを構築したいチームにとって、おすすめのソフトウェアです。正直、Stalwartは紹介しきれないほどの機能があり、作者の熱意というか既存MTAへの怒りというか、ゲームチェンジ対する挑戦的なものが伝わります。
https://stalw.art/
明日はいよいよクリスマス！担当は @kazeburo さんです。お楽しみに！