rfc1036.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

    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.





Horton & Adams                                                  [Page 7]

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
    message might read:

              From: [e-mail] (John Smith)
              Sender: [e-mail] (Sarah Jones)

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

              From: [e-mail]
              Sender: [e-mail]

    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.






Horton & Adams                                                  [Page 8]

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.






Horton & Adams                                                  [Page 9]

RFC 1036              Standard for USENET Messages         December 1987


    Also for upward compatibility, if the first 4 characters of the
    "Subject:" line are "cmsg", the rest of the "Subject:" line should
    be interpreted as a control message.

2.2.7.  Distribution

    This line is used to alter the distribution scope of the message.
    It is a comma separated list similar to the "Newsgroups" line.  User
    subscriptions are still controlled by "Newsgroups", but the message
    is sent to all systems subscribing to the newsgroups on the
    "Distribution" line in addition to the "Newsgroups" line.  For the
    message to be transmitted, the receiving site must normally receive
    one of the specified newsgroups AND must receive one of the
    specified distributions.  Thus, a message concerning a car for sale
    in New Jersey might have headers including:

                   Newsgroups: rec.auto,misc.forsale
                   Distribution: nj,ny

    so that it would only go to persons subscribing to rec.auto or misc.
    for sale within New Jersey or New York.  The intent of this header
    is to restrict the distribution of a newsgroup further, not to
    increase it.  A local newsgroup, such as nj.crazy-eddie, will
    probably not be propagated by hosts outside New Jersey that do not
    show such a newsgroup as valid.  A follow-up message should default
    to the same "Distribution" line as the original message, but the
    user can change it to a more limited one, or escalate the
    distribution if it was originally restricted and a more widely
    distributed reply is appropriate.

2.2.8.  Organization

    The text of this line is a short phrase describing the organization
    to which the sender belongs, or to which the machine belongs.  The
    intent of this line is to help identify the person posting the
    message, since host names are often cryptic enough to make it hard
    to recognize the organization by the electronic address.

2.2.9.  Keywords

    A few well-selected keywords identifying the message should be on
    this line.  This is used as an aid in determining if this message is
    interesting to the reader.

2.2.10.  Summary

    This line should contain a brief summary of the message.  It is
    usually used as part of a follow-up to another message.  Again, it



Horton & Adams                                                 [Page 10]

RFC 1036              Standard for USENET Messages         December 1987


    is very useful to the reader in determining whether to read the
    message.

2.2.11.  Approved

    This line is required for any message posted to a moderated
    newsgroup.  It should be added by the moderator and consist of his
    mail address.  It is also required with certain control messages.

2.2.12.  Lines

    This contains a count of the number of lines in the body of the
    message.

2.2.13.  Xref

    This line contains the name of the host (with domains omitted) and a
    white space separated list of colon-separated pairs of newsgroup
    names and message numbers.  These are the newsgroups listed in the
    "Newsgroups" line and the corresponding message numbers from the
    spool directory.

    This is only of value to the local system, so it should not be
    transmitted.  For example, in:

               Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
               From: [e-mail] (Brian Reid)
               Newsgroups: news.lists,news.groups
               Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
               Message-ID: <[e-mail]>
               Date: 1 Oct 86 11:26:15 GMT
               Organization: DEC Western Research Laboratory
               Lines: 441
               Approved: [e-mail]
               Xref: seismo news.lists:461 news.groups:6378

    the "Xref" line shows that the message is message number 461 in the
    newsgroup news.lists, and message number 6378 in the newsgroup
    news.groups, on host seismo.  This information may be used by
    certain user interfaces.

3.  Control Messages

    This section lists the control messages currently defined.  The body
    of the "Control" header line is the control message.  Messages are a
    sequence of zero or more words, separated by white space (blanks or
    tabs).  The first word is the name of the control message, remaining
    words are parameters to the message.  The remainder of the header



Horton & Adams                                                 [Page 11]

RFC 1036              Standard for USENET Messages         December 1987


    and the body of the message are also potential parameters; for
    example, the "From" line might suggest an address to which a
    response is to be mailed.

    Implementors and administrators may choose to allow control messages
    to be carried out automatically, or to queue them for annual
    processing.  However, manually processed messages should be dealt
    with promptly.

    Failed control messages should NOT be mailed to the originator of
    the message, but to the local "usenet" account.

3.1.  Cancel

                     cancel <Message-ID>


    If a message with the given Message-ID is present on the local
    system, the message is cancelled.  This mechanism allows a user to
    cancel a message after the message has been distributed over the
    network.

    If the system is unable to cancel the message as requested, it
    should not forward the cancellation request to its neighbor systems.

    Only the author of the message or the local news administrator is
    allowed to send this message.  The verified sender of a message is
    the "Sender" line, or if no "Sender" line is present, the "From"
    line.  The verified sender of the cancel message must be the same as
    either the "Sender" or "From" field of the original message.  A
    verified sender in the cancel message is allowed to match an
    unverified "From" in the original message.

3.2.  Ihave/Sendme

                   ihave <Message-ID list> [<remotesys>]
                   sendme <Message-ID list> [<remotesys>]

    This message is part of the ihave/sendme protocol, which allows one
    host (say A) to tell another host (B) that a particular message has
    been received on A.  Suppose that host A receives message
    "<[e-mail]>", and wishes to transmit the message to
    host B.

    A sends the control message "ihave <[e-mail]> A" to
    host B (by posting it to newsgroup to.B).  B responds with the
    control message "sendme <[e-mail]> B" (on newsgroup
    to.A), if it has not already received the message.  Upon receiving



Horton & Adams                                                 [Page 12]

RFC 1036              Standard for USENET Messages         December 1987


    the sendme message, A sends the message to B.

    This protocol can be used to cut down on redundant traffic between
    hosts.  It is optional and should be used only if the particular
    situation makes it worthwhile.  Frequently, the outcome is that,
    since most original messages are short, and since there is a high
    overhead to start sending a new message with UUCP, it costs as much
    to send the ihave as it would cost to send the message itself.

    One possible solution to this overhead problem is to batch requests.
    Several Message-ID's may be announced or requested in one message.
    If no Message-ID's are listed in the control message, the body of
    the message should be scanned for Message-ID's, one per line.

3.3.  Newgroup

                      newgroup <groupname> [moderated]

    This control message creates a new newsgroup with the given name.
    Since no messages may be posted or forwarded until a newsgroup is
    created, this message is required before a newsgroup can be used.
    The body of the message is expected to be a short paragraph
    describing the intended use of the newsgroup.

    If the second argument is present and it is the keyword moderated,
    the group should be created moderated instead of the default of
    unmoderated.  The newgroup message should be ignored unless there is
    an "Approved" line in the same message header.

3.4.  Rmgroup

                            rmgroup <groupname>

    This message removes a newsgroup with the given name.  Since the