Standards, Environments, and Macros addresses(5) NNNNAAAAMMMMEEEE addresses - formats for Internet mail addresses IIIINNNNTTTTRRRROOOODDDDUUUUCCCCTTTTIIIIOOOONNNN A mmmmaaaaiiiillll aaaaddddddddrrrreeeessssssss is a string of characters containing @. Every mail address has a llllooooccccaaaallll ppppaaaarrrrtttt and a ddddoooommmmaaaaiiiinnnn ppppaaaarrrrtttt. The domain part is everything after the final @. The local part is everything before. For example, the mail addresses God@heaven.af.mil @heaven.af.mil @at@@heaven.af.mil all have domain part hhhheeeeaaaavvvveeeennnn....aaaaffff....mmmmiiiillll. The local parts are GGGGoooodddd, empty, and @@@@aaaatttt@@@@. Some domains have owners. It is up to the owner of hhhheeeeaaaavvvveeeennnn....aaaaffff....mmmmiiiillll to say how mail messages will be delivered to addresses with domain part hhhheeeeaaaavvvveeeennnn....aaaaffff....mmmmiiiillll. The domain part of an address is interpreted without regard to case, so God@heaven.af.mil God@HEAVEN.AF.MIL God@Heaven.AF.Mil all refer to the same domain. There is one exceptional address that does not contain an @: namely, the empty string. The empty string cannot be used as a recipient address. It can be used as a sender address so that the real sender doesn't receive bounces. QQQQMMMMAAAAIIIILLLL EEEEXXXXTTTTEEEENNNNSSSSIIIIOOOONNNNSSSS The qqqqmmmmaaaaiiiillll system allows several further types of addresses in mail envelopes. First, an envelope recipient address without an @ is inter- preted as being at _e_n_v_n_o_a_t_h_o_s_t. For example, if _e_n_v_n_o_a_t_h_o_s_t is hhhheeeeaaaavvvveeeennnn....aaaaffff....mmmmiiiillll, the address GGGGoooodddd will be rewritten as GGGGoooodddd@@@@hhhheeeeaaaavvvveeeennnn....aaaaffff....mmmmiiiillll. Second, the address ####@@@@[[[[]]]] is used as an envelope sender address for double bounces. Third, envelope sender addresses of the form _p_r_e@@@@_h_o_s_t----@@@@[[[[]]]] are used to support variable envelope return paths (VERPs). qqqqmmmmaaaaiiiillll----sssseeeennnndddd will rewrite _p_r_e@@@@_h_o_s_t----@@@@[[[[]]]] as _p_r_e_r_e_c_i_p====_d_o_m_a_i_n@@@@_h_o_s_t SunOS 5.11 Last change: 1 Standards, Environments, and Macros addresses(5) for deliveries to _r_e_c_i_p@@@@_d_o_m_a_i_n. Bounces directly from qqqqmmmmaaaaiiiillll----sssseeeennnndddd will come back to _p_r_e@@@@_h_o_s_t. CCCCHHHHOOOOOOOOSSSSIIIINNNNGGGG MMMMAAAAIIIILLLL AAAADDDDDDDDRRRREEEESSSSSSSSEEEESSSS Here are some suggestions on choosing mail addresses for the Internet. Do not use non-ASCII characters. Under RFC 822 and RFC 821, these characters cannot be used in mail headers or in SMTP commands. In practice, they are regularly corrupted. Do not use ASCII control characters. NUL is regularly cor- rupted. CR and LF cannot be used in some combinations and are corrupted in all. None of these characters are usable on business cards. Avoid spaces and the characters \"<>()[],;: These all require quoting in mail headers and in SMTP. Many existing mail programs do not handle quoting properly. Do not use @ in a local part. @ requires quoting in mail headers and in SMTP. Many programs incorrectly look for the first @, rather than the last @, to find the domain part of an address. In a local part, do not use two consecutive dots, a dot at the beginning, or a dot at the end. Any of these would require quoting in mail headers. Do not use an empty local part; it cannot appear in SMTP commands. Avoid local parts longer than 64 characters. Be wary of uppercase letters in local parts. Some mail pro- grams (and users!) will incorrectly convert GGGGoooodddd@@@@hhhheeeeaaaavvvveeeennnn....aaaaffff....mmmmiiiillll to ggggoooodddd@@@@hhhheeeeaaaavvvveeeennnn....aaaaffff....mmmmiiiillll. Be wary of the following characters: $&!#~`'^*|{} Some users will not know how to feed these characters safely to their mail programs. In domain names, stick to letters, digits, dash, and dot. One popular DNS resolver has, under the banner of security, recently begun destroying domain names that contain certain other characters, including underscore. Exception: A SunOS 5.11 Last change: 2 Standards, Environments, and Macros addresses(5) dotted-decimal IP address in brackets, such as [[[[111122227777....0000....0000....1111]]]], identifies a domain owned by whoever owns the host at that IP address, and can be used safely. In a domain name, do not use two consecutive dots, a dot at the beginning, or a dot at the end. This means that, when a domain name is broken down into components separated by dots, there are no empty components. Always use at least one dot in a domain name. If you own the mmmmiiiillll domain, don't bother using the address rrrrooooooootttt@@@@mmmmiiiillll; most users will be unable to send messages to that address. Same for the root domain. Avoid domain names longer than 64 characters. EEEENNNNCCCCOOOODDDDEEEEDDDD AAAADDDDDDDDRRRREEEESSSSSSSSEEEESSSS IIIINNNN SSSSMMMMTTTTPPPP CCCCOOOOMMMMMMMMAAAANNNNDDDDSSSS RFC 821 defines an encoding of mail addresses in SMTP. For example, the addresses God@heaven.af.mil a"quote@heaven.af.mil The Almighty.One@heaven.af.mil could be encoded in RCPT commands as RCPT TO: RCPT TO: RCPT TO: There are several restrictions in RFC 821 on the mail addresses that can be used over SMTP. Non-ASCII characters are prohibited. The local part must not be empty. The domain part must be a sequence of elements separated by dots, where each element is either a component, a sequence of digits preceded by #, or a dotted-decimal IP address sur- rounded by brackets. The only allowable characters in com- ponents are letters, digits, and dashes. Every component must (believe it or not) have at least three characters; the first character must be a letter; the last character must not be a hyphen. EEEENNNNCCCCOOOODDDDEEEEDDDD AAAADDDDDDDDRRRREEEESSSSSSSSEEEESSSS IIIINNNN MMMMAAAAIIIILLLL HHHHEEEEAAAADDDDEEEERRRRSSSS RFC 822 defines an encoding of mail addresses in certain header fields in a mail message. For example, the addresses God@heaven.af.mil a"quote@heaven.af.mil The Almighty.One@heaven.af.mil could be encoded in a TTTToooo field as SunOS 5.11 Last change: 3 Standards, Environments, and Macros addresses(5) To: God@heaven.af.mil, <@brl.mil:"a\"quote"@heaven.af.mil>, "The Almighty".One@heaven.af.mil or perhaps To: < "God"@heaven .af.mil>, "a\"quote" (Who?) @ heaven . af. mil , God<"The Almighty.One"@heaven.af.mil> There are several restrictions on the mail addresses that can be used in these header fields. Non-ASCII characters are prohibited. The domain part must be a sequence of ele- ments separated by dots, where each element either (1) begins with [ and ends with ] or (2) is a nonempty string of printable ASCII characters not including any of \".<>()[],;: and not including space. SSSSEEEEEEEE AAAALLLLSSSSOOOO envelopes(5), qmail-header(5), qmail-inject(8), qmail- remote(8), qmail-smtpd(8) SunOS 5.11 Last change: 4