Ubuntu Manpage: addresses - formats for Internet mail addresses

Provided by: qmail_1.06-6.2~deb10u1build0.16.04.1_amd64

NAME

       addresses - formats for Internet mail addresses

INTRODUCTION

       A mail address is a string of characters containing @.

       Every  mail address has a local part and a domain part.  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 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  to  say  how  mail  messages  will  be
       delivered to addresses with domain part heaven.af.mil.

       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.

QMAIL EXTENSIONS

       The qmail system allows several further types of addresses in mail envelopes.

       First,  an  envelope recipient address without an @ is interpreted as being at envnoathost.  For example,
       if envnoathost is heaven.af.mil, the address God will be rewritten as God@heaven.af.mil.

       Second, the address #@[] is used as an envelope sender address for double bounces.

       Third, envelope sender addresses of the form pre@host-@[] are used to support  variable  envelope  return
       paths   (VERPs).   qmail-send  will  rewrite  pre@host-@[]  as  prerecip=domain@host  for  deliveries  to
       recip@domain.  Bounces directly from qmail-send will come back to pre@host.

CHOOSING MAIL ADDRESSES

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 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 to god@heaven.af.mil.

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 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 domain, 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.

ENCODED ADDRESSES IN SMTP COMMANDS

       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:<God@heaven.af.mil>
          RCPT TO:<a\"quote@heaven.af.mil>
          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.

ENCODED ADDRESSES IN MAIL HEADERS