RFC 2142《通用服务与角色邮箱名约定》中文译本

IETF · RFC 2142 · 标准跟踪（Standards Track）· 1997 年 5 月

文档状态（Status of this Memo）

本文档规定了面向互联网社区的互联网标准跟踪协议，并请求进行讨论及提出改进建议。有关本协议的标准化状态与现状，请参阅“互联网官方协议标准”（STD 1）的当前版本。本备忘录的分发不受限制。

摘要（ABSTRACT）

本规范列举并描述了在联系某组织内部人员时所应使用的互联网邮件地址（邮箱名 @ 主机引用）。其中既提供了面向运营职能的邮箱名，也提供了面向业务职能的邮箱名。本规范并不禁止增设其他邮箱名或别名，但对于那些与互联网进行邮件往来的组织，鼓励其至少支持本组织内存在相应职能的每个邮箱名。

1. 制定理由与范围（RATIONALE AND SCOPE）

各类互联网文档曾规定过用于联系某项服务运营者的邮箱名；例如，[RFC822 6.3, C.6] 要求所有拥有 SMTP 服务器的主机都必须存在 这个邮箱名。其他协议对知名邮箱名也有事实上的标准，例如 NNTP 的 （见 [RFC977]），以及 HTTP 的 （见 [HTTP]）。对于与特定协议无关、却广为人知的邮箱名，同样存在事实上的标准，例如 与 。

本备忘录旨在汇总并规定组织需要支持的一组基本邮箱名。大多数组织无需支持此处定义的全部邮箱名，因为并非每个组织都会实现所有相关服务。但是，若某组织提供了某项服务，则必须（MUST）支持与之关联的邮箱名，从而使邮件能够投递给适合该被引用服务或角色的收件人。

若某主机未配置为直接接收邮件，但它实现了本规范为其定义了邮箱名的某项服务，那么该主机必须具有一组 MX 资源记录（RR）（见 [RFC974]），且由该 RR 集指定的邮件交换器必须将该被引用主机的域名视为“本地”，以接收发往所定义邮箱名的邮件。需要注意，即便所通告的域名与该主机的域名并不相同，此规则同样成立；例如，若某 NNTP 服务器的主机名为 DATA.RAMONA.VIX.COM，但它在 “Path:” 信头中通告的域名为 VIX.COM，那么邮件必须可投递至 与 ，即便这些地址可能被投递到不同的最终目的地。

知名邮箱名的作用范围是其所处的域名。代表某域名接收邮件的服务器，必须接收并正确处理该域名的邮箱名，即便该服务器自身并不支持相关服务。因此举例来说，若某 NNTP 服务器在 “Path:” 信头中通告了该组织的最顶层域名（见 [RFC977]），那么该最顶层域名的邮件交换器必须接收发往 的邮件，即便这些邮件交换器主机自身并不提供 NNTP 协议服务。

2. 不变式（INVARIANTS）

对于与特定协议无关的知名名字，仅要求组织的最顶层域名有效即可。例如，若某互联网服务提供商的域名为 COMPANY.COM，那么 这个地址必须有效且被支持，即便那些产生投诉的活动来自使用更具体域名（如 SHELL1.COMPANY.COM）的主机的客户。不过请注意，支持子域的邮箱名也是有效且受鼓励的做法（在适当情况下）。

邮箱名的识别必须（MUST）与字符大小写无关。例如，POSTMASTER、postmaster、Postmaster、PostMaster，乃至 PoStMaStEr 都应被同等对待，并投递到同一邮箱。

这些知名名字的实现需要考虑到使用它们的发件人的预期。自动回送邮件确认通常是有帮助的（不过我们建议警惕“邮件机器人对战”及由此产生的邮件循环的可能性）。

3. 业务相关邮箱名（BUSINESS-RELATED MAILBOX NAMES）

这些名字与组织的业务活动相关。INFO 名字通常与自动应答器绑定，可提供一系列标准文件。

邮箱名	适用服务	用途说明
INFO	Marketing	关于组织、产品和/或服务（视情况而定）的打包信息
MARKETING	Marketing	产品营销与营销沟通
SALES	Sales	产品采购信息
SUPPORT	Customer Service	产品或服务相关问题

4. 网络运营邮箱名（NETWORK OPERATIONS MAILBOX NAMES）

运营类地址旨在为正在遭遇该组织互联网服务困难的客户、提供商及其他方面提供求助渠道。

邮箱名	适用服务	用途说明
ABUSE	Customer Relations	不当的公开行为
NOC	Network Operations	网络基础设施
SECURITY	Network Security	安全公告或咨询

5. 特定互联网服务的支持邮箱名（SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES）

对于主要的互联网协议服务，都定义了一个用于接收咨询与报告的邮箱。（由于这些同义词拥有广泛的既有部署基础，此处一并列出。）

邮箱名	适用服务	用途说明
POSTMASTER	SMTP	[RFC821], [RFC822]
HOSTMASTER	DNS	[RFC1033-RFC1035]
USENET	NNTP	[RFC977]
NEWS	NNTP	USENET 的同义词
WEBMASTER	HTTP	[RFC 2068]
WWW	HTTP	WEBMASTER 的同义词
UUCP	UUCP	[RFC976]
FTP	FTP	[RFC959]

6. 邮件列表管理邮箱（MAILING LIST ADMINISTRATION MAILBOX）

邮件列表拥有一个管理邮箱名，可向其发送订阅/退订请求及其他元级查询。

对于投递邮箱名为以下形式的邮件列表：

<LIST@DOMAIN>

必须（MUST）存在如下管理邮箱名：

<LIST-REQUEST@DOMAIN>

像 MajorDomo（MAJORDOMO）和 Listserv（LISTSERV）这样的分发列表管理软件，在该系统上还拥有一个与该软件本身（而非该系统上某个特定列表）相关联的单一邮箱名——通常使用软件名称作为该邮箱名。使用这类邮箱名要求参与者了解该站点所采用的列表软件类型，这会带来问题。因此：

无论是否存在通用的列表软件邮箱名，都必须（MUST）提供列表专用的（-REQUEST）邮箱名。

7. 域名服务管理邮箱（DOMAIN NAME SERVICE ADMINISTRATION MAILBOX）

在 DNS（见 [RFC1033]、[RFC1034] 与 [RFC1035]）中，起始授权机构记录（SOA RR）含有一个用于指定该区域管理员邮箱名的字段。

该字段必须（MUST）是一个不含元字符（如 “%”、“!” 或 “::”）的单纯单词，并且应在相关的邮件交换器主机上设置邮件别名，以将区域管理邮件导向合适的邮箱。

为求简洁与规范，强烈建议始终使用知名邮箱名 HOSTMASTER，即 。

8. 自治系统邮箱（AUTONOMOUS SYSTEM MAILBOX）

若干互联网注册机构为自治系统联系人实现了邮件列表。因此举例来说，在撰写本文时，发往 的邮件将能联系到自治系统 3557 在 BGP4（见 [RFC1654]、[RFC1655] 与 [RFC1656]）中的技术联系人。

然而，并非所有自治系统都已在所有注册机构处登记，因此在该方案下无法投递的邮箱名应被视为一种不便，而非错误或违反标准的行为。

9. 安全考虑（SECURITY CONSIDERATIONS）

拒绝服务攻击（向某邮箱大量灌入垃圾邮件）在本文档成为标准后将更加容易得逞，因为会有更多系统支持同一组邮箱名。

10. 参考文献（REFERENCES）

[RFC821] Postel, J., “Simple Mail Transfer Protocol”, STD 10, RFC 821, Information Sciences Institute, 1982 年 8 月。

[RFC822] Crocker, D., “Standard for the format of ARPA Internet text messages”, STD 11, RFC 822, University of Delaware, 1982 年 8 月。

[RFC959] Postel, J., and J. Reynolds, “File Transfer Protocol (FTP)”, STD 9, RFC 959, Information Sciences Institute, 1985 年 10 月。

[RFC974] Partridge, C., “Mail routing and the domain system”, STD 14, RFC 974, CSNET CIC BBN Laboratories Inc, 1986 年 1 月。

[RFC976] Horton, M., “UUCP mail interchange format standard”, RFC 976, Bell Laboratories, 1986 年 2 月。

[RFC977] Kantor, B., et al, “Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News”, RFC 977, University of California, 1986 年 2 月。

[RFC1033] Lottor, M., “Domain administrators operations guide”, RFC 1033, SRI International, 1987 年 11 月。

[RFC1034] Mockapetris, P., “Domain names - concepts and facilities”, STD 13, RFC 1035, USC/Information Sciences Institute, 1987 年 11 月。

[RFC1035] Mockapetris, P., “Domain Names - Implementation and Specification” STD 13, RFC 1035, USC/Information Sciences Institute, 1987 年 11 月。

[RFC1654] Rekhter, Y., et al, “A Border Gateway Protocol 4 (BGP-4)”, RFC 1654, T.J. Watson Research Center, IBM Corp., 1994 年 7 月。

[RFC1655] Rekhter, Y., et al, “Application of the Border Gateway Protocol in the Internet”, RFC 1655, T.J. Watson Research Center, IBM Corp., 1994 年 7 月。

[RFC1656] Traina, P., “BGP-4 Protocol Document Roadmap and Implementation Experience”, RFC 1656, cisco Systems, 1994 年 7 月。

[HTTP] Berners-Lee, T., et al, “Hypertext Transfer Protocol -- HTTP/1.0”, RFC 1945, 1996 年 5 月。

11. 致谢（ACKNOWLEDGEMENTS）

本规范源自 Paul Vixie 撰写的一份早期草案。感谢 Stan Barber、Michael Dillon、James Aldridge、J. D. Falk、Peter Kaminski、Brett Watson、Russ Wright、Neal McBurnett 以及 Ed Morin 对该草案提出的意见。

12. 作者地址（AUTHOR'S ADDRESS）

Dave Crocker
Internet Mail Consortium
127 Segre Ave.
Santa Cruz, CA

电话：+1 408 246 8253
电子邮件：dcrocker@imc.org