(Corrections, notes, and links for Usenet RKT.)
by Mib Software, INN customization and consulting
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, 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: <642@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 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.
RFC1036 2.1.1. From
RFC1036 2.1.2. Date
RFC1036 2.1.3. Newsgroups
RFC1036 2.1.4. Subject
RFC1036 2.1.5. Message-ID
RFC1036 2.1.6. Path
RFC1036 2.2.1. Reply-To
RFC1036 2.2.2. Sender
RFC1036 2.2.3. Followup-To
RFC1036 2.2.4. Expires
RFC1036 2.2.5. References
RFC1036 2.2.6. Control
RFC1036 2.2.7. Distribution
RFC1036 2.2.8. Organization
RFC1036 2.2.9. Keywords
RFC1036 2.2.10. Summary
RFC1036 2.2.11. Approved
RFC1036 2.2.12. Lines
RFC1036 2.2.13. Xref
RFC1036: [Source:"RFC-1036"] [Last Changed:December 1987] [Copyright: 1987 M. Horton, R. Adams]
RFC-1036:[Previous][Up to Table of Contents] [Next]
-B-r-o-a-d-e-n- your knowledgeUp to RFC1036