addresses(5)                                                    File Formats Manual                                                   addresses(5)

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 re-
       write 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 prac-
       tice, 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  let-
       ter; the last character must not be a hyphen.

ENCODED ADDRESSES IN MAIL HEADERS

       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 To field as

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

SEE ALSO

       envelopes(5), qmail-header(5), qmail-inject(8), qmail-remote(8), qmail-smtpd(8)

                                                                                                                                      addresses(5)