rfc733.txt

RFC 的详细文档！

    the output to the addressee's desk.

    An individual may have  several  mailboxes  and  a  group  of
    individuals  may wish to receive mail as a single unit (i.e.,
    a distribution list).  The second and third  alternatives  of
    an  address  list  (#address)  allow  naming  a collection of
    subordinate  addresses  list(s).   Recipient  mailboxes   are
    specified  within the bracketed part ("<" - ">" or ":" - ";")
    of such named lists.  The use of angle-brackets ("<", ">") is
    intended for the cases of individuals with multiple mailboxes
    and of special mailbox lists; it is not expected to be nested
    more  than  one level, although the specification allows such
    nesting.  The use of colon/semi-colon (":", ";") is  intended
    for  the  case  of  groups.   Groups  can be expected to nest
    (i.e., to  contain  subgroups).   For  both  individuals  and
    groups,  a  copy  of the transmitted message is to be sent to
    EACH mailbox  listed.   For  the  case  of  a  special  list,
    treatment of addresses is defined in the relevant subsections
    of this section.

b.  The inclusion of bare quoted-strings as addresses (i.e.,  the
    fourth  address-form  alternative)  is allowed as a syntactic
    convenience, but no semantics  are  defined  for  their  use.
    However,  it is reasonable, when replicating an address list,
    to replicate ALL of its members, including quoted-strings.

c.  ":Include:" specifications are used to refer to one  or  more
    locations  containing  stored  address  lists (#address).  If
    more than one location is referenced, the address part of the
    Include  phrase  must  be  a  list  (#address)  surrounded by
    angle-brackets, as per the "Individual / List" alternative of
    <address>.   Constituent  addresses  must  resolve to a host-

Standard for the Format of Text Messages                       18
IV. Semantics
 A. Address Fields



    phrase; only they have any  meaning  within  this  construct.
    The phrase part of indicated host-phrases should contain text
    which the referenced  host  can  resolve  to  a  file.   This
    standard is not a protocol and so does not prescribe HOW data
    is to be retrieved from the  file.   However,  the  following
    requirements are made:

         o  The file must be accessible  through  the  local
            operating system interface (if it exists), given
            adequate user access rights; and

         o  If a host has an FTP server and a user  is  able
            to  retrieve  any files from the host using that
            server, then the file must be accessible through
            FTP,  using  DEFAULT  transfer  settings,  given
            adequate user access rights.

    It is intended that this mechanism allow programs to retrieve
    such lists automatically.

    The interpretation of such a file reference follows.  This is
    not  intended  to imply any particular implementation scheme,
    but is presented  to  aid  in  understanding  the  notion  of
    including  file  contents in address lists:

         o  Elements of the address list part are alternates
            and  the  contents of ONLY ONE of them are to be
            included in the resultant address list.

         o  The contents of the file indicated by  a  member
            host-phrase  are  treated as an address list and
            are inserted as an address  list  (#address)  in
            the  position  of  the  path item in the syntax.
            That is, the TELNET ASCII characters  specifying
            the  entire Include <address> is replaced by the
            contents of one of the files to which the  host-
            phrase(s),   of  the  address  list  (#address),
            refers.  Therefore, the contents of  each  file,
            indicated   by   an  Include  address,  must  be
            syntactically self-contained and must adhere  to
            the full syntax prescribed herein for an address
            list.

d.  ":Postal:" specifications are used to indicate (U.S.)  postal
    addresses,  but  can  be  treated  the  same as quoted-string
    addresses.  To reference a list of postal addresses, the list
    must  conform  to  the  "Individual  /  List"  alternative of
    <address>.  The ":Include:" alternative also is valid.

e.  The "':' atom ':'" syntax is intended as a general  mechanism
    for  indicating  specially  data-typed  addresses.   As  with
    extension-fields, the authors of this document will  regulate

Standard for the Format of Text Messages                       19
IV. Semantics
 A. Address Fields



    the  publishing  of  specifications  for these extended data-
    types.  In the absence of defined semantics,  any  occurrence
    of  an address in this form may be treated as a quoted-string
    address.

f.  A node name must be THE official name of a network or a host,
    or  else  a decimal number indicating the Network address for
    that network or host, at the time  the  message  is  created.
    The  USE  OF NUMBERS IS STRONGLY DISCOURAGED and is permitted
    only due to the occasional necessity of bypassing local  name
    tables.   For  the  ARPANET, official names are maintained by
    the Network Information Center at  SRI  International,  Menlo
    Park, California.

    Whenever a message might be transmitted or migrate to a  host
    on  another  network,  full  hierarchical  addresses  must be
    specified.   These  are  indicated  as  a  series  of  words,
    separated  by at-sign or "at" indications.  The communication
    environment is assumed to consist of a collection of networks
    organized  as  independent  "trees"  except  for  connections
    between the root nodes.  That is, only the roots can  act  as
    gateways  between  these  independent  networks.  While other
    actual connections may exist, it is believed  that  presuming
    this  type of organization will provide a reliable method for
    describing VALID, if not EFFICIENT, paths between  hosts.   A
    typical full mailbox specification might therefore look like:

         Friendly User @ hosta @ local-net1 @ major-netq

    In the simplest case, a mail-sending host should transmit the
    message  to the node which is mentioned last (farthest to the
    right), strip off that node reference from the specification,
    and then pass the remaining host-phrase to the recipient host
    (in  the  ARPANET,  its  FTP server) for it to process.  This
    treats the remaining portion of the host-indicator merely  as
    the terminating part of the phrase.

         NOTE:  When passing any portion of a host-indicator
                onto a process which does not interpret data
                according to this  standard  (e.g.,  ARPANET
                FTP  servers), "@" must be used and not "at"
                and it must not be preceded or  followed  by
                any  LWSP-chars.   Using  the above example,
                the following string would be passed to  the
                major-netq gateway:

                Friendly User@hosta@local-net1

    When the sending host  has  more  knowledge  of  the  network
    environment,  then  it  should  send the message along a more
    efficient path, making appropriate changes to the form of the
    host-phrase which it gives to the recipient host.

Standard for the Format of Text Messages                       20
IV. Semantics
 A. Address Fields



    To use the above specification as an example:  If  a  sending
    hostb  also were part of local-net1, then it could  send  the
    message  directly  to  hosta  and  would give only the phrase
    "Friendly User" to hosta's mail-receiving program.  If  hostb
    were  part  of  local-net2, along with hostc, and happened to
    know that hosta and hostc were  part  of  another  local-net,
    then  hostb  could  send  the message to hostc to the address
    "Friendly User@hosta".

    The phrase in a host-phrase is intended to be meaningful only
    to  the  indicated  receiving  host.  To all other hosts, the
    phrase is to be treated as an uninterpreted string.  No  case
    transformations  should  be  (automatically) performed on the
    phrase.  The phrase  is  passed  to  the  local  host's  mail
    sending  program; it is the responsibility of the destination
    host's mail receiving (distribution) program to perform  case
    mapping on this phrase, if required, to deliver the mail.


2.  Originator Fields

    WARNING:  The standard  allows  only  a  subset  of  the
              combinations  possible  with the From, Sender,
              and  Reply-To  fields.   The   limitation   is
              intentional.

a.  From

    This field contains the identity of the person(s) who  wished
    this message to be sent.  The message-creation process should
    default this field to be a single machine address, indicating
    the AGENT (person or process) entering the message.  If  this
    is  NOT  done, the "Sender" field MUST be present; if this IS
    done, the "Sender" field is optional.

b.  Sender

    This field contains  the  identity  of  the  AGENT (person or
    process) who  sends the message.  It is intended for use when
    the sender is not the author of the message, or  to  indicate
    who  among  a group of authors actually sent the message.  If
    the contents  of  the  "Sender"  field  would  be  completely
    redundant with the "From" field, then the "Sender" field need
    not be present and  its  use  is  discouraged  (though  still
    legal);  in  particular,  the  "Sender" field MUST be present
    if it is NOT the same as the "From" Field.

    The  Sender  host-phrase  includes  a   phrase   which   must
    correspond  to  a  specific  agent  (i.e.,  a human user or a
    computer program)  rather  than  a  standard  address.   This
    indicates  the  expectation  that the field will identify the
    single AGENT (person or process) responsible for sending  the

Standard for the Format of Text Messages                       21
IV. Semantics
 A. Address Fields



    mail  and not simply include the name of a mailbox from which
    the mail was sent.  For example in the case of a shared login
    name, the name, by itself, would not be adequate.  The phrase
    part of the host-phrase,  which  refers  to  this  agent,  is
    expected  to be a computer system term, and not (for example)
    a generalized person reference which can be used outside  the
    network text message context.

    Since the critical function served by the "Sender"  field  is
    the  identification of the agent responsible for sending mail
    and since computer programs cannot be  held  accountable  for
    their  behavior, is strongly recommended that when a computer
    program generates a message, the HUMAN who is responsible for
    that  program  be  referenced  as  part of the "Sender" field
    host-phrase.

c.  Reply-To

    This field provides a general mechanism  for  indicating  any
    mailbox(es) to which responses are to be sent.  Three typical
    uses for this feature can be  distinguished.   In  the  first
    case,  the  author(s)  may  not  have  regular  machine-based
    mailboxes and therefore wish(es)  to  indicate  an  alternate
    machine  address.   In  the  second  case, an author may wish
    additional persons to be made aware of, or  responsible  for,
    responses;  responders  should  send  their  replies  to  the
    "Reply-To" mailbox(es) listed in  the  original  message.   A
    somewhat  different  use may be of some help to "text message
    teleconferencing" groups equipped with automatic distribution
    services:   include  the  address  of  that  service  in  the
    "Reply-To"  field  of   all   messages   submitted   to   the
    teleconference;  then  participants can "reply" to conference
    submissions to guarantee  the  correct  distribution  of  any
    submission of their own.

    Reply-To fields are  NOT  required  to  contain  any  machine
    addresses  (i.e., host-phrases).   Note,  however,  that  the
    absence  of even one  valid  network  address  will  tend  to
    prevent  software  systems from automatically assisting users
    in conveniently responding to mail.

NOTE:  For systems which automatically generate address lists for
replies to messages, the following recommendations are made:

     o  The receiver, when replying  to  a  message,  should
        NEVER automatically include the "Sender" host-phrase
        in the reply's address list;

     o  If the  "Reply-To"  field  exists,  then  the  reply
        should  go  ONLY  to the addresses indicated in that
        field and not to  the  addresses  indicated  in  the
        "From" field.

Standard for the Format of Text Messages                       22
IV. Semantics
 A. Address Fields



(Extensive    examples  are  provided  in   Section   V.)    This
recommendation  is intended only for originator-fields and is not
intended to suggest that replies should not also be sent  to  the
other  recipients  of  this  message.  It is up to the respective
mail handling programs to decide what additional facilities  will
be provided.


3.  Receiver Fields

a.  To

    This field contains the identity of the primary recipients of
    the message.

b.  cc

    This field contains the identity of the secondary  recipients
    of the message.

b.  Bcc

    This field contains the identity of additional recipients  of
    the  message.  The contents of this field are not included in
    copies of the message  sent  to  the  primary  and  secondary
    recipients.   Some  systems may choose to include the text of
    the "Bcc" field only in the author(s)'s  copy,  while  others
    may  also  include it in the text sent to all those indicated
    in the "Bcc" list.



B.  REFERENCE SPECIFICATION FIELDS


1.  Message-ID

This field contains a unique identifier (the phrase) which refers
to  THIS  version of THIS message.  The uniqueness of the message
identifier is guaranteed by the host which  generates  it.   This
identifier is intended to be machine readable and not necessarily
meaningful to humans.  A message identifier pertains  to  exactly
one  instantiation  of a particular message; subsequent revisions
to the message should each receive a new message identifier.


2.  In-Reply-To

The contents of this field identify previous correspondence which
this  message answers.  Note that if message identifiers are used
in this field, they must use the mach-id specification format.


Standard for the Format of Text Messages                       23
IV. Semantics
 B. Reference Specification Fields



3.  References

The contents of this field identify  other  correspondence  which
this  message  references.   Note  that  if  message  identifiers
are used, they  must  use  the  mach-id  specification format.