rfc850.txt

RFC 的详细文档！




"cbosgd!mhuxj!mhuxt",    "cbosgd,  mhuxj,  mhuxt",     and
"@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp"      and       even
"teklabs,   zehntel,   sri-unix@cca!decvax"    are   valid
entries.  (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
third example was  "teklabs".   Letters,  digits,  periods
and  hyphens  are  considered  part  of  site 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
system.

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  travelled  to  reach  the  local  site.
There  are  several  uses for this information.  One is to
monitor USENET routing for performance  reasons.   Another
is  to  establish  a path to reach new sites.  Perhaps the
most important is to cut down on redundant USENET  traffic
by failing to forward a message to a site that is known to
have already received it.   In  particular,  when  site  A
sends  an article to site B, the Path line includes   "A",
so that site B will not immediately send the article  back
to  site  A.   The  site  name  each site 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 site adds its own name to the front of a  path  when  it
receives  a message from another site.  Thus, if a message
with path A!X!Y!Z is passed from site A to site 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  sites  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.   Thus, sites are
required to continue to keep the Path line  in  a  working
reply  format  as much as possible, until January 1, 1984.
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


                          - 7 -


existing  convention of placing the site name and an   "!" 
at the front of the path, and of starting  the  path  with
the  site  name,  an   "!",   and the user name, should be
maintained at least until 1984.

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  article  to  the
network,  and  should  be  verified by the software at the
submitting site.

For example, if John Smith is visiting CCA and  wishes  to
post  an  article 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 site sri-unix, the lines might read

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

The primary purpose of this field is to be able  to  track
down  articles 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  articles  are to be
posted to the newsgroup(s) listed here.  If this  line  is
not  present,  followups  are  posted  to the newsgroup(s)
listed in the Newsgroups line, except  that  followups  to
"net.general"  should instead go to  "net.followup".

2.2.4  Date-Received  This line (formerly  "Received")  is
in  a  legal  USENET date format.  It records the date and
time that the article was  first  received  on  the  local
system.   If  this  line  is  present  in an article being
transmitted from one host to another, the  receiving  host
should  ignore  it  and  replace it with the current date.
Since this field is intended for local use only,  no  site
is  required  to support it.  However, no site should pass
this field on to another site unchanged.

                          - 8 -



2.2.5  Expires  This line,  if  present,  is  in  a  legal
USENET  date  format.  It specifies a suggested expiration
date for the article.  If not present, the  local  default
expiration date is used.

This field is intended to be used  to  clean  up  articles
with  a  limited usefulness, or to keep important articles
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 sites have
local  policies  for  expiration  of  news  (depending  on
available disk space, for instance), users are discouraged
from providing expiration dates for articles 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.

2.2.6  References  This field lists the  message  ID's  of
any articles prompting the submission of this article.  It
is required for all follow-up articles, and forbidden when
a new subject is raised.  Implementations should provide a
follow-up command, which allows a user to post a follow-up
article.   This  command  should  generate  a Subject line
which is the same as the original article, 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  article (including the angle brackets).
If the original article does have a References  line,  the
followup  article should have a References line containing
the text of the original References line, a blank, and the
message ID of the original article.

The purpose of the References header is to allow  articles
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  may not make use of this header, but all
automatically  generated  followups  should  generate  the
References line for the benefit of systems that do use it,
and manually generated followups (e.g. typed in well after
the  original  article  has  been  printed by the machine)
should be encouraged to include them as well.

2.2.7  Control  If an article contains a Control line, the
article  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.

                          - 9 -



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.

2.2.8  Distribution   This  line  is  used  to  alter  the
distribution scope of the message.  It has the same format
as 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 instead of the Newsgroups line.  Thus, a car for sale
in New Jersey might have headers including

     Newsgroups: net.auto,net.wanted
     Distribution: nj.all

so that  it  would  only  go  to  persons  subscribing  to
net.auto  or  net.wanted within New Jersey.  The intent of
this header is to further restrict the distribution  of  a
newsgroup, not to increase it.  A local newsgroup, such as
nj.crazy-eddie, will probably not be propagated  by  sites
outside  New  Jersey  that do not show such a newsgroup as
valid.  Wildcards in newsgroup names in  the  Distribution
line are allowed.  Followup articles should default to the
same Distribution line as the original  article,  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.9  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 site names are often cryptic enough to make
it  hard  to  recognize the organization by the electronic
address.


3.  Control Messages

This section lists the control messages currently defined.
The  body  of  the  Control header 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
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.




                          - 10 -



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

3.1  Cancel

     cancel <message ID>

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

Only the author of the article or the local super user  is
allowed  to  use  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  site  (say  "A")  to tell another site
("B")  that  a particular message has been received on  A.
Suppose  that site A receives article  "ucbvax.1234",  and
wishes to transmit the article to site  B.   A  sends  the
control  message   "ihave  ucbvax.1234  A"   to site B (by
posting it to newsgroup  "to.B").   B  responds  with  the
control  message   "sendme  ucbvax.1234  B"  (on newsgroup
to.A) if it has not already received  the  article.   Upon
receiving the Sendme message, A sends the article to B.

This protocol can be used to cut down on redundant traffic
between  sites.  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 article 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.



                          - 11 -



3.3  Newgroup

     newgroup <groupname>

This control message creates a new newsgroup with the name
given.  Since no articles 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.

3.4  Rmgroup

     rmgroup <groupname>

This message removes a  newsgroup  with  the  given  name.
Since  the  newsgroup  is  removed  from every site on the
network, this  command  should  be  used  carefully  by  a
responsible administrator.

3.5  Sendsys

     sendsys (no arguments)

The   "sys"   file,  listing  all  neighbors   and   which
newsgroups  are  sent  to each neighbor, will be mailed to
the author of the control message (Reply-to,  if  present,
otherwise  From).   This  information is considered public
information, and it is  a  requirement  of  membership  in
USENET  that  this  information  be  provided  on request,
either automatically in response to this control  message,
or  manually,  by mailing the requested information to the
author of the message.  This information is used  to  keep
the  map  of  USENET  up  to  date, and to determine where
netnews is sent.

The format of the file mailed back to the author should be
the same as that of the  "sys"  file.  This format has one
line per neighboring site (plus one  line  for  the  local
site),  containing four colon separated fields.  The first
field has the site name of the neighbor, the second  field
has  a newsgroup pattern describing the newsgroups sent to
the neighbor.  The third and fourth fields are not defined
by this standard.  A sample response:

     From cbosgd!mark  Sun Mar 27 20:39:37 1983
     Subject: response to your sendsys request
     To: [e-mail]







                          - 12 -