Recognize the limits of predictable names
06A 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.
Predictable addresses can attract floods of junk. Automated replies can also loop; this RFC supplies no guaranteed protection or required auto-reply.
Key idea: A missing optional registry alias is not a standards violation, and a role name is not an identity proof.
Terms
- Autonomous System
- A network or group of networks under a common routing administration.
- Documentation ASN
- A number reserved for examples rather than an actual operator in this demonstration.
Rules & examples
A missing optional registry alias is not a standards violation, and a role name is not an identity proof.
- RFC2142§8 describes some registries’ AS-number contact aliases. It does not require every registry to cover every Autonomous System. An undeliverable address under that scheme is an inconvenience, not a standards violation.
- AS64496@registry.example is a fictional configured entry using a documentation ASN from RFC5398§4. It is not a real registry lookup or a universal routing rule. other.example is a separate fictional registry with no such entry.
- The naming scheme provides no cryptographic sender identity. A familiar From address is not proof of authorship; see SMTP security and spoofing in RFC5321§7.1.
- RFC2142§9 warns that predictable role addresses make mailbox flooding easier. The illustration shows that risk; it does not claim the RFC defines a spam filter or queue limit.
- Automatic acknowledgements may be useful, but §2 cautions about duelling mail robots and loops. The guide does not require automatic replies or send any test mail.
Historical examples are labeled as such. Documentation-only ASN choices are an intentional QA-data restriction, not a new Internet numbering rule. No role-address existence, sender identity, inbox capacity or reply is promised by spelling alone.
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.