Mailbox Names for Common Services, Roles and Functions
Extracted elements (19)
HOSTMASTER is strongly recommended for the DNS SOA zone administrator mailbox for simplicity and regularity; the SOA field must be a simple word without metacharacters, and a mail alias should be used on relevant mail exchangers to route zone administration mail to the appropriate destination.
LIST-specific -REQUEST mailbox names are mandated even when generic list-software mailbox names (e.g., 'majordomo') exist at the site, because relying on software-named mailboxes requires senders to know what list software is deployed, which is considered problematic.
The document aggregates previously scattered per-protocol mailbox name requirements (POSTMASTER from RFC 822, USENET from RFC 977, WEBMASTER from HTTP) together with defacto standards (ABUSE, TROUBLE) into a single specification, so organizations have one normative reference for the full required set.
The scope of a well-known mailbox name is the domain name level, not the host level; for non-protocol-specific names like ABUSE, only the organization's top-level domain name is required to be valid, though supporting sub-domain mailbox names is encouraged.
Implementations of well-known mailbox names should account for sender expectations; sending an automatic acknowledgement is usually helpful, but implementors should guard against 'duelling mail robots' and resulting mail loops.
When an NNTP (or other) server advertises a domain name different from its host name (e.g., DATA.RAMONA.VIX.COM advertising VIX.COM in Path headers), mail must be deliverable to the well-known mailbox at BOTH the advertised domain and the actual host domain, even if delivered to different final destinations.
For a mailing list whose submission mailbox name is LIST@DOMAIN, there MUST be an administrative mailbox name LIST-REQUEST@DOMAIN.
For simplicity and regularity, it is strongly RECOMMENDED that the well-known mailbox name HOSTMASTER always be used for the DNS SOA zone administrator field, i.e., HOSTMASTER@domain.
If a given service is offered by an organization, the associated mailbox name(s) defined in this specification MUST be supported, resulting in delivery to a recipient appropriate for the referenced service or role.
If a host is not configured to accept mail directly but implements a service for which this specification defines a mailbox name, that host MUST have an MX RR set, and the mail exchangers specified by this RR set must recognize the referenced host's domain name as 'local' for the purpose of accepting mail bound for the defined mailbox name.
List-specific -REQUEST mailbox names are REQUIRED independently of the availability of generic list-software mailbox names (such as those for MajorDomo or Listserv), because requiring participants to know the list software type is problematic.
Mailbox names defined in this specification must be recognized independent of character case; for example, POSTMASTER, postmaster, Postmaster, and PoStMaStEr must all be treated as the same address with delivery to the same mailbox.
Servers accepting mail on behalf of a domain must accept and correctly process well-known mailbox names for that domain, even if the server itself does not support the associated service (e.g., mail exchangers for a domain must accept USENET@domain even if they don't run NNTP).
Autonomous System mailbox names take the form AS<number>@<registry-domain> (e.g., [email protected]), used by Internet registries to provide mailing lists for AS technical contacts. Undeliverable names under this scheme should be treated as an inconvenience rather than a standards violation.
Eight service-specific mailbox names are defined: POSTMASTER (SMTP), HOSTMASTER (DNS), USENET and NEWS (NNTP synonyms), WEBMASTER and WWW (HTTP synonyms), UUCP (UUCP), and FTP (FTP).
Four business-related mailbox names are defined: INFO (packaged information about the organization), MARKETING (product marketing), SALES (product purchase information), and SUPPORT (customer service for problems with products or services).
Mailing list administrative mailbox names follow the pattern LIST-REQUEST@DOMAIN, where LIST@DOMAIN is the submission address; this provides a consistent mechanism for add/drop requests and other meta-queries independent of list software.
Three network operations mailbox names are defined: ABUSE (inappropriate public behavior/complaints), NOC (network infrastructure operations), and SECURITY (security bulletins or queries).
Denial-of-service attacks (flooding a mailbox with junk) will be easier after this document becomes a standard, since more systems will support the same predictable set of mailbox names.