本レポートは、CentOS 7環境におけるqmailメールサーバー運用で発生した主要な問題と、その解決策を体系的にまとめたものです。qmail + vpopmail + tcpserver-ssl構成での実践的なトラブルシューティング知見を集約しています。
1. 問題カテゴリ一覧
| カテゴリ | 概要 | 重要度 |
|---|---|---|
| ポート枯渇・接続滞留 | SMTPS/POP3S/IMAPSでESTABLISHED接続が長時間残留 | 高 |
| TLSハンドシェイク停滞 | TCP接続後、TLSハンドシェイクで停止 | 高 |
| 認証失敗 | vpopmail/vchkpwでのパスワード認証エラー | 中 |
| メール転送とSPF/DKIM | 転送時のSPF失敗、DMARC認証問題 | 中 |
| バウンス処理 | ダブルバウンス、トリプルバウンス発生 | 中 |
| 配送エラー | 接続切断、ドメイン不明、メールボックス不在 | 中 |
| ゾンビプロセス | qmail-smtpdプロセスが<defunct>状態 | 低 |
| タイムアウト未設定 | tcpserver-ssl -tオプション未設定 | 高 |
2. ポート枯渇・接続滞留問題
2.1 症状
SMTPS(465)、POP3S(995)、IMAPS(993)ポートにおいて、ESTABLISHED状態の接続が3日以上残留する現象が発生。netstatで「ESTABLISHED off」と表示され、単一IPから20以上の同時接続が観測されました。tcpserver-sslの接続上限(-c 100)に達し、正規ユーザーがブロックされる事態となりました。
2.2 根本原因
tcpserver-sslの起動コマンドに-t（タイムアウト）オプションが未設定であったため、TLSハンドシェイク段階で停止した接続が無期限に維持されました。
攻撃パターン:
- SSL/TLS脆弱性スキャン（sslyze、testssl.sh）
- slowloris型攻撃（接続を開いたまま保持）
2.3 解決策
主要対策: tcpserver-sslに-t 30オプションを追加
# Before
tcpserver-ssl -qvs -l0 -c 100 -HR -u 89 -g 89 ...
# After
tcpserver-ssl -qvs -l0 -c 100 -t 30 -HR -u 89 -g 89 ...補助対策:
- iptables connlimit: 8接続/IP
- iptables hashlimit: 5/min/IP
- カーネルパラメータ: tcp_keepalive_time=300
- conntrackタイムアウト: 3600秒
2.4 技術的理解
クライアント → TCP 3-way handshake → tcpserver-ssl → TLS handshake → qmail-smtpd
↓ ↓
netstat: ESTABLISHED ★攻撃はここで停止- TCPの3ウェイハンドシェイク完了後にnetstatはESTABLISHEDと表示
- これはTLS/SSLハンドシェイク完了を意味しない
- 攻撃はTLSハンドシェイク段階で停止し、qmail-smtpdには到達しなかった
- そのため
timeout 60 qmail-smtpdは無効（プロセスが起動していない）
3. vpopmail認証失敗問題
3.1 症状
Thunderbirdからのログインで以下のエラーが発生:
vchkpw-submission: password fail user@domain:192.168.x.xvpopmail自体は正常に動作しており、コマンドラインでの認証テストは成功する状態。
3.2 調査手順
# 1. ユーザー存在確認
/var/vpopmail/bin/vuserinfo user@domain
# 2. コマンドライン認証テスト
printf "user@domain\0password\0" | /var/vpopmail/bin/vchkpw /usr/bin/id 3<&0
echo $? # 0なら成功
# 3. Base64エンコードでtelnetテスト
printf "\0user@domain\0password" | base64
telnet localhost 587
EHLO test
AUTH PLAIN <base64文字列>3.3 よくある原因
- クライアントが異なるパスワードを送信 – Thunderbirdに保存された古いパスワード
- 認証方式の不一致 – サーバーはPLAINを期待、クライアントはCRAM-MD5を使用
- 文字エンコーディング問題 – 特殊文字を含むパスワード
- ユーザー名形式 – @ドメインなしでログイン試行
3.4 解決策
- Thunderbirdの「保存されたパスワード」を削除して再入力
- SMTP認証方式を「通常のパスワード認証」に設定
- ユーザー名は完全なメールアドレス形式（user@domain）を使用
- 接続の保護は「STARTTLS」を選択
4. メール転送とSPF/DKIM/DMARC問題
4.1 問題の構造
.qmailファイルによる単純な転送では、エンベロープFromが元の送信者のまま維持されます。
元メール: [email protected] → [email protected]
転送後: [email protected] → [email protected]
↓
Yahoo側でSPFチェック
送信元IP: your-server.jp
gmail.comのSPFレコードにyour-server.jpは含まれない
→ SPF FAIL4.2 SPF認証に問題がある転送方法
| 方法 | 設定例 | 結果 |
|---|---|---|
| 単純な転送 | &[email protected] |
SPF FAIL ❌ |
| forward配送 | |forward [email protected] |
SPF FAIL ❌ |
4.3 解決策：qmail-injectによるエンベロープFrom書き換え
|qmail-inject -f [email protected] -a [email protected]この方法で:
- エンベロープFrom: 転送サーバーのドメインに書き換え → SPF PASS
- ヘッダーFrom: 元のまま維持 → DKIM署名有効
4.4 DMARCがパスする理由
DMARCは以下のどちらか一方が成功すればパス:
- SPFアライメント（エンベロープFrom = ヘッダーFrom）
- DKIMアライメント（DKIM署名ドメイン = ヘッダーFrom）
転送でエンベロープFromを書き換えてもDKIM署名は維持されるため、DKIMアライメントでDMARCをパスできます。
5. バウンスメール処理問題
5.1 バウンスの連鎖
1. 元メール配送失敗
↓
バウンスメール生成（From: <>）
↓
2. バウンスメールも配送失敗（送信者アドレスが無効等）
↓
ダブルバウンス生成
↓
3. ダブルバウンスも配送失敗
↓
トリプルバウンス → 破棄（discarding bounce）5.2 特殊なアドレス形式
ダブルバウンス時、qmailはアドレスを以下のような形式に変換:
[email protected]これは:
- 無限ループ防止
- エラー追跡の容易化
- 特別なエラー処理ルートへの誘導
のための意図的な設計です。
5.3 対策
# postmasterエイリアスの設定
/var/qmail/alias/.qmail-postmaster
# rootエイリアスの設定
/var/qmail/alias/.qmail-root
# ダブルバウンス送信先
/var/qmail/control/doublebounceto6. 配送エラー各種
6.1 HELO拒否エラー
Connected to xxx but my name was rejected.
Remote host said: 421 Service not available原因:
- 逆引きDNS未設定または不一致
- /var/qmail/control/helohostの設定不備
- 一部のISPは逆引きDNSチェックが厳格
対策:
# 確認
cat /var/qmail/control/helohost
dig -x <送信元IP> +short
# 正引き・逆引きの整合性確認6.2 ドメイン不明エラー
Sender address rejected: Domain not found送信者のドメインがDNSで解決できない。スパムメールの特徴。
6.3 接続切断エラー
connection died (#4.4.2)一時的なエラー、自動再送信されます。原因:
- 相手サーバーの負荷
- ネットワーク不安定
- タイムアウト設定
6.4 メールボックス不在エラー
Sorry, no mailbox here by that name. (#5.1.1)永続的エラー。存在しないローカルユーザー宛。スパマーによる辞書攻撃の可能性あり。
7. ゾンビプロセス問題
7.1 症状
$ ps aux | grep qmail-smtpd
vpopmail 12345 0.0 0.0 0 0 ? Z [qmail-smtpd] <defunct>
vpopmail 12346 0.0 0.0 0 0 ? Z [qmail-smtpd] <defunct>7.2 原因
- qmail-smtpdが適切に終了処理されていない
- tcpserverが子プロセスのwait()を実行していない
- recordioやfixcrioが終了処理に影響
7.3 対策
短期: システム再起動でゾンビプロセスをクリア
長期:
- tcpserver設定の見直し（-c、-t）
- ゾンビプロセス監視スクリプトの導入
- Postfixへの移行検討
8. タイムアウト設定の体系的理解
8.1 tcpserver/tcpserver-sslのオプション
| オプション | 説明 | 推奨値 |
|---|---|---|
| -t seconds | TLSハンドシェイクタイムアウト | 30 |
| -T seconds | IDENT情報取得タイムアウト | 10 |
| -c number | 同時接続数上限 | 100 |
8.2 qmail-smtpdの環境変数
| 環境変数 | 説明 | デフォルト |
|---|---|---|
| QMAIL_SMTP_TIMEOUT | SMTPコマンドタイムアウト | 1200秒 |
| QMAIL_SMTPD_TIMEOUT | 全体セッションタイムアウト | なし（無制限） |
| QMAIL_SMTPD_DATA_TIMEOUT | DATAコマンドタイムアウト | SMTP_TIMEOUT値 |
8.3 カーネルパラメータ
# /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
net.netfilter.nf_conntrack_tcp_timeout_established = 36009. 教訓と推奨事項
9.1 レイヤー理解の重要性
TCP層、TLS/SSL層、アプリケーション層の区別が問題切り分けに不可欠です。netstatのESTABLISHEDはTCP層の状態であり、TLSハンドシェイク完了を意味しません。
9.2 デフォルト設定の危険性
tcpserver-sslのデフォルトはタイムアウトなし（無制限）。明示的なタイムアウト設定が必須です。本番環境では必ず-tオプションを設定してください。
9.3 多層防御の実装
| レイヤー | 対策 |
|---|---|
| アプリケーション | tcpserver-ssl -t |
| ネットワーク | iptables connlimit/hashlimit |
| カーネル | sysctl tcp_keepalive_* |
9.4 監視の重要性
- ESTABLISHED接続数の定期監視
- 認証失敗ログの監視
- ゾンビプロセスの検出
- 異常の早期発見が被害拡大を防ぐ
9.5 将来への移行検討
qmailは2007年以降更新されていません。Rocky Linux 9移行時にはPostfixへの移行を検討することをお勧めします。Postfixは:
- 活発に開発されている
- ネイティブTLSサポート
- 現代的な認証方式
- 優れたドキュメント
付録: コマンドリファレンス
接続状況確認
netstat -an | grep -E ":465|:995|:993" | grep ESTABLISHED | wc -l
ss -tnp | grep -E ":465|:995|:993"認証テスト
printf "user@domain\0password\0" | /var/vpopmail/bin/vchkpw /usr/bin/id 3<&0ゾンビプロセス確認
ps aux | grep -E "Z.*qmail"タイムアウト設定確認
cat /proc/$(pidof tcpserver)/cmdline | tr '\0' ' '作成日: 2026-01-09
コメント