postmaster 和 abuse 邮箱必须要有吗？没有会带来什么后果？

角色邮箱常被当作「老派惯例」而在新建域名时被跳过，这是一个代价被严重低估的决定。RFC 2142 是 Standards Track 文档，它对这些名字提出的是规范性要求。

RFC 2142 §2 给出了三条不变量，每一条都有直接的运维含义：

• 顶级域必须有效。对于与具体协议无关的知名名字，只要求组织的顶级域名下有效。规范以 abuse 为例说明：若某互联网服务提供方的域名是某个组织域，则该域下的 abuse 地址必须有效且被支持，即便产生投诉的客户使用的是更具体的子域主机名。规范同时鼓励在适当情况下为子域也支持这些邮箱名。
• 识别必须不区分大小写。规范明确要求各种大小写写法都应被同等对待并投递到同一个邮箱。这条常在自建别名映射时被忽略，结果是某些大小写写法的来信静默落空。
• 要考虑发信人的预期。规范指出，实现这些知名名字时需要顾及使用者的预期，并说明自动回执通常是有帮助的，但同时提醒警惕「机器人对轰」造成邮件环路。这一提醒与 RFC 3834 关于自动回复的建议方向一致。

RFC 2142 按类别列出了这些邮箱名。§4 网络运营类的三个与安全运营关系最直接：

• ABUSE（客户关系）：用于不当的公开行为相关事宜。这是外部举报滥用行为的标准入口。
• NOC（网络运营）：网络基础设施相关事宜。
• SECURITY（网络安全）：安全公告或安全问询。

§5 特定互联网服务的支持邮箱中，与邮件直接相关的是：

• POSTMASTER（SMTP）：邮件服务的标准联系入口。规范在引言中即提到，SMTP 相关规范要求域名下存在 postmaster 邮箱名。
• HOSTMASTER（DNS）、WEBMASTER（HTTP，WWW 为其同义名）等，各对应一类服务。

§3 还列出了业务相关的名字，如 INFO、SALES、SUPPORT 等，分别对应市场、销售与客户服务领域。

此外规范在邮件列表管理一节中强调：列表专属的 -REQUEST 邮箱名是必需的，与是否提供通用列表软件邮箱名无关。

把这些邮箱当作可选项，代价体现在几个具体的地方：

• 投递问题失去外部反馈通路。对方邮件管理员发现与你的域之间存在投递异常时，标准做法是发信到 postmaster。这个地址不可达，意味着你只能等到自家用户投诉才知道出了问题，而那通常已经晚了很久。
• 滥用举报无处投递。当你的域被冒用发信、或你的用户账号失陷向外发垃圾邮件时，外部的第一反应是发信到 abuse。收不到举报的直接后果是问题持续扩大，直到你的域被列入拦截名单——那时你才知道，但处置窗口已经错过。
• 影响信誉评估。是否提供可用的角色邮箱，是接收方评估一个发信域是否被规范运营的一项参考。
• 影响其他协议机制。RFC 7293 定义的 RRVS 机制在判定时会豁免 RFC 2142 所列的角色账号——因为角色邮箱按设计就会在人员之间流转。这说明角色邮箱在协议层面被当作一类有特殊语义的对象，其存在与否会影响其他机制的行为。
• 反馈回路无法建立。RFC 5965 定义的反馈报告格式依赖一个可靠的接收地址。缺少规范化的角色邮箱，反馈回路难以建立。

1. 先在组织的顶级域上把 postmaster 与 abuse 建起来。这是规范的最低要求，也是收益最高的一步。
2. 确认大小写不敏感。用不同大小写写法各发一封测试邮件，确认都能投进同一个邮箱。自建别名映射尤其要测，很多映射表是大小写敏感的。
3. 指向真人可及的处理队列。把角色邮箱接进工单系统或指定值班组，而不是指向一个无人查看的信箱。「地址存在但没人看」在效果上等同于不存在，而且更糟——它让对方以为已经通知到了。
4. 放宽这些地址上的过滤强度。滥用举报天然携带垃圾邮件样本、可疑附件与恶意链接。用常规过滤策略处理 abuse 信箱，必然把最重要的举报当垃圾拦掉。应为其单独设置策略，并在受控环境中查看。
5. 自动回执要谨慎。规范认可自动回执通常有帮助，但明确提醒了邮件环路风险。若启用，需遵循 RFC 3834 关于自动回复的建议，特别是对空信封发件人的处理与回复抑制。
6. 纳入事件响应流程。abuse 与 security 邮箱是外部报告的入口，应当明确接收后的分派、定级与响应时限。NIST SP 800-61 Rev. 3 提供了事件响应的框架性建议，可作为流程设计参考。
7. 为所有实际使用的域名都配置。包括子品牌域、营销活动域、以及承载发信的子域。被冒用的往往正是这些平时无人关注的域名。

这里存在一个需要辨析的取舍。收敛未使用域名的常见做法是声明该域不接收邮件，但这一做法与角色邮箱要求存在张力。

判断标准应当是这个域名是否会发信：

• 确实完全不用于邮件的域名（纯站点域、防御性注册的域、已下线业务的域），可以声明不接收邮件。它们不发信，也就不会产生需要外部反馈的场景。
• 任何会发出邮件的域名，都必须保留可达的 postmaster 与 abuse 接收能力。只发不收是一种危险的配置：你向外界发送邮件，却切断了外界告诉你「你发的邮件有问题」的唯一标准通路。

一个常见的自伤场景是：某域名仅用于发送系统通知，管理员认为「反正不用收信」而配置为不接收邮件，结果所有退信、投诉与外部告警都无处可去，投递问题彻底失去可观测性。发信域至少应保留 postmaster 与 abuse 的收件能力。