Keep case and domain scope separate
02Capitalization 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.
The same ABUSE role at picnic.example and other.example leads to their separate, illustrative contacts.
Key idea: Case variants of a well-known name reach the same mailbox; the domain still matters.
Terms
- Case independent
- Uppercase and lowercase letters do not distinguish this role name.
- Principal domain
- The organization’s main domain for the non-protocol-specific role in this example.
Rules & examples
Case variants of a well-known name reach the same mailbox; the domain still matters.
- RFC2142§2 requires case-independent recognition of these well-known names, with delivery to the same mailbox. SUPPORT and SuPpOrT at picnic.example are equivalent role names.
- This is not a rule to lowercase every arbitrary SMTP local part. Current RFC5321§2.4 preserves local-part case in general; §4.5.1 separately requires case-insensitive postmaster for servers supporting relaying/delivery, with the stated always-554 exception.
- For non-protocol-specific roles, the requirement is at the organization’s principal domain, not at every customer host. Supporting suitable subdomain aliases is valid and encouraged, not universally required.
- The RFC’s phrase “top level domain” refers to the organization’s domain in context, not the public suffix alone. Held editorial1764 records the principal-domain clarification; it is not marked Verified.
- ABUSE@picnic.example and ABUSE@other.example belong to different domains. A role name is not a globally shared mailbox.
Case examples use the fifteen fixed role names from §§3–5 only. Arbitrary personal and list mailbox names are not normalized by this teaching helper. Principal-domain examples do not infer registrable domains from a public-suffix algorithm.
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.