You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ba...@apache.org on 2006/07/29 15:16:01 UTC
svn commit: r426798 [21/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Added: james/server/trunk/src/site/resources/rfclist/nntp/rfc1036.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/nntp/rfc1036.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/nntp/rfc1036.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/nntp/rfc1036.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,1068 @@
+
+
+
+
+
+Network Working Group M. Horton
+Request for Comments: 1036 AT&T Bell Laboratories
+Obsoletes: RFC-850 R. Adams
+ Center for Seismic Studies
+ December 1987
+
+
+ Standard for Interchange of USENET Messages
+
+
+
+STATUS OF THIS MEMO
+
+ This document defines the standard format for the interchange of
+ network News messages among USENET hosts. It updates and replaces
+ RFC-850, reflecting version B2.11 of the News program. This memo is
+ disributed as an RFC to make this information easily accessible to
+ the Internet community. It does not specify an Internet standard.
+ Distribution of this memo is unlimited.
+
+1. Introduction
+
+ This document defines the standard format for the interchange of
+ network News messages among USENET hosts. It describes the format
+ for messages themselves and gives partial standards for transmission
+ of news. The news transmission is not entirely in order to give a
+ good deal of flexibility to the hosts to choose transmission
+ hardware and software, to batch news, and so on.
+
+ There are five sections to this document. Section two defines the
+ format. Section three defines the valid control messages. Section
+ four specifies some valid transmission methods. Section five
+ describes the overall news propagation algorithm.
+
+2. Message Format
+
+ The primary consideration in choosing a message format is that it
+ fit in with existing tools as well as possible. Existing tools
+ include implementations of both mail and news. (The notesfiles
+ system from the University of Illinois is considered a news
+ implementation.) A standard format for mail messages has existed
+ for many years on the Internet, and this format meets most of the
+ needs of USENET. Since the Internet format is extensible,
+ extensions to meet the additional needs of USENET are easily made
+ within the Internet standard. Therefore, the rule is adopted that
+ all USENET news messages must be formatted as valid Internet mail
+ messages, according to the Internet standard RFC-822. The USENET
+ News standard is more restrictive than the Internet standard,
+
+
+
+Horton & Adams [Page 1]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ placing additional requirements on each message and forbidding use
+ of certain Internet features. However, it should always be possible
+ to use a tool expecting an Internet message to process a news
+ message. In any situation where this standard conflicts with the
+ Internet standard, RFC-822 should be considered correct and this
+ standard in error.
+
+ Here is an example USENET message to illustrate the fields.
+
+ From: jerry@eagle.ATT.COM (Jerry Schwarz)
+ Path: cbosgd!mhuxj!mhuxt!eagle!jerry
+ Newsgroups: news.announce
+ Subject: Usenet Etiquette -- Please Read
+ Message-ID: <64...@eagle.ATT.COM>
+ Date: Fri, 19 Nov 82 16:14:55 GMT
+ Followup-To: news.misc
+ Expires: Sat, 1 Jan 83 00:00:00 -0500
+ Organization: AT&T Bell Laboratories, Murray Hill
+
+ The body of the message comes here, after a blank line.
+
+ Here is an example of a message in the old format (before the
+ existence of this standard). It is recommended that
+ implementations also accept messages in this format to ease upward
+ conversion.
+
+ From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
+ Newsgroups: news.misc
+ Title: Usenet Etiquette -- Please Read
+ Article-I.D.: eagle.642
+ Posted: Fri Nov 19 16:14:55 1982
+ Received: Fri Nov 19 16:59:30 1982
+ Expires: Mon Jan 1 00:00:00 1990
+
+ The body of the message comes here, after a blank line.
+
+ Some news systems transmit news in the A format, which looks like
+ this:
+
+ Aeagle.642
+ news.misc
+ cbosgd!mhuxj!mhuxt!eagle!jerry
+ Fri Nov 19 16:14:55 1982
+ Usenet Etiquette - Please Read
+ The body of the message comes here, with no blank line.
+
+ A standard USENET message consists of several header lines, followed
+ by a blank line, followed by the body of the message. Each header
+
+
+
+Horton & Adams [Page 2]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ line consist of a keyword, a colon, a blank, and some additional
+ information. This is a subset of the Internet standard, simplified
+ to allow simpler software to handle it. The "From" line may
+ optionally include a full name, in the format above, or use the
+ Internet angle bracket syntax. To keep the implementations simple,
+ other formats (for example, with part of the machine address after
+ the close parenthesis) are not allowed. The Internet convention of
+ continuation header lines (beginning with a blank or tab) is
+ allowed.
+
+ Certain headers are required, and certain other headers are
+ optional. Any unrecognized headers are allowed, and will be passed
+ through unchanged. The required header lines are "From", "Date",
+ "Newsgroups", "Subject", "Message-ID", and "Path". The optional
+ header lines are "Followup-To", "Expires", "Reply-To", "Sender",
+ "References", "Control", "Distribution", "Keywords", "Summary",
+ "Approved", "Lines", "Xref", and "Organization". Each of these
+ header lines will be described below.
+
+2.1. Required Header lines
+
+2.1.1. From
+
+ The "From" line contains the electronic mailing address of the
+ person who sent the message, in the Internet syntax. It may
+ optionally also contain the full name of the person, in parentheses,
+ after the electronic address. The electronic address is the same as
+ the entity responsible for originating the message, unless the
+ "Sender" header is present, in which case the "From" header might
+ not be verified. Note that in all host and domain names, upper and
+ lower case are considered the same, thus "mark@cbosgd.ATT.COM",
+ "mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent.
+ User names may or may not be case sensitive, for example,
+ "Billy@cbosgd.ATT.COM" might be different from
+ "BillY@cbosgd.ATT.COM". Programs should avoid changing the case of
+ electronic addresses when forwarding news or mail.
+
+ RFC-822 specifies that all text in parentheses is to be interpreted
+ as a comment. It is common in Internet mail to place the full name
+ of the user in a comment at the end of the "From" line. This
+ standard specifies a more rigid syntax. The full name is not
+ considered a comment, but an optional part of the header line.
+ Either the full name is omitted, or it appears in parentheses after
+ the electronic address of the person posting the message, or it
+ appears before an electronic address which is enclosed in angle
+ brackets. Thus, the three permissible forms are:
+
+
+
+
+
+Horton & Adams [Page 3]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ From: mark@cbosgd.ATT.COM
+ From: mark@cbosgd.ATT.COM (Mark Horton)
+ From: Mark Horton <ma...@cbosgd.ATT.COM>
+
+ Full names may contain any printing ASCII characters from space
+ through tilde, except that they may not contain "(" (left
+ parenthesis), ")" (right parenthesis), "<" (left angle bracket), or
+ ">" (right angle bracket). Additional restrictions may be placed on
+ full names by the mail standard, in particular, the characters ","
+ (comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
+ (equal), and ";" (semicolon) are inadvisable in full names.
+
+2.1.2. Date
+
+ The "Date" line (formerly "Posted") is the date that the message was
+ originally posted to the network. Its format must be acceptable
+ both in RFC-822 and to the getdate(3) routine that is provided with
+ the Usenet software. This date remains unchanged as the message is
+ propagated throughout the network. One format that is acceptable to
+ both is:
+
+ Wdy, DD Mon YY HH:MM:SS TIMEZONE
+
+ Several examples of valid dates appear in the sample message above.
+ Note in particular that ctime(3) format:
+
+ Wdy Mon DD HH:MM:SS YYYY
+
+ is not acceptable because it is not a valid RFC-822 date. However,
+ since older software still generates this format, news
+ implementations are encouraged to accept this format and translate
+ it into an acceptable format.
+
+ There is no hope of having a complete list of timezones. Universal
+ Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
+ CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be
+ supported. It is recommended that times in message headers be
+ transmitted in GMT and displayed in the local time zone.
+
+2.1.3. Newsgroups
+
+ The "Newsgroups" line specifies the newsgroup or newsgroups in which
+ the message belongs. Multiple newsgroups may be specified,
+ separated by a comma. Newsgroups specified must all be the names of
+ existing newsgroups, as no new newsgroups will be created by simply
+ posting to them.
+
+
+
+
+
+Horton & Adams [Page 4]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ Wildcards (e.g., the word "all") are never allowed in a "News-
+ groups" line. For example, a newsgroup comp.all is illegal,
+ although a newsgroup rec.sport.football is permitted.
+
+ If a message is received with a "Newsgroups" line listing some valid
+ newsgroups and some invalid newsgroups, a host should not remove
+ invalid newsgroups from the list. Instead, the invalid newsgroups
+ should be ignored. For example, suppose host A subscribes to the
+ classes btl.all and comp.all, and exchanges news messages with host
+ B, which subscribes to comp.all but not btl.all. Suppose A receives
+ a message with Newsgroups: comp.unix,btl.general.
+
+ This message is passed on to B because B receives comp.unix, but B
+ does not receive btl.general. A must leave the "Newsgroups" line
+ unchanged. If it were to remove btl.general, the edited header
+ could eventually re-enter the btl.all class, resulting in a message
+ that is not shown to users subscribing to btl.general. Also,
+ follow-ups from outside btl.all would not be shown to such users.
+
+2.1.4. Subject
+
+ The "Subject" line (formerly "Title") tells what the message is
+ about. It should be suggestive enough of the contents of the
+ message to enable a reader to make a decision whether to read the
+ message based on the subject alone. If the message is submitted in
+ response to another message (e.g., is a follow-up) the default
+ subject should begin with the four characters "Re:", and the
+ "References" line is required. For follow-ups, the use of the
+ "Summary" line is encouraged.
+
+2.1.5. Message-ID
+
+ The "Message-ID" line gives the message a unique identifier. The
+ Message-ID may not be reused during the lifetime of any previous
+ message with the same Message-ID. (It is recommended that no
+ Message-ID be reused for at least two years.) Message-ID's have the
+ syntax:
+
+ <string not containing blank or ">">
+
+ In order to conform to RFC-822, the Message-ID must have the format:
+
+ <un...@full_domain_name>
+
+ where full_domain_name is the full name of the host at which the
+ message entered the network, including a domain that host is in, and
+ unique is any string of printing ASCII characters, not including "<"
+ (left angle bracket), ">" (right angle bracket), or "@" (at sign).
+
+
+
+Horton & Adams [Page 5]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ For example, the unique part could be an integer representing a
+ sequence number for messages submitted to the network, or a short
+ string derived from the date and time the message was created. For
+ example, a valid Message-ID for a message submitted from host ucbvax
+ in domain "Berkeley.EDU" would be "<41...@ucbvax.Berkeley.EDU>".
+ Programmers are urged not to make assumptions about the content of
+ Message-ID fields from other hosts, but to treat them as unknown
+ character strings. It is not safe, for example, to assume that a
+ Message-ID will be under 14 characters, that it is unique in the
+ first 14 characters, nor that is does not contain a "/".
+
+ The angle brackets are considered part of the Message-ID. Thus, in
+ references to the Message-ID, such as the ihave/sendme and cancel
+ control messages, the angle brackets are included. White space
+ 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
+
+
+
+Horton & Adams [Page 6]
+
+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.
+
+
+
+
+
+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: 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.
+
+
+
+
+
+
+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: reid@decwrl.DEC.COM (Brian Reid)
+ Newsgroups: news.lists,news.groups
+ Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
+ Message-ID: <56...@decwrl.DEC.COM>
+ Date: 1 Oct 86 11:26:15 GMT
+ Organization: DEC Western Research Laboratory
+ Lines: 441
+ Approved: reid@decwrl.UUCP
+ 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
+ "<12...@ucbvax.Berkeley.edu>", and wishes to transmit the message to
+ host B.
+
+ A sends the control message "ihave <12...@ucbvax.Berkeley.edu> A" to
+ host B (by posting it to newsgroup to.B). B responds with the
+ control message "sendme <12...@ucbvax.Berkeley.edu> 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
+ newsgroup is removed from every host on the network, this command
+ should be used carefully by a responsible administrator. The
+ rmgroup message should be ignored unless there is an "Approved:"
+ line in the same message header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horton & Adams [Page 13]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+3.5. Sendsys
+ sendsys (no arguments)
+
+ The sys file, listing all neighbors and the newsgroups to be 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
+ host (plus one line for the local host), containing four colon
+ separated fields. The first field has the host 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. The sys file is not the same as the
+ UUCP L.sys file. A sample response is:
+
+ From: cbosgd!mark (Mark Horton)
+ Date: Sun, 27 Mar 83 20:39:37 -0500
+ Subject: response to your sendsys request
+ To: mark@cbosgd.ATT.COM
+
+ Responding-System: cbosgd.ATT.COM
+ cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,
+ test
+ ucbvax:world,comp,to.ucbvax:L:
+ cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews
+ /cbosg
+ cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
+ sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews
+ /sescent
+ npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
+ mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
+
+3.6. Version
+
+ version (no arguments)
+
+ The name and version of the software running on the local system is
+ to be mailed back to the author of the message ("Reply-to" if
+ present, otherwise "From").
+
+3.7. Checkgroups
+
+
+
+Horton & Adams [Page 14]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ The message body is a list of "official" newsgroups and their
+ description, one group per line. They are compared against the list
+ of active newsgroups on the current host. The names of any obsolete
+ or new newsgroups are mailed to the user "usenet" and descriptions
+ of the new newsgroups are added to the help file used when posting
+ news.
+
+4. Transmission Methods
+
+ USENET is not a physical network, but rather a logical network
+ resting on top of several existing physical networks. These
+ networks include, but are not limited to, UUCP, the Internet, an
+ Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET.
+ What is important is that two neighboring systems on USENET have
+ some method to get a new message, in the format listed here, from
+ one system to the other, and once on the receiving system, processed
+ by the netnews software on that system. (On UNIX systems, this
+ usually means the rnews program being run with the message on the
+ standard input. <1>)
+
+ It is not a requirement that USENET hosts have mail systems capable
+ of understanding the Internet mail syntax, but it is strongly
+ recommended. Since "From", "Reply-To", and "Sender" lines use the
+ Internet syntax, replies will be difficult or impossible without an
+ Internet mailer. A host without an Internet mailer can attempt to
+ use the "Path" header line for replies, but this field is not
+ guaranteed to be a working path for replies. In any event, any host
+ generating or forwarding news messages must have an Internet address
+ that allows them to receive mail from hosts with Internet mailers,
+ and they must include their Internet address on their From line.
+
+4.1. Remote Execution
+
+ Some networks permit direct remote command execution. On these
+ networks, news may be forwarded by spooling the rnews command with
+ the message on the standard input. For example, if the remote
+ system is called remote, news would be sent over a UUCP link
+ with the command:
+
+ uux - remote!rnews
+
+ and on a Berknet:
+
+ net -mremote rnews
+
+
+
+
+
+
+
+Horton & Adams [Page 15]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ It is important that the message be sent via a reliable mechanism,
+ normally involving the possibility of spooling, rather than direct
+ real-time remote execution. This is because, if the remote system
+ is down, a direct execution command will fail, and the message will
+ never be delivered. If the message is spooled, it will eventually
+ be delivered when both systems are up.
+
+4.2. Transfer by Mail
+
+ On some systems, direct remote spooled execution is not possible.
+ However, most systems support electronic mail, and a news message
+ can be sent as mail. One approach is to send a mail message which
+ is identical to the news message: the mail headers are the news
+ headers, and the mail body is the news body. By convention, this
+ mail is sent to the user newsmail on the remote machine.
+
+ One problem with this method is that it may not be possible to
+ convince the mail system that the "From" line of the message is
+ valid, since the mail message was generated by a program on a
+ system different from the source of the news message. Another
+ problem is that error messages caused by the mail transmission
+ would be sent to the originator of the news message, who has no
+ control over news transmission between two cooperating hosts
+ and does not know whom to contact. Transmission error messages
+ should be directed to a responsible contact person on the
+ sending machine.
+
+ A solution to this problem is to encapsulate the news message into a
+ mail message, such that the entire message (headers and body) are
+ part of the body of the mail message. The convention here is that
+ such mail is sent to user rnews on the remote system. A mail
+ message body is generated by prepending the letter N to each line of
+ the news message, and then attaching whatever mail headers are
+ convenient to generate. The N's are attached to prevent any special
+ lines in the news message from interfering with mail transmission,
+ and to prevent any extra lines inserted by the mailer (headers,
+ blank lines, etc.) from becoming part of the news message. A
+ program on the receiving machine receives mail to rnews, extracting
+ the message itself and invoking the rnews program. An example in
+ this format might look like this:
+
+
+
+
+
+
+
+
+
+
+
+Horton & Adams [Page 16]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ Date: Mon, 3 Jan 83 08:33:47 MST
+ From: news@cbosgd.ATT.COM
+ Subject: network news message
+ To: rnews@npois.ATT.COM
+
+ NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
+ NFrom: derek@sask.UUCP (Derek Andrew)
+ NNewsgroups: misc.test
+ NSubject: necessary test
+ NMessage-ID: <17...@sask.UUCP>
+ NDate: Mon, 3 Jan 83 00:59:15 MST
+ N
+ NThis really is a test. If anyone out there more than 6
+ Nhops away would kindly confirm this note I would
+ Nappreciate it. We suspect that our news postings
+ Nare not getting out into the world.
+ N
+
+ Using mail solves the spooling problem, since mail must always be
+ spooled if the destination host is down. However, it adds more
+ overhead to the transmission process (to encapsulate and extract the
+ message) and makes it harder for software to give different
+ priorities to news and mail.
+
+4.3. Batching
+
+ Since news messages are usually short, and since a large number of
+ messages are often sent between two hosts in a day, it may make
+ sense to batch news messages. Several messages can be combined into
+ one large message, using conventions agreed upon in advance by the
+ two hosts. One such batching scheme is described here; its use is
+ highly recommended.
+
+ News messages are combined into a script, separated by a header of
+ the form:
+
+
+ #! rnews 1234
+
+ where 1234 is the length of the message in bytes. Each such line is
+ followed by a message containing the given number of bytes. (The
+ newline at the end of each line of the message is counted as one
+ byte, for purposes of this count, even if it is stored as <CARRIAGE
+ RETURN><LINE FEED>.) For example, a batch of message might look
+ like this:
+
+
+
+
+
+
+Horton & Adams [Page 17]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ #! rnews 239
+ From: jerry@eagle.ATT.COM (Jerry Schwarz)
+ Path: cbosgd!mhuxj!mhuxt!eagle!jerry
+ Newsgroups: news.announce
+ Subject: Usenet Etiquette -- Please Read
+ Message-ID: <64...@eagle.ATT.COM>
+ Date: Fri, 19 Nov 82 16:14:55 EST
+ Approved: mark@cbosgd.ATT.COM
+
+ Here is an important message about USENET Etiquette.
+ #! rnews 234
+ From: jerry@eagle.ATT.COM (Jerry Schwarz)
+ Path: cbosgd!mhuxj!mhuxt!eagle!jerry
+ Newsgroups: news.announce
+ Subject: Notes on Etiquette message
+ Message-ID: <64...@eagle.ATT.COM>
+ Date: Fri, 19 Nov 82 17:24:12 EST
+ Approved: mark@cbosgd.ATT.COM
+
+ There was something I forgot to mention in the last
+ message.
+
+ Batched news is recognized because the first character in the
+ message is #. The message is then passed to the unbatcher for
+ interpretation.
+
+ The second argument (in this example rnews) determines which
+ batching scheme is being used. Cooperating hosts may use whatever
+ scheme is appropriate for them.
+
+5. The News Propagation Algorithm
+
+ This section describes the overall scheme of USENET and the
+ algorithm followed by hosts in propagating news to the entire
+ logical network. Since all hosts are affected by incorrectly
+ formatted messages and by propagation errors, it is important
+ for the method to be standardized.
+
+ USENET is a directed graph. Each node in the graph is a host
+ computer, and each arc in the graph is a transmission path from
+ one host to another host. Each arc is labeled with a newsgroup
+ pattern, specifying which newsgroup classes are forwarded along
+ that link. Most arcs are bidirectional, that is, if host A
+ sends a class of newsgroups to host B, then host B usually sends
+ the same class of newsgroups to host A. This bidirectionality
+ is not, however, required.
+
+ USENET is made up of many subnetworks. Each subnet has a name, such
+
+
+
+Horton & Adams [Page 18]
+
+RFC 1036 Standard for USENET Messages December 1987
+
+
+ as comp or btl. Each subnet is a connected graph, that is, a path
+ exists from every node to every other node in the subnet. In
+ addition, the entire graph is (theoretically) connected. (In
+ practice, some political considerations have caused some hosts to be
+ unable to post messages reaching the rest of the network.)
+
+ A message is posted on one machine to a list of newsgroups. That
+ machine accepts it locally, then forwards it to all its neighbors
+ that are interested in at least one of the newsgroups of the
+ message. (Site A deems host B to be "interested" in a newsgroup if
+ the newsgroup matches the pattern on the arc from A to B. This
+ pattern is stored in a file on the A machine.) The hosts receiving
+ the incoming message examine it to make sure they really want the
+ message, accept it locally, and then in turn forward the message to
+ all their interested neighbors. This process continues until the
+ entire network has seen the message.
+
+ An important part of the algorithm is the prevention of loops. The
+ above process would cause a message to loop along a cycle forever.
+ In particular, when host A sends a message to host B, host B will
+ send it back to host A, which will send it to host B, and so on.
+ One solution to this is the history mechanism. Each host keeps
+ track of all messages it has seen (by their Message-ID) and
+ whenever a message comes in that it has already seen, the incoming
+ message is discarded immediately. This solution is sufficient to
+ prevent loops, but additional optimizations can be made to avoid
+ sending messages to hosts that will simply throw them away.
+
+ One optimization is that a message should never be sent to a machine
+ listed in the "Path" line of the header. When a machine name is
+ in the "Path" line, the message is known to have passed through the
+ machine. Another optimization is that, if the message originated
+ on host A, then host A has already seen the message. Thus, if a
+ message is posted to newsgroup misc.misc, it will match the pattern
+ misc.all (where all is a metasymbol that matches any string), and
+ will be forwarded to all hosts that subscribe to misc.all (as
+ determined by what their neighbors send them). These hosts make up
+ the misc subnetwork. A message posted to btl.general will reach all
+ hosts receiving btl.all, but will not reach hosts that do not get
+ btl.all. In effect, the messages reaches the btl subnetwork. A
+ messages posted to newsgroups misc.misc,btl.general will reach all
+ hosts subscribing to either of the two classes.
+
+Notes
+
+ <1> UNIX is a registered trademark of AT&T.
+
+
+
+
+
+Horton & Adams [Page 19]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/nntp/rfc1036.txt
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org