message might read:

              From: smith@ucbvax.Berkeley.EDU (John Smith)
              Sender: jones@cca.COM (Sarah Jones)

    If a gateway program enters a mail message into the network at host
    unix.SRI.COM, the lines might read:

              From: John.Doe@A.CS.CMU.EDU
              Sender: network@unix.SRI.COM

    The primary purpose of this field is to be able to track down
    messages to determine how they were entered into the network.  The
    full name may be optionally given, in parentheses, as in the "From"
    line.

2.2.3.  Followup-To

    This line has the same format as "Newsgroups".  If present, follow-
    up messages are to be posted to the newsgroup or newsgroups listed
    here.  If this line is not present, follow-ups are posted to the
    newsgroup or newsgroups listed in the "Newsgroups" line.

    If the keyword poster is present, follow-up messages are not
    permitted.  The message should be mailed to the submitter of the
    message via mail.

2.2.4.  Expires

    This line, if present, is in a legal USENET date format.  It
    specifies a suggested expiration date for the message.  If not
    present, the local default expiration date is used.  This field is
    intended to be used to clean up messages with a limited usefulness,
    or to keep important messages around for longer than usual.  For
    example, a message announcing an upcoming seminar could have an
    expiration date the day after the seminar, since the message is not
    useful after the seminar is over.  Since local hosts have local
    policies for expiration of news (depending on available disk space,
    for instance), users are discouraged from providing expiration dates
    for messages unless there is a natural expiration date associated
    with the topic.  System software should almost never provide a
    default "Expires" line.  Leave it out and allow local policies to be
    used unless there is a good reason not to.







 
RFC 1036              Standard for USENET Messages         December 1987


2.2.5.  References

    This field lists the Message-ID's of any messages prompting the
    submission of this message.  It is required for all follow-up
    messages, and forbidden when a new subject is raised.
    Implementations should provide a follow-up command, which allows a
    user to post a follow-up message.  This command should generate a
    "Subject" line which is the same as the original message, except
    that if the original subject does not begin with "Re:" or "re:", the
    four characters "Re:" are inserted before the subject.  If there is
    no "References" line on the original header, the "References" line
    should contain the Message-ID of the original message (including the
    angle brackets).  If the original message does have a "References"
    line, the follow-up message should have a "References" line
    containing the text of the original "References" line, a blank, and
    the Message-ID of the original message.

    The purpose of the "References" header is to allow messages to be
    grouped into conversations by the user interface program.  This
    allows conversations within a newsgroup to be kept together, and
    potentially users might shut off entire conversations without
    unsubscribing to a newsgroup.  User interfaces need not make use of
    this header, but all automatically generated follow-ups should
    generate the "References" line for the benefit of systems that do
    use it, and manually generated follow-ups (e.g., typed in well after
    the original message has been printed by the machine) should be
    encouraged to include them as well.

    It is permissible to not include the entire previous "References"
    line if it is too long.  An attempt should be made to include a
    reasonable number of backwards references.

2.2.6.  Control

    If a message contains a "Control" line, the message is a control
    message.  Control messages are used for communication among USENET
    host machines, not to be read by users.  Control messages are
    distributed by the same newsgroup mechanism as ordinary messages.
    The body of the "Control" header line is the message to the host.

    For upward compatibility, messages that match the newsgroup pattern
    "all.all.ctl" should also be interpreted as control messages.  If no
    "Control" header is present on such messages, the subject is used as
    the control message.  However, messages on newsgroups matching this
    pattern do not conform to this standard.