addresses - formats for Internet mail addresses
A mail address
is a string of characters containing @.
Every mail address has a local part
and a domain part.
part is everything after the final @. The local part is everything before.
For example, the mail addresses
all have domain part heaven.af.mil
. The local parts are God
empty, and @at@
Some domains have owners. It is up to the owner of heaven.af.mil
how mail messages will be delivered to addresses with domain part
The domain part of an address is interpreted without regard to case, so
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.
system allows several further types of addresses in mail
First, an envelope recipient address without an @ is interpreted as being at
. For example, if envnoathost
, the address God
will be rewritten as
Second, the address #@
is used as an envelope sender address for double
Third, envelope sender addresses of the form
pre@host-@ are used to support variable
envelope return paths (VERPs). qmail-send
pre@ host-@ as
prerecip=domain @host for deliveries
to recip@domain. Bounces directly from
will come back to pre@host.
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
Do not use ASCII control characters. NUL is regularly corrupted. 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 programs (and users!)
will incorrectly convert God@heaven.af.mil
Be wary of the following characters:
Some users will not know how to feed these characters safely to their mail
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 dotted-decimal IP address in brackets, such as [127.0.0.1]
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 mil
don't bother using the address root@mil
; most users will be unable to
send messages to that address. Same for the root domain.
Avoid domain names longer than 64 characters.
RFC 821 defines an encoding of mail addresses in SMTP. For example, the
could be encoded in RCPT commands as
RCPT TO:<The\ Almighty.One@heaven.af.mil>
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 surrounded by brackets. The only allowable
characters in components 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.
RFC 822 defines an encoding of mail addresses in certain header fields in a mail
message. For example, the addresses
could be encoded in a To
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 elements 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.
envelopes(5), qmail-header(5), qmail-inject(8), qmail-remote(8),