RFC 2142 / START HERE
Role mailboxes, before the details
Mailbox Names for Common Services, Roles and Functions: a descriptive title, not an acronym
Organizations need stable email contacts for functions such as support, network operations and DNS administration. A role mailbox names that function rather than an employee. RFC2142 collects the common names and explains where they must work.
Why it exists
A familiar name alone is insufficient: the destination domain and mail exchanger must accept it. This guide separates required list-specific administrative addresses from the recommended HOSTMASTER spelling and optional historical registry aliases. It does not define a new mail transport or prove who sent a message.
A familiar example
A fictional FTP host files.picnic.example does not receive SMTP directly. Its MX points to inbox.picnic.example, which accepts ftp@files.picnic.example and forwards it to the chosen FTP operators. The exchanger need not run FTP.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Choose the contact for the roleA role mailbox reaches a function at an organization, rather than naming a particular employee. The local part is the name before @; the domain identifies the organization or service whose mail is being addressed.→
- Keep case and domain scope separateCapitalization must not change which well-known role mailbox is selected. Domain scope is a separate question: an identical name at another organization is a different contact.→
- Route service mail through its exchangerA service host can offer FTP without listening for SMTP mail itself. It still needs a mail route for its defined role address. An MX record names the mail exchanger that accepts mail on its behalf.→
- Separate list posts from administrationMessages submitted to a mailing list and requests to administer it have different destinations. A list-specific -request address remains necessary even if the site also offers a generic software controller.→
- Connect the SOA contact to an aliasA DNS zone’s SOA record contains RNAME, a DNS-name representation of its administrator’s mailbox. A stable alias can route this mail to whichever team is responsible.→
- Recognize the limits of predictable namesA well-known contact name is useful, but not every apparent address is universally required or authentic. Historical registry contact conventions and security risks have explicit limits.→
This introduction explains RFC 2142 (1997). Read the original RFC ↗