RFC 3834《自动电子邮件响应》中文导读
非官方中文导读声明：本页为 IETF RFC 3834《Recommendations for Automatic Responses to Electronic Mail》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc3834.txt。
1. 自动回复为什么需要规范
离开办公室自动回复、邮件列表的订阅确认、服务器的投递失败通知……自动邮件响应无处不在。但若实现不当，会带来两个经典灾难：回环（A 的自动回复触发 B 的自动回复，无限往复）与噪声轰炸（对每一封批量邮件都自动回信）。
RFC 3834 因此给出一套建议，目的是让自动响应既服务于用户，又不污染邮件生态。它属于标准跟踪，但措辞多为“应当/不应当”的建议性规范。
2. 三类响应者
文档把自动响应软件分为三类，并分别给出行为约束：
- 服务类响应者（Service Responder）：代表邮件系统自身运作，如投递失败通知、邮件列表管理回应。这类响应是系统行为，通常不应被用户外出回复再转发。
- 个人类响应者（Personal Responder）：代表某个真实用户，如“我正在休假”外出回复。
- 群组类响应者（Group Responder）：代表一个团队或别名，如 support@ 的自动受理回执。
区分的意义在于：不同类别的响应，其目标收件人、是否应触发连锁响应、是否应附带原始信头，都有不同处置。
3. Auto-Submitted 头字段：回环的刹车
防止回环的关键机制是 Auto-Submitted 头字段。规范建议：任何由软件自动发出的邮件都应带上这个头字段，取值包括：
no：默认值，表示这是人发的、非自动邮件；auto-generated：完全由软件生成、不是对某封来信的回复（如系统通知）；auto-replied：是对某封来信的自动回复（如外出回复）。
响应者在决定是否回复一封来信时，应当检查来信的 Auto-Submitted：若来信本身已是 auto-replied 或 auto-generated，不得再自动回复，从而切断回环。这是避免“自动回复风暴”的核心规则。
4. 运输层响应用 DSN/MDN，而非普通回复
投递失败（bounce）、已读/已处理回执这类运输层的响应，规范明确建议走专门的机制，而不是发一封普通回复邮件：
- DSN（投递状态通知，RFC 3464）：用于报告投递成功/失败/延迟，由 MTA 生成；
- MDN（消息处置通知，RFC 3798）：用于报告收件人端对邮件的处置（显示、打印、删除等）。
原因是：普通回复邮件会进入用户的收件箱、可能再次触发对方自动回复，而 DSN/MDN 是协议级的、对会话透明的通知，不会引发回环，也不会被误当作一般来信。
5. 响应内容的约束
- 指向原发件人：自动回复应当发给原始邮件的 Return-Path（信封发件人），而不是信头 From 中可能被伪造的地址；
- 附带原始信头：响应中应包含原始邮件的关键信头（如 Message-ID、From、To、Subject、Date），便于收件人关联上下文；
- 主题与频率：建议响应主题能反映原主题，且对同一发件人在短时间内只回复一次，避免重复轰炸（个人外出回复尤其需要去重）。
文档还提醒：自动回复可能把“某人正在休假、何时回来”这类信息泄露给攻击者，因此在安全敏感场景下应谨慎决定回复内容的详细程度。
6. 邮件列表与转发的特殊处理
对邮件列表（Mediator）而言，列表服务器本身会改写信封与信头，列表成员收到的邮件其 Return-Path 常是列表服务器。若按“回复原信封发件人”规则，自动回复会回到列表——这通常正是期望的（由列表统一处理），但也可能造成列表回环。
规范因此建议：响应者在向列表地址发自动回复前，应先评估是否会触发列表的自动机制；对明显是列表流量的来信，个人响应者可以选择不回复，或只回复给人类可识别的、非角色账户的真实地址。
参考：https://www.rfc-editor.org/rfc/rfc3834.txt