Address lists are the most painful part of 822. It would have been easy to encode each address as a quoted string, but the 822 format is vastly more complicated.
For example, here are six encoded box names, each representing the 8-byte string "John.Doe":
John.Doe "John".Doe John."Doe" "John"."Doe" "John.Doe" "\J\o\h\n\.\D\o\e"Beware that sendmail incorrectly distinguishes between these names.
822 says that an encoded box name must start with a word, alternate between words and dots, and end with a word. MH is unable to handle encoded box names with adjacent dots or ending with a dot. Such names nevertheless appear on occasion; I recommend that readers be prepared for any combination of dots.
For example, here are some encoded domain names:
heaven.af.mil [127.0.0.1]  [\.af.milThe last example represents the 10-byte string "[.af.mil". Beware that many mailers have trouble with domain literals. 822bis prohibits domain literals inside domain names except when the domain literal is the entire domain name.
822 says that an encoded domain name must start with a subdomain, alternate between subdomains and dots, and end with a subdomain. In practice, domain names sometimes show up ending with a dot; readers have to be prepared for this.
God@heaven.af.milis an encoded address, representing the 17-byte Internet mail address "God@heaven.af.mil"; and
"\"quote" . "and space" @ (dot).[\.yp. tois an encoded address, representing a 29-byte Internet mail address starting with a double quote.
Domain names must be fully qualified: e.g., heaven.af.mil, not just heaven. If a recipient sees a message from God@heaven, for example, how does he know that his reply should go to God@heaven.af.mil?
On the other hand, many MUAs let the user type unqualified domain names in outgoing messages. Many MUAs also support an extension to the syntax for encoded addresses in outgoing messages: they allow an encoded box name without an @ or a domain name, so users at heaven.af.mil can simply type God instead of God@heaven.af.mil. The MUA has to add a fully qualified domain name before it sends the message.
Encode the box part as a series of atoms and dots if
I also recommend against putting any spaces, tabs, or comments between the tokens in an encoded address; they are handled incorrectly by Pine, mm, and some versions of mailx. Put them before or after the address:
"\"quote.and space"@.[\.yp.to (Might work)And consider switching to an address that doesn't need any quoted strings or domain literals.
@heaven.af.mil,@uucp.localis a route.
Routes were discouraged in 822 and heavily discouraged in RFC 1123. Their function is actively subverted by most Internet mailers. Writers should not generate them. However, they still show up occasionally; readers have to be able to parse the route syntax.
<@gateway.af.mil:God@heaven.af.mil>is a bracketed address. The < and > are required; for example,
@proxy.research.att.com:God@heaven.af.mil (WRONG)is not a valid bracketed address.
I recommend against inserting spaces, tabs, or comments inside a bracketed address:
From: < email@example.com > (spotted in 1998)When Microsoft Outlook 8.5 sees this, it incorrectly includes the spaces in the address.
J. Q. Public822 does not allow dots or @s in phrases, and MH doesn't understand them. I recommend that writers limit each phrase to a single word, preferably a quoted string:
"J. Q. Public"However, many messages include phrases with unquoted dots, so readers have to be prepared to handle them.
The optional phrase in a target is normally used for a human-comprehensible name. Two examples:
"The Boss" <God@heaven.af.mil> "Angels mailing list" <firstname.lastname@example.org>Many writers instead put names into comments, since that's the standard USENET name format:
God@heaven.af.mil (The Boss)822bis discourages all use of comments inside targets.
Sun's mailx is unable to handle a bracketed address without a phrase:
<God@heaven.af.mil>I recommend that writers avoid using a bracketed address when there is no phrase.
Microsoft Outlook 2000 reportedly aborts header processing when it sees a phrase consisting of a single space:
" " <God@heaven.af.mil>I do not know what other phrases trigger this bug.
The Boss <God@heaven.af.mil>, email@example.com allows any number of commas between and around targets:
,,,God@heaven.af.mil,,,firstname.lastname@example.org,,,Pine throws away the rest of the recipient list when it sees an extra comma. 822bis prohibits extra commas.
Users enjoy being able to leave out the commas, so it's helpful if the MUA can convert
God@heaven.af.mil email@example.com (WRONG)into the correct target list:
the gang: firstname.lastname@example.org, email@example.com; recipient list not shown: ;Beware that pre-1996 versions of sendmail will corrupt "phrase longer than one word: ;" into "phrase longer than one word:;@the.sendmail.host".
people who asked: ;, other people who should know: ;