- メールは本来 オープンなシステムであり、2026年には配信問題やスパムを管理しながら自宅やVPSで運用し、少数の大企業にメールを預けずに済む
- 自宅で運用するには、ブロックリストに載っていない 固定IPv4、CGNAT未使用、PTRレコード変更権限、
25・143・465・587・993 ポートの開放が必要で、条件が合わなければVPSが適している
- SPF・DKIM・DMARC・MX・PTRを正しく設定し、mail-tester.comで配信状態を検査する必要がある。短時間のインターネット障害が発生しても、送信側サーバーが配信を再試行する
- Rspamdの GPTプラグインとローカルの
Gemma 4 12B QAT モデルを組み合わせると、外部LLM APIに個人メールを送らずにスパム確率と判定理由を生成できる
- docker-mailserverとThunderbird・Webメールクライアントで構築のハードルは下げられるが、運用者は バックアップ・復旧・リモートアクセス・アップデートを自ら責任を持ち、復旧手順を少なくとも一度は試験する必要がある
自宅とVPSのどちらを選ぶか
- 一般的には VPS が推奨されるが、自宅のインターネットが次の条件をすべて満たすなら、自宅でもメールサーバーを運用できる
- ブロックリストに掲載されていない固定IPv4アドレス
- CGNATの背後にない回線
- ISPサポートなどを通じてIPの PTRレコードを変更できる権限
- 一般的なメールサーバーポート
25, 143, 465, 587, 993 を開放できる環境
- サーバーが一時的に落ちても、送信側メールサーバーが配信を再試行するため、すぐに受信メールを失うわけではない
- 1日のうちインターネット停止時間が 40%未満であれば正常に動作し得る
メールサーバーソフトウェア
ドメインとDNS設定
- IPと同様に、ドメインもまずスパムブロックリストへの掲載有無を確認する必要がある
- 正常な送信と受信には、次の DNSレコード が必要である
- SPF: ドメインに代わってメールを送信できるサーバーを指定する。一般的な値として
v=spf1 mx a ~all を使用できる
- DKIM: 送信メールのヘッダーに暗号学的署名を追加する。サーバーが案内した名前と公開鍵の値をドメインに登録する
- DMARC: SPFとDKIMを拡張してドメイン偽装を防ぐ。値が不確かな場合は DMARC生成ツール を利用できる
- MX: 他のサーバーがメールを配信する場所を指定する。
mail.yourdomain.com のAレコードをサーバーIPに紐づけ、MX優先度 10 の値としてそのホスト名を設定する方法が一般的である
- PTRレコード はISPやVPS事業者だけが設定でき、サーバーIPが
mail.yourdomain.com のような実際のメールサーバーホスト名へ逆引きされる必要がある
- 一部のサーバーは自動サービス検出用レコードの追加も推奨するが、SPF・DKIM・DMARC・MX・PTRが基本構成である
- 構築後は mail-tester.com でレコードとサーバー動作、メール配信状態を検査することが推奨される
ローカルLLMを使ったスパム対策
- 従来のオープンソースのスパム対策は、IP・ドメインのブロックリスト、Spamhausのような外部サービス、キーワード検索に依存しており、効果が低く、自前ホスティング離れの主な原因だった
- ここ2年で ローカルLLM分類 が、自前ホスティング環境のスパム問題を解決できる選択肢として登場した
- Rspamd は、ブロックリスト、IP・DNS検査、キーワード検出に加え、GPTプラグイン によってメールがスパムかどうかをLLMに分類させられる
- 個人メールを外部LLM APIへ送る代わりに、Gemma 4 12B QAT をローカルで実行する
- GPUまたはCPUで実行でき、最低 7GB RAMまたはVRAM が必要である
- 多言語に対応しており、メール分類に活用できる
ローカルモデルの実行とRspamdの接続
- ローカルLLMを初めて構成する場合は、Windows・Linux・macOS向けの Unslothのllama.cppガイド を参照できる
- LinuxとmacOSでは次のコマンドで
llama.cpp をインストールする
curl -LsSf https://llama.app/install.sh | sh
winget install llama.cpp
- モデルサーバーは次のように実行し、
localhost:8080 でチャットインターフェースを確認できる
llama serve -hf unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL --reasoning off -fa on -c 16000 --temp 0.7
- Rspamdの
/etc/rspamd/local.d/gpt.conf で type = "openai" とローカルの /v1 エンドポイントを指定すれば、OpenAI互換インターフェースとしてモデルを接続できる
- モデルは
unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4_K_XL に設定する
- 最大出力トークンは
100、温度は 0.1、タイムアウトは 30秒 に構成する
- GPUのないLLMサーバーではタイムアウトを延ばせる
- 応答はJSONとして解釈し、
spam ではなく probability キーを要求する
- プロンプトでは、ヘッダー・件名・本文を分析し、
0.0~1.0 の間の スパム確率 と短い判定理由だけをJSONで返すよう指示する
- 受信者別の会話コンテキスト機能は、Redisに最近のメールのラベル、主要な送信者、512文字の要約を保存し、5件以上集まると分類プロンプトに含める
- 範囲は受信者別メールボックスである
user
- メッセージ要約の保持期間は
14日、Redisキーの寿命は 30日
- 外部呼び出しなしにローカルで動作する
- スパムメールには、恐怖をあおるマーケティング、望まない商業コンテンツ、疑わしい国際化ドメインなどを根拠に高い確率を返せる
- 正常な技術テストメールには、疑わしいリンクや宣伝文句がないことを理由に低い確率を返せる
- Rspamdの Webインターフェース では、グラフとデータを確認し、メールを貼り付けて予想される分類結果を試験できる
メールクライアントの選択
- デスクトップでは Thunderbird がOutlookを代替できる高機能なオープンソースクライアントである
- 必要な基本機能と十分な検索機能を提供する
- Androidアプリ も提供している
- 3年間使って問題はなかった
- Webメールが必要なら、次の選択肢を利用できる
保守と運用責任
- docker-mailserverのような現代的なメールサーバーソリューションは、セキュリティ修正 と本番環境を壊さない自動アップデートを考慮して設計されている
- 自前ホスティングはデータのコントロール権を提供する一方で、バックアップ、復旧、リモートアクセス、アップデートの責任を運用者に戻す
- バックアップがなければすべてのデータを失う可能性があるため、十分な バックアップ計画 を用意し、復旧手順を少なくとも一度は試験する必要がある
- 条件と運用責任を引き受けられるなら、短時間のサーバー停止があってもメールを運用でき、データ主権を重視するユーザーは自前ホスティングを試せる
1件のコメント
Lobste.rsの意見
Fastmail を使っていて、面倒ごとはすべて回避できている。どんな面倒ごとを回避しているのか読むのは面白かった
重要な受信トレイなら、Migadu、Simplymail、Fastmail のような優れた ホスティングメールボックスサービス があるので、自分で運用しようとは思わない。趣味用や重要でない用途ならあり
Gmail依存の問題を示すように、現在 Gmail が Lobsters のパスワード再設定メール をスパムとしてブロックしている
ログには「Gmail has detected that this message is likely 550-5.7.1 unsolicited mail. To reduce the amount of spam sent to Gmail, this 550-5.7.1 message has been blocked.」と出ており、これをどうやって Google に知らせればいいのか気になる
メーリングリストゲートウェイが lobste.rs 側で壊れたのかと思って購読解除したが、どうせあまり読んでいなかったし、今はウェブサイトのほうを好んでいる
自宅でメールを自前運用するという発想は良いが、引っ越しのときが問題。引っ越し中にも重要なメールは来るので、バックアップMX だけでは不十分
実装は可能だろうが、引っ越し自体でも十分ストレスが大きいのに、引っ越しチェックリストにメール移行手順まで入れたくはない。その間ブログや隠しDNSマスターが止まるのは構わない
約15年前に安価なVMへメールサーバーを移して以来、ずっと安定して運用できている。定住先でブロックリストに載っていない固定IPと企業向けレベルの回線を使えるなら問題ないだろう
また SMTP にはリトライがプロトコル自体に組み込まれているので、サーバーが24時間前に再試行をやめたなら、関連仕様に準拠していないことになる。メールボックスが存在しない場合や容量超過時のようにサーバーが明示的に拒否するケースとは違い、SMTP は思っているより堅牢だ
自前でメールを運用するときの難しい部分は、受信スパムではなく、送信に必要な対策をすべて行っても大手メール事業者が送ったメールをスパム判定すること
個人や家庭から送る程度の量では、IP に 良い評判 が蓄積されないので、Gmail などの受信トレイに入らなくなり始めると、事実上解決が難しい
ただし Amazon SES のようなサービスでリレーすれば、設定も簡単で配送問題も消えるかもしれない。政治的理由やデータ主権のために自前運用するなら、受け入れにくい解決策かもしれない
自前メールサーバーの一番良い点は、スパムフィルタリングをしなくてよい こと。たまに迷惑メールは来るが、誰でも自分にメールを送れるという確信のほうが良い
スパムフォルダーを確認するだけでは不十分。大手テック企業はろくな理由もなくメールをひそかに破棄することがあり、Gmail の受信成功率は約90%なので、他の大手事業者からのメールでさえ10%は消える。自前運用のメールは一度も受信に失敗したことがない
一方で他の大手サービスのアカウントにメールを送るには、その側のアカウントがまだ必要だが、連絡先としては常に自前運用のアドレスを案内している。大手事業者は送信専用に使い、MX は自前サーバーに向けられるか試してみたい
https://xmox.nl は設定がとても簡単だった
ウェブサイトの メーリングリスト を自前で運用している。購読者は数人だけだが、メールは正常に配送されている
個人メールまで自前運用するつもりはない
数年前に Hetzner VPS に https://modoboa.org/ をインストールしたが、アップグレードに何度も失敗した末に、事実上あきらめた。今も大半が動いているという理由だけで維持しているが、長期的に持続可能な構成 ではなく、次の選択肢はまだ決めていない
Steam のような一部の二要素認証コードは受信トレイに届くのが遅すぎる。原因が分からないので、そういうときはほとんど使っていない Gmail アカウントを使っている
スパムもある程度は通ってしまうが、受信スパムには 完璧な解決策はない。自然言語処理向けに設計された LLM はこの作業に向いているかもしれず、実際の性能は気になるが、リソース消費が途方もなく大きくなる可能性もありそうだ