一、背景说明
在一套基于 Docker Compose 运行的 mailcow 邮件系统中，随着服务组件逐渐增多，内存占用开始成为需要关注的资源项。系统主要用于低频、自用场景，不存在大规模外部用户或高并发邮件流量。
在对整体容器资源使用情况进行评估后，发现部分组件在当前使用场景下性价比偏低，有进一步精简的空间。
二、资源使用情况初步分析
通过 docker stats 对运行中的容器进行统计，可以观察到以下特点：
- 核心邮件组件（Postfix、Dovecot、Rspamd、Redis、MySQL）内存占用较低，运行状态稳定
- ClamAV（clamd）与 OnlyOffice 属于内存占用明显偏高的服务
- ClamAV 常驻内存超过 1 GiB
- OnlyOffice 常驻内存超过 1 GiB
- 在邮件量较低、附件来源可控的情况下，这两者对系统安全性与可用性的实际提升有限
基于上述观察，决定对这两个组件进行停用验证。
三、停用 OnlyOffice 的处理结果
OnlyOffice 作为独立服务容器，在停止后：
- 容器不再出现在运行列表中
- 系统整体内存占用立即下降约 1 GiB
- mailcow 及其他服务未受到任何影响
该结果符合预期，表明 OnlyOffice 与核心邮件链路无强依赖关系，适合在不需要在线文档协作的场景下停用。
四、ClamAV 的停用方式与验证
4.1 配置层面的停用方式
mailcow 并不推荐直接修改 docker-compose.yml 或手动删除 service，而是通过配置变量控制组件启停。
在配置文件中设置：
SKIP_CLAMD=y
该变量用于告知 mailcow 在启动阶段跳过 ClamAV 相关逻辑。
4.2 实际运行行为观察
停用后仍可在容器列表中看到 clamd 容器，但其行为发生了明显变化：
- 内存占用降至不足 1 MiB
- 容器日志中明确输出：
SKIP_CLAMD=y, skipping ClamAV...
这表明：
- 容器本身仍作为占位存在
- ClamAV 服务本体未启动
- 病毒库更新与附件扫描逻辑均被跳过
从功能和资源角度看，ClamAV 已处于“逻辑完全禁用”状态。
五、停用后的整体状态评估
在 ClamAV 与 OnlyOffice 停用后，系统呈现出以下特征：
- 邮件系统内存占用显著降低
- 关键服务运行负载稳定
- watchdog、rspamd 等辅助组件工作正常
- 未观察到异常 CPU、PIDS 或 I/O 行为
对于低频、自用邮件系统而言，该配置状态更加贴近“最小可维护集”。
六、关于安全性的取舍说明
停用 ClamAV 后，系统将不再对邮件附件进行服务器端病毒扫描。但在以下前提条件成立的情况下，该取舍是可控的：
- 邮件使用者数量极少
- 邮件来源相对可信
- 服务器本身不执行附件内容
- 客户端侧仍具备基础安全防护
在不涉及合规要求或公共服务的前提下，该调整更偏向于资源优化，而非安全降级。
七、结论
- OnlyOffice 可作为非核心组件直接停用
- ClamAV 应通过官方配置变量进行停用，而非手动修改 Compose 文件
- 在低负载、自用场景下，mailcow 可稳定运行于一个更精简的组件集合中
- 通过定期检查容器资源使用情况，有助于及时识别“性价比偏低”的服务组件
该实践为后续进一步精简邮件系统、降低维护成本提供了可参考的配置方向。