Docker-Mailserver 用户配置与初始化问题深度解析

问题背景

在使用 Docker-Mailserver 项目时，许多开发者会遇到一个典型的"先有鸡还是先有蛋"的问题：如何在容器启动时自动创建初始邮件用户。这个问题的核心在于 Dovecot 服务要求至少存在一个用户账户才能正常启动，而传统的 user-patches.sh 脚本执行时机却是在服务启动之后。

问题本质分析

Docker-Mailserver 的启动流程存在以下关键点：

1. 服务依赖关系：Dovecot 作为邮件存储服务，强制要求至少配置一个有效用户才能启动
2. 初始化顺序：user-patches.sh 脚本实际上是在服务初始化完成后执行，而非之前
3. 配置加载机制：Postfix 和 Dovecot 的账户配置依赖于 postfix-accounts.cf 文件

这种设计导致了开发者无法简单地通过 user-patches.sh 来创建初始用户，因为脚本执行时 Dovecot 已经因缺少用户而拒绝启动。

解决方案比较

1. 预生成账户配置文件（推荐方案）

最优雅的解决方案是预先创建 postfix-accounts.cf 文件：

mkdir provisioning
./setup.sh email add [e-mail] password

然后将生成的文件通过 Docker 配置挂载：

services:
  mailserver:
    volumes:
      - ./provisioning/postfix-accounts.cf:/tmp/docker-mailserver/postfix-accounts.cf

优点：

• 完全符合 Docker 的最佳实践
• 无副作用，不会影响后续容器重启
• 配置清晰可见

2. 自定义入口脚本

对于需要动态创建的场景，可以覆盖容器入口点：

#!/bin/bash
# 检查并创建必要用户
if [ ! -f /tmp/docker-mailserver/postfix-accounts.cf ]; then
    setup email add [e-mail] password
fi

# 继续原始启动流程
exec "$@"

注意事项：

• 需要处理用户已存在的情况
• 密码以明文形式存在有一定安全风险
• 更适合测试环境使用

3. 使用 Docker Compose Configs 功能

Docker 17.06+ 提供了原生配置管理：

configs:
  mail-accounts:
    content: |
      [e-mail]|{SHA512-CRYPT}$6$salt$hash
      [e-mail]|{SHA512-CRYPT}$6$salt$hash

进阶问题：本地邮件投递失败

在解决初始用户问题后，开发者可能会遇到本地邮件无法投递的问题，表现为：

status=bounced (unknown user: "recipient")

根本原因：

• 邮件域名同时出现在 mydestination 和 virtual_mailbox_domains 配置中
• Postfix 投递逻辑冲突

解决方案： 通过 user-patches.sh 调整 Postfix 配置：

#!/bin/sh
postconf -e 'mydestination = localhost'
postfix reload

注意事项：

• 此方案会影响系统邮件的接收
• 更佳实践是保持邮件域名与主机名不同（如 mail.example.com 主机服务 [e-mail]）

最佳实践建议

1. 环境区分：

   • 生产环境：使用预生成配置文件
   • 测试环境：可考虑入口脚本方案

2. 密码安全：

   • 避免在脚本中存储明文密码
   • 考虑使用密码哈希直接配置

3. 域名规划：

   • 邮件服务域名与主机域名分开
   • 例如：MX 记录指向 mail.example.com，用户使用 [e-mail]

4. 监控配置：

   • 确保系统邮件能被适当转发
   • 监控 /var/mail 下的系统邮件

通过理解 Docker-Mailserver 的这些核心机制，开发者可以构建出更稳定可靠的邮件服务解决方案，避免常见的配置陷阱和服务启动问题。