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




 
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 


    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> []
                   sendme <Message-ID list> []

    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
    "<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message to
    host B.

    A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A" to
    host B (by posting it to newsgroup to.B).  B responds with the
    control message "sendme <1234@ucbvax.Berkeley.edu> B" (on newsgroup
    to.A), if it has not already received the message.  Upon receiving




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