RFC 2142

Mailbox Names for Common Services, Roles and Functions

📅 published May 1997, from ietf

RFC 2142: MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS 🎀

Network Working Group 🌸 this one is from the Network Working Group. Request for Comments: 2142 ✨ Category: Standards Track 🔥 it's an actual standards-track spec, not a sidenote Date: May 1997 📅 Author: D. Crocker, Internet Mail Consortium 💜 Obsoletes / Updates: this document doesn't list anything it obsoletes or updates 🦋

Status of this Memo 📣

okay bestie, so this is an Internet standards track protocol for the whole Internet community, and it's basically asking everyone for discussion and suggestions 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) doc. Distribution of this memo is unlimited, so share it with everyone 💅

ABSTRACT 🦋

this spec lists and explains the Internet mail addresses (a mailbox name @ host) you'd use to contact people at an organization 💌 It covers mailboxes for both operations and business functions. Extra mailbox names and aliases are totally allowed, but orgs that do email with the Internet are encouraged to support AT LEAST every mailbox name for which the matching function exists inside the organization ✨

1. RATIONALE AND SCOPE 💅

so a bunch of Internet docs already name mailboxes for reaching the operators of a service 👀 For example, [RFC822 6.3, C.6] requires a <POSTMASTER@domain> mailbox on every host that has an SMTP server 📮 Other protocols have de facto well-known mailboxes too, like <USENET@domain> for NNTP (see [RFC977]) and <WEBMASTER@domain> for HTTP (see [HTTP]). Some well-known names have nothing to do with any single protocol, like <ABUSE@domain> and <TROUBLE@domain> 🍓

The whole point of this memo is to gather up and specify the basic set of mailbox names that orgs need to support 🧚 Most orgs won't need the full list, since not every org runs every service. BUT if a service is offered, then its associated mailbox name(es) must be supported, and mail to them must get delivered to someone who's appropriate for that service or role 🫶

If a host doesn't accept mail directly, but it does run a service this spec gives a mailbox name to, then that host must have an MX RR set (see [RFC974]). The mail exchangers in that RR set must treat the host's domain name as "local" so they can accept mail for the defined mailbox name 💖 This is true even when the domain the service advertises is different from the host's own domain name. Like, if an NNTP server's host name is DATA.RAMONA.VIX.COM but it advertises VIX.COM in its "Path:" headers, then mail must be deliverable to both <USENET@VIX.COM> and <USENET@DATA.RAMONA.VIX.COM>, even if those two addresses end up going to different final destinations 🌈

The scope of a well-known mailbox name is its domain name 🔥 Servers that accept mail for a domain must accept and correctly process mailbox names for that domain, even if the server itself doesn't run the associated service 🙈 So, for example, if an NNTP server advertises the org's top-level domain in "Path:" headers (see [RFC977]), then the mail exchangers for that top-level domain must accept mail to <USENET@domain> even if those exchanger hosts don't serve NNTP themselves 👑

2. INVARIANTS 👑

for well-known names that aren't tied to a specific protocol, only the org's top-level domain name is required to be valid 🫶 Say an ISP's domain is COMPANY.COM. Then <ABUSE@COMPANY.COM> must be valid and supported, even though the customers making the complaints use hosts with more specific names like SHELL1.COMPANY.COM 💅 Note that supporting mailbox names for sub-domains is valid and encouraged too, where it makes sense ✨

Mailbox names must be recognized regardless of character case 🌸 So POSTMASTER, postmaster, Postmaster, PostMaster, and even PoStMaStEr all get treated the same and delivered to the same mailbox 😭

Implementations of these well-known names need to think about what the senders using them expect 💖 Sending back an automatic acknowledgement is usually helpful, though we do suggest caution about "duelling mail robots" and the mail loops they can cause 🤖

these names are about an org's line-of-business activities 💼 The INFO name is often hooked up to an autoresponder with a range of standard files available 📬

MAILBOX        AREA                USAGE
-----------    ----------------    ---------------------------
INFO           Marketing           Packaged information about the
                                   organization, products, and/or
                                   services, as appropriate
MARKETING      Marketing           Product marketing and
                                   marketing communications
SALES          Sales               Product purchase information
SUPPORT        Customer Service    Problems with product or
                                   service

4. NETWORK OPERATIONS MAILBOX NAMES 🛠️

operations addresses exist so customers, providers, and others who are having trouble with the org's Internet service have somewhere to turn 🆘

MAILBOX        AREA                USAGE
-----------    ----------------    ---------------------------
ABUSE          Customer Relations  Inappropriate public behaviour
NOC            Network Operations  Network infrastructure
SECURITY       Network Security    Security bulletins or queries

5. SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES 🧠

for the major Internet protocol services, there's a mailbox set up for receiving queries and reports 📥 (Synonyms are listed here too, because they have a huge installed base 🦋)

MAILBOX        SERVICE             SPECIFICATIONS
-----------    ----------------    ---------------------------
POSTMASTER     SMTP                [RFC821], [RFC822]
HOSTMASTER     DNS                 [RFC1033-RFC1035]
USENET         NNTP                [RFC977]
NEWS           NNTP                Synonym for USENET
WEBMASTER      HTTP                [RFC 2068]
WWW            HTTP                Synonym for WEBMASTER
UUCP           UUCP                [RFC976]
FTP            FTP                 [RFC959]

6. MAILING LIST ADMINISTRATION MAILBOX 📋

mailing lists need an administrative mailbox where add/drop requests and other meta-queries can go 💌

for a mailing list whose submission mailbox name is:

<LIST@DOMAIN>

there MUST be the administrative mailbox name:

<LIST-REQUEST@DOMAIN>

🚨 this part is serious: LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED, INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE MAILBOX NAMES. 🚨

list management software like MajorDomo and Listserv also has a single mailbox name tied to the software on that system (usually just the software's name), instead of one for each particular list 🤔 But using those names means participants have to know which type of list software a site runs, and that's problematic 😬 That's why the list-specific names above are required no matter what generic list software names exist 💖

7. DOMAIN NAME SERVICE ADMINISTRATION MAILBOX 🌐

in DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of Authority record (SOA RR) has a field for the mailbox name of the zone's administrator 📜

this field must be a simple word with no metacharacters (things like "%", "!" or "::"), and a mail alias should be set up on the relevant mail exchanger hosts to send zone administration mail to the right mailbox 🧚

for simplicity and regularity, it is strongly recommended that the well-known mailbox name HOSTMASTER always be used: <HOSTMASTER@domain> 🍓

8. AUTONOMOUS SYSTEM MAILBOX 🛰️

several Internet registries run mailing lists for Autonomous System contacts 📡 For example, mail sent to <AS3557@RA.NET> will, at the time of this writing, reach the technical contact for Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and [RFC1656]) 🌈

not every Autonomous System is registered with every registry, though, so undeliverable mailbox names under this scheme should be treated as an inconvenience, not as an error or a standards violation 🫠

9. SECURITY CONSIDERATIONS 🚨

💀 heads up, this one's a real concern: denial of service attacks (flooding a mailbox with junk) will get easier once this document becomes a standard, because more systems will support the same set of mailbox names. 💀

10. REFERENCES 📚

[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, Information Sciences Institute, August 1982.

[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, University of Delaware, August 1982.

[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, Information Sciences Institute, October 1985.

[RFC974] Partridge, C., "Mail routing and the domain system", STD 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.

[RFC976] Horton, M., "UUCP mail interchange format standard", RFC 976, Bell Laboratories, February 1986.

[RFC977] Kantor, B., et al, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, University of California, February 1986.

[RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, SRI International, November 1987.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification" STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1654, T.J. Watson Research Center, IBM Corp., July 1994.

[RFC1655] Rekhter, Y., et al, "Application of the Border Gateway Protocol in the Internet", RFC 1655, T.J. Watson Research Center, IBM Corp., July 1994.

[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, cisco Systems, July 1994.

[HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

11. ACKNOWLEDGEMENTS 🫶

this spec came from an earlier draft written by Paul Vixie 💜 Big thanks to Stan Barber, Michael Dillon, James Aldridge, J. D. Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and Ed Morin for their comments on that draft 🌷

12. AUTHOR'S ADDRESS 📮

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

Phone: +1 408 246 8253
EMail: dcrocker@imc.org

that's the whole RFC, bestie! 🌈💅✨

📦 where this page comes from