Choose the contact for the role
01A 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.
These names cover SMTP, DNS, NNTP, HTTP, UUCP and FTP contacts. Synonyms do not create new protocols or prove cited older protocol texts mandated an address.
Key idea: Support the applicable role names; not every organization needs every listed function.
Terms
- Role mailbox
- An address for a function, such as customer support.
- Local part
- The name before @; its meaning belongs to the destination domain.
- Alias
- A configured name that directs mail to a chosen recipient.
Rules & examples
Support the applicable role names; not every organization needs every listed function.
- RFC2142§1 says the associated names must be supported when the corresponding service is offered, with delivery to an appropriate recipient. It does not require every organization to offer every function.
- Business names (§3): INFO for packaged information, MARKETING for marketing communications, SALES for purchase information, SUPPORT for product/service problems.
- Operations names (§4): ABUSE for inappropriate public behaviour, NOC for network infrastructure, SECURITY for security bulletins or queries.
- The published service table (§5) lists POSTMASTER/SMTP, HOSTMASTER/DNS, USENET and NEWS/NNTP, WEBMASTER and WWW/HTTP, UUCP/UUCP and FTP/FTP. NEWS and WWW are listed synonyms.
- The drawings show contact-address selection, not protocol commands, automatic complaint classification or a requirement for everyone to run all these services.
Reported technical erratum8692 disputes the HTTP citations behind WEBMASTER/WWW; it is not Verified. The guide describes RFC2142’s own published table, not a mandate derived from HTTP request headers. Held editorial1082 concerns NNTP references; it is not an approved alias substitution.
Sources
New to this? Start hereA quick picture + helpful background
Address the function, then route its mail
Imagine addressing a department rather than one employee. The department label stays stable while its internal recipient can change. The destination domain and its mail exchanger still have to recognize that label; a familiar name is not proof of the sender’s identity.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.