characters (e.g., blank and tab) are not allowed in a Message-ID.
    Slashes ("/") are strongly discouraged.  All characters between the
    angle brackets must be printing ASCII characters.

2.1.6.  Path

    This line shows the path the message took to reach the current
    system.  When a system forwards the message, it should add its own
    name to the list of systems in the "Path" line.  The names may be
    separated by any punctuation character or characters (except "."
    which is considered part of the hostname).  Thus, the following are
    valid entries:

                   cbosgd!mhuxj!mhuxt
                   cbosgd, mhuxj, mhuxt
                   @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
                   teklabs, zehntel, sri-unix@cca!decvax

    (The latter path indicates a message that passed through decvax,
    cca, sri-unix, zehntel, and teklabs, in that order.) Additional
    names should be added from the left.  For example, the most recently
    added name in the fourth example was teklabs.  Letters, digits,
    periods and hyphens are considered part of host names; other
    punctuation, including blanks, are considered separators.

    Normally, the rightmost name will be the name of the originating
    system.  However, it is also permissible to include an extra entry
    on the right, which is the name of the sender.  This is for upward
    compatibility with older systems.

    The "Path" line is not used for replies, and should not be taken as
    a mailing address.  It is intended to show the route the message
    traveled to reach the local host.  There are several uses for this
    information.  One is to monitor USENET routing for performance




 
RFC 1036              Standard for USENET Messages         December 1987


    reasons.  Another is to establish a path to reach new hosts.
    Perhaps the most important use is to cut down on redundant USENET
    traffic by failing to forward a message to a host that is known to
    have already received it.  In particular, when host A sends a
    message to host B, the "Path" line includes A, so that host B will
    not immediately send the message back to host A.  The name each host
    uses to identify itself should be the same as the name by which its
    neighbors know it, in order to make this optimization possible.

    A host adds its own name to the front of a path when it receives a
    message from another host.  Thus, if a message with path "A!X!Y!Z"
    is passed from host A to host B, B will add its own name to the path
    when it receives the message from A, e.g., "B!A!X!Y!Z".  If B then
    passes the message on to C, the message sent to C will contain the
    path "B!A!X!Y!Z", and when C receives it, C will change it to
    "C!B!A!X!Y!Z".

    Special upward compatibility note:  Since the "From", "Sender", and
    "Reply-To" lines are in Internet format, and since many USENET hosts
    do not yet have mailers capable of understanding Internet format, it
    would break the reply capability to completely sever the connection
    between the "Path" header and the reply function.  It is recognized
    that the path is not always a valid reply string in older
    implementations, and no requirement to fix this problem is placed on
    implementations.  However, the existing convention of placing the
    host name and an "!"  at the front of the path, and of starting the
    path with the host name, an "!", and the user name, should be
    maintained when possible.

2.2.  Optional Headers

2.2.1.  Reply-To

    This line has the same format as "From".  If present, mailed replies
    to the author should be sent to the name given here.  Otherwise,
    replies are mailed to the name on the "From" line. (This does not
    prevent additional copies from being sent to recipients named by the
    replier, or on "To" or "Cc" lines.)  The full name may be optionally
    given, in parentheses, as in the "From" line.

2.2.2.  Sender

    This field is present only if the submitter manually enters a "From"
    line.  It is intended to record the entity responsible for
    submitting the message to the network.  It should be verified by the
    software at the submitting host.






 
RFC 1036              Standard for USENET Messages         December 1987


    For example, if John Smith is visiting CCA and wishes to post a
    message to the network, using friend Sarah Jones' account, the