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 hb...@apache.org on 2001/04/05 11:51:26 UTC
cvs commit: jakarta-james/docs/rfclist rfc977.txt rfc822.txt rfc1036.txt README draft-ietf-nntpext-base-13.txt
hbedi 01/04/05 02:51:25
Added: docs/rfclist rfc977.txt rfc822.txt rfc1036.txt README
draft-ietf-nntpext-base-13.txt
Log:
RFC and drafts relevant to James
Revision Changes Path
1.1 jakarta-james/docs/rfclist/rfc977.txt
Index: rfc977.txt
===================================================================
Network Working Group Brian Kantor (U.C. San Diego)
Request for Comments: 977 Phil Lapsley (U.C. Berkeley)
February 1986
Network News Transfer Protocol
A Proposed Standard for the Stream-Based
Transmission of News
Status of This Memo
NNTP specifies a protocol for the distribution, inquiry, retrieval,
and posting of news articles using a reliable stream-based
transmission of news among the ARPA-Internet community. NNTP is
designed so that news articles are stored in a central database
allowing a subscriber to select only those items he wishes to read.
Indexing, cross-referencing, and expiration of aged messages are also
provided. This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
1. Introduction
For many years, the ARPA-Internet community has supported the
distribution of bulletins, information, and data in a timely fashion
to thousands of participants. We collectively refer to such items of
information as "news". Such news provides for the rapid
dissemination of items of interest such as software bug fixes, new
product reviews, technical tips, and programming pointers, as well as
rapid-fire discussions of matters of concern to the working computer
professional. News is very popular among its readers.
There are popularly two methods of distributing such news: the
Internet method of direct mailing, and the USENET news system.
1.1. Internet Mailing Lists
The Internet community distributes news by the use of mailing lists.
These are lists of subscriber's mailbox addresses and remailing
sublists of all intended recipients. These mailing lists operate by
remailing a copy of the information to be distributed to each
subscriber on the mailing list. Such remailing is inefficient when a
mailing list grows beyond a dozen or so people, since sending a
separate copy to each of the subscribers occupies large quantities of
network bandwidth, CPU resources, and significant amounts of disk
storage at the destination host. There is also a significant problem
in maintenance of the list itself: as subscribers move from one job
to another; as new subscribers join and old ones leave; and as hosts
come in and out of service.
Kantor & Lapsley [Page 1]
RFC 977 February 1986
Network News Transfer Protocol
1.2. The USENET News System
Clearly, a worthwhile reduction of the amount of these resources used
can be achieved if articles are stored in a central database on the
receiving host instead of in each subscriber's mailbox. The USENET
news system provides a method of doing just this. There is a central
repository of the news articles in one place (customarily a spool
directory of some sort), and a set of programs that allow a
subscriber to select those items he wishes to read. Indexing,
cross-referencing, and expiration of aged messages are also provided.
1.3. Central Storage of News
For clusters of hosts connected together by fast local area networks
(such as Ethernet), it makes even more sense to consolidate news
distribution onto one (or a very few) hosts, and to allow access to
these news articles using a server and client model. Subscribers may
then request only the articles they wish to see, without having to
wastefully duplicate the storage of a copy of each item on each host.
1.4. A Central News Server
A way to achieve these economies is to have a central computer system
that can provide news service to the other systems on the local area
network. Such a server would manage the collection of news articles
and index files, with each person who desires to read news bulletins
doing so over the LAN. For a large cluster of computer systems, the
savings in total disk space is clearly worthwhile. Also, this allows
workstations with limited disk storage space to participate in the
news without incoming items consuming oppressive amounts of the
workstation's disk storage.
We have heard rumors of somewhat successful attempts to provide
centralized news service using IBIS and other shared or distributed
file systems. While it is possible that such a distributed file
system implementation might work well with a group of similar
computers running nearly identical operating systems, such a scheme
is not general enough to offer service to a wide range of client
systems, especially when many diverse operating systems may be in use
among a group of clients. There are few (if any) shared or networked
file systems that can offer the generality of service that stream
connections using Internet TCP provide, particularly when a wide
range of host hardware and operating systems are considered.
NNTP specifies a protocol for the distribution, inquiry, retrieval,
and posting of news articles using a reliable stream (such as TCP)
server-client model. NNTP is designed so that news articles need only
Kantor & Lapsley [Page 2]
RFC 977 February 1986
Network News Transfer Protocol
be stored on one (presumably central) host, and subscribers on other
hosts attached to the LAN may read news articles using stream
connections to the news host.
NNTP is modelled upon the news article specifications in RFC 850,
which describes the USENET news system. However, NNTP makes few
demands upon the structure, content, or storage of news articles, and
thus we believe it easily can be adapted to other non-USENET news
systems.
Typically, the NNTP server runs as a background process on one host,
and would accept connections from other hosts on the LAN. This works
well when there are a number of small computer systems (such as
workstations, with only one or at most a few users each), and a large
central server.
1.5. Intermediate News Servers
For clusters of machines with many users (as might be the case in a
university or large industrial environment), an intermediate server
might be used. This intermediate or "slave" server runs on each
computer system, and is responsible for mediating news reading
requests and performing local caching of recently-retrieved news
articles.
Typically, a client attempting to obtain news service would first
attempt to connect to the news service port on the local machine. If
this attempt were unsuccessful, indicating a failed server, an
installation might choose to either deny news access, or to permit
connection to the central "master" news server.
For workstations or other small systems, direct connection to the
master server would probably be the normal manner of operation.
This specification does not cover the operation of slave NNTP
servers. We merely suggest that slave servers are a logical addition
to NNTP server usage which would enhance operation on large local
area networks.
1.6. News Distribution
NNTP has commands which provide a straightforward method of
exchanging articles between cooperating hosts. Hosts which are well
connected on a local area or other fast network and who wish to
actually obtain copies of news articles for local storage might well
find NNTP to be a more efficient way to distribute news than more
traditional transfer methods (such as UUCP).
Kantor & Lapsley [Page 3]
RFC 977 February 1986
Network News Transfer Protocol
In the traditional method of distributing news articles, news is
propagated from host to host by flooding - that is, each host will
send all its new news articles on to each host that it feeds. These
hosts will then in turn send these new articles on to other hosts
that they feed. Clearly, sending articles that a host already has
obtained a copy of from another feed (many hosts that receive news
are redundantly fed) again is a waste of time and communications
resources, but for transport mechanisms that are single-transaction
based rather than interactive (such as UUCP in the UNIX-world <1>),
distribution time is diminished by sending all articles and having
the receiving host simply discard the duplicates. This is an
especially true when communications sessions are limited to once a
day.
Using NNTP, hosts exchanging news articles have an interactive
mechanism for deciding which articles are to be transmitted. A host
desiring new news, or which has new news to send, will typically
contact one or more of its neighbors using NNTP. First it will
inquire if any new news groups have been created on the serving host
by means of the NEWGROUPS command. If so, and those are appropriate
or desired (as established by local site-dependent rules), those new
newsgroups can be created.
The client host will then inquire as to which new articles have
arrived in all or some of the newsgroups that it desires to receive,
using the NEWNEWS command. It will receive a list of new articles
from the server, and can request transmission of those articles that
it desires and does not already have.
Finally, the client can advise the server of those new articles which
the client has recently received. The server will indicate those
articles that it has already obtained copies of, and which articles
should be sent to add to its collection.
In this manner, only those articles which are not duplicates and
which are desired are transferred.
Kantor & Lapsley [Page 4]
RFC 977 February 1986
Network News Transfer Protocol
2. The NNTP Specification
2.1. Overview
The news server specified by this document uses a stream connection
(such as TCP) and SMTP-like commands and responses. It is designed
to accept connections from hosts, and to provide a simple interface
to the news database.
This server is only an interface between programs and the news
databases. It does not perform any user interaction or presentation-
level functions. These "user-friendly" functions are better left to
the client programs, which have a better understanding of the
environment in which they are operating.
When used via Internet TCP, the contact port assigned for this
service is 119.
2.2. Character Codes
Commands and replies are composed of characters from the ASCII
character set. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.
2.3. Commands
Commands consist of a command word, which in some cases may be
followed by a parameter. Commands with parameters must separate the
parameters from each other and from the command by one or more space
or tab characters. Command lines must be complete with all required
parameters, and may not contain more than one command.
Commands and command parameters are not case sensitive. That is, a
command or parameter word may be upper case, lower case, or any
mixture of upper and lower case.
Each command line must be terminated by a CR-LF (Carriage Return -
Line Feed) pair.
Command lines shall not exceed 512 characters in length, counting all
characters including spaces, separators, punctuation, and the
trailing CR-LF (thus there are 510 characters maximum allowed for the
command and its parameters). There is no provision for continuation
command lines.
Kantor & Lapsley [Page 5]
RFC 977 February 1986
Network News Transfer Protocol
2.4. Responses
Responses are of two kinds, textual and status.
2.4.1. Text Responses
Text is sent only after a numeric status response line has been sent
that indicates that text will follow. Text is sent as a series of
successive lines of textual matter, each terminated with CR-LF pair.
A single line containing only a period (.) is sent to indicate the
end of the text (i.e., the server will send a CR-LF pair at the end
of the last line of text, a period, and another CR-LF pair).
If the text contained a period as the first character of the text
line in the original, that first period is doubled. Therefore, the
client must examine the first character of each line received, and
for those beginning with a period, determine either that this is the
end of the text or whether to collapse the doubled period to a single
one.
The intention is that text messages will usually be displayed on the
user's terminal whereas command/status responses will be interpreted
by the client program before any possible display is done.
2.4.2. Status Responses
These are status reports from the server and indicate the response to
the last command received from the client.
Status response lines begin with a 3 digit numeric code which is
sufficient to distinguish all responses. Some of these may herald
the subsequent transmission of text.
The first digit of the response broadly indicates the success,
failure, or progress of the previous command.
1xx - Informative message
2xx - Command ok
3xx - Command ok so far, send the rest of it.
4xx - Command was correct, but couldn't be performed for
some reason.
5xx - Command unimplemented, or incorrect, or a serious
program error occurred.
Kantor & Lapsley [Page 6]
RFC 977 February 1986
Network News Transfer Protocol
The next digit in the code indicates the function response category.
x0x - Connection, setup, and miscellaneous messages
x1x - Newsgroup selection
x2x - Article selection
x3x - Distribution functions
x4x - Posting
x8x - Nonstandard (private implementation) extensions
x9x - Debugging output
The exact response codes that should be expected from each command
are detailed in the description of that command. In addition, below
is listed a general set of response codes that may be received at any
time.
Certain status responses contain parameters such as numbers and
names. The number and type of such parameters is fixed for each
response code to simplify interpretation of the response.
Parameters are separated from the numeric response code and from each
other by a single space. All numeric parameters are decimal, and may
have leading zeros. All string parameters begin after the separating
space, and end before the following separating space or the CR-LF
pair at the end of the line. (String parameters may not, therefore,
contain spaces.) All text, if any, in the response which is not a
parameter of the response must follow and be separated from the last
parameter by a space. Also, note that the text following a response
number may vary in different implementations of the server. The
3-digit numeric code should be used to determine what response was
sent.
Response codes not specified in this standard may be used for any
installation-specific additional commands also not specified. These
should be chosen to fit the pattern of x8x specified above. (Note
that debugging is provided for explicitly in the x9x response codes.)
The use of unspecified response codes for standard commands is
prohibited.
We have provided a response pattern x9x for debugging. Since much
debugging output may be classed as "informative messages", we would
expect, therefore, that responses 190 through 199 would be used for
various debugging outputs. There is no requirement in this
specification for debugging output, but if such is provided over the
connected stream, it must use these response codes. If appropriate
to a specific implementation, other x9x codes may be used for
debugging. (An example might be to use e.g., 290 to acknowledge a
remote debugging request.)
Kantor & Lapsley [Page 7]
RFC 977 February 1986
Network News Transfer Protocol
2.4.3. General Responses
The following is a list of general response codes that may be sent by
the NNTP server. These are not specific to any one command, but may
be returned as the result of a connection, a failure, or some unusual
condition.
In general, 1xx codes may be ignored or displayed as desired; code
200 or 201 is sent upon initial connection to the NNTP server
depending upon posting permission; code 400 will be sent when the
NNTP server discontinues service (by operator request, for example);
and 5xx codes indicate that the command could not be performed for
some unusual reason.
100 help text
190
through
199 debug output
200 server ready - posting allowed
201 server ready - no posting allowed
400 service discontinued
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
3. Command and Response Details
On the following pages are descriptions of each command recognized by
the NNTP server and the responses which will be returned by those
commands.
Each command is shown in upper case for clarity, although case is
ignored in the interpretation of commands by the NNTP server. Any
parameters are shown in lower case. A parameter shown in [square
brackets] is optional. For example, [GMT] indicates that the
triglyph GMT may present or omitted.
Every command described in this section must be implemented by all
NNTP servers.
Kantor & Lapsley [Page 8]
RFC 977 February 1986
Network News Transfer Protocol
There is no prohibition against additional commands being added;
however, it is recommended that any such unspecified command begin
with the letter "X" to avoid conflict with later revisions of this
specification.
Implementors are reminded that such additional commands may not
redefine specified status response codes. Using additional
unspecified responses for standard commands is also prohibited.
3.1. The ARTICLE, BODY, HEAD, and STAT commands
There are two forms to the ARTICLE command (and the related BODY,
HEAD, and STAT commands), each using a different method of specifying
which article is to be retrieved. When the ARTICLE command is
followed by a message-id in angle brackets ("<" and ">"), the first
form of the command is used; when a numeric parameter or no parameter
is supplied, the second form is invoked.
The text of the article is returned as a textual response, as
described earlier in this document.
The HEAD and BODY commands are identical to the ARTICLE command
except that they respectively return only the header lines or text
body of the article.
The STAT command is similar to the ARTICLE command except that no
text is returned. When selecting by message number within a group,
the STAT command serves to set the current article pointer without
sending text. The returned acknowledgement response will contain the
message-id, which may be of some value. Using the STAT command to
select by message-id is valid but of questionable value, since a
selection by message-id does NOT alter the "current article pointer".
3.1.1. ARTICLE (selection by message-id)
ARTICLE <message-id>
Display the header, a blank line, then the body (text) of the
specified article. Message-id is the message id of an article as
shown in that article's header. It is anticipated that the client
will obtain the message-id from a list provided by the NEWNEWS
command, from references contained within another article, or from
the message-id provided in the response to some other commands.
Please note that the internally-maintained "current article pointer"
is NOT ALTERED by this command. This is both to facilitate the
presentation of articles that may be referenced within an article
Kantor & Lapsley [Page 9]
RFC 977 February 1986
Network News Transfer Protocol
being read, and because of the semantic difficulties of determining
the proper sequence and membership of an article which may have been
posted to more than one newsgroup.
3.1.2. ARTICLE (selection by number)
ARTICLE [nnn]
Displays the header, a blank line, then the body (text) of the
current or specified article. The optional parameter nnn is the
numeric id of an article in the current newsgroup and must be chosen
from the range of articles provided when the newsgroup was selected.
If it is omitted, the current article is assumed.
The internally-maintained "current article pointer" is set by this
command if a valid article number is specified.
[the following applies to both forms of the article command.] A
response indicating the current article number, a message-id string,
and that text is to follow will be returned.
The message-id string returned is an identification string contained
within angle brackets ("<" and ">"), which is derived from the header
of the article itself. The Message-ID header line (required by
RFC850) from the article must be used to supply this information. If
the message-id header line is missing from the article, a single
digit "0" (zero) should be supplied within the angle brackets.
Since the message-id field is unique with each article, it may be
used by a news reading program to skip duplicate displays of articles
that have been posted more than once, or to more than one newsgroup.
3.1.3. Responses
220 n <a> article retrieved - head and body follow
(n = article number, <a> = message-id)
221 n <a> article retrieved - head follows
222 n <a> article retrieved - body follows
223 n <a> article retrieved - request text separately
412 no newsgroup has been selected
420 no current article has been selected
423 no such article number in this group
430 no such article found
Kantor & Lapsley [Page 10]
RFC 977 February 1986
Network News Transfer Protocol
3.2. The GROUP command
3.2.1. GROUP
GROUP ggg
The required parameter ggg is the name of the newsgroup to be
selected (e.g. "net.news"). A list of valid newsgroups may be
obtained from the LIST command.
The successful selection response will return the article numbers of
the first and last articles in the group, and an estimate of the
number of articles on file in the group. It is not necessary that
the estimate be correct, although that is helpful; it must only be
equal to or larger than the actual number of articles on file. (Some
implementations will actually count the number of articles on file.
Others will just subtract first article number from last to get an
estimate.)
When a valid group is selected by means of this command, the
internally maintained "current article pointer" is set to the first
article in the group. If an invalid group is specified, the
previously selected group and article remain selected. If an empty
newsgroup is selected, the "current article pointer" is in an
indeterminate state and should not be used.
Note that the name of the newsgroup is not case-dependent. It must
otherwise match a newsgroup obtained from the LIST command or an
error will result.
3.2.2. Responses
211 n f l s group selected
(n = estimated number of articles in group,
f = first article number in the group,
l = last article number in the group,
s = name of the group.)
411 no such news group
Kantor & Lapsley [Page 11]
RFC 977 February 1986
Network News Transfer Protocol
3.3. The HELP command
3.3.1. HELP
HELP
Provides a short summary of commands that are understood by this
implementation of the server. The help text will be presented as a
textual response, terminated by a single period on a line by itself.
3.3.2. Responses
100 help text follows
3.4. The IHAVE command
3.4.1. IHAVE
IHAVE <messageid>
The IHAVE command informs the server that the client has an article
whose id is <messageid>. If the server desires a copy of that
article, it will return a response instructing the client to send the
entire article. If the server does not want the article (if, for
example, the server already has a copy of it), a response indicating
that the article is not wanted will be returned.
If transmission of the article is requested, the client should send
the entire article, including header and body, in the manner
specified for text transmission from the server. A response code
indicating success or failure of the transferral of the article will
be returned.
This function differs from the POST command in that it is intended
for use in transferring already-posted articles between hosts.
Normally it will not be used when the client is a personal
newsreading program. In particular, this function will invoke the
server's news posting program with the appropriate settings (flags,
options, etc) to indicate that the forthcoming article is being
forwarded from another host.
The server may, however, elect not to post or forward the article if
after further examination of the article it deems it inappropriate to
do so. The 436 or 437 error codes may be returned as appropriate to
the situation.
Reasons for such subsequent rejection of an article may include such
Kantor & Lapsley [Page 12]
RFC 977 February 1986
Network News Transfer Protocol
problems as inappropriate newsgroups or distributions, disk space
limitations, article lengths, garbled headers, and the like. These
are typically restrictions enforced by the server host's news
software and not necessarily the NNTP server itself.
3.4.2. Responses
235 article transferred ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again
An implementation note:
Because some host news posting software may not be able to decide
immediately that an article is inappropriate for posting or
forwarding, it is acceptable to acknowledge the successful transfer
of the article and to later silently discard it. Thus it is
permitted to return the 235 acknowledgement code and later discard
the received article. This is not a fully satisfactory solution to
the problem. Perhaps some implementations will wish to send mail to
the author of the article in certain of these cases.
3.5. The LAST command
3.5.1. LAST
LAST
The internally maintained "current article pointer" is set to the
previous article in the current newsgroup. If already positioned at
the first article of the newsgroup, an error message is returned and
the current article remains selected.
The internally-maintained "current article pointer" is set by this
command.
A response indicating the current article number, and a message-id
string will be returned. No text is sent in response to this
command.
3.5.2. Responses
223 n a article retrieved - request text separately
(n = article number, a = unique article id)
Kantor & Lapsley [Page 13]
RFC 977 February 1986
Network News Transfer Protocol
412 no newsgroup selected
420 no current article has been selected
422 no previous article in this group
3.6. The LIST command
3.6.1. LIST
LIST
Returns a list of valid newsgroups and associated information. Each
newsgroup is sent as a line of text in the following format:
group last first p
where <group> is the name of the newsgroup, <last> is the number of
the last known article currently in that newsgroup, <first> is the
number of the first article currently in the newsgroup, and <p> is
either 'y' or 'n' indicating whether posting to this newsgroup is
allowed ('y') or prohibited ('n').
The <first> and <last> fields will always be numeric. They may have
leading zeros. If the <last> field evaluates to less than the
<first> field, there are no articles currently on file in the
newsgroup.
Note that posting may still be prohibited to a client even though the
LIST command indicates that posting is permitted to a particular
newsgroup. See the POST command for an explanation of client
prohibitions. The posting flag exists for each newsgroup because
some newsgroups are moderated or are digests, and therefore cannot be
posted to; that is, articles posted to them must be mailed to a
moderator who will post them for the submitter. This is independent
of the posting permission granted to a client by the NNTP server.
Please note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible valid
response, and indicates that there are currently no valid newsgroups.
3.6.2. Responses
215 list of newsgroups follows
Kantor & Lapsley [Page 14]
RFC 977 February 1986
Network News Transfer Protocol
3.7. The NEWGROUPS command
3.7.1. NEWGROUPS
NEWGROUPS date time [GMT] [<distributions>]
A list of newsgroups created since <date and time> will be listed in
the same format as the LIST command.
The date is sent as 6 digits in the format YYMMDD, where YY is the
last two digits of the year, MM is the two digits of the month (with
leading zero, if appropriate), and DD is the day of the month (with
leading zero, if appropriate). The closest century is assumed as
part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
1999, 00 is 2000).
Time must also be specified. It must be as 6 digits HHMMSS with HH
being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
00-59. The time is assumed to be in the server's timezone unless the
token "GMT" appears, in which case both time and date are evaluated
at the 0 meridian.
The optional parameter "distributions" is a list of distribution
groups, enclosed in angle brackets. If specified, the distribution
portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
examined for a match with the distribution categories listed, and
only those new newsgroups which match will be listed. If more than
one distribution group is to be listed, they must be separated by
commas within the angle brackets.
Please note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible valid
response, and indicates that there are currently no new newsgroups.
3.7.2. Responses
231 list of new newsgroups follows
Kantor & Lapsley [Page 15]
RFC 977 February 1986
Network News Transfer Protocol
3.8. The NEWNEWS command
3.8.1. NEWNEWS
NEWNEWS newsgroups date time [GMT] [<distribution>]
A list of message-ids of articles posted or received to the specified
newsgroup since "date" will be listed. The format of the listing will
be one message-id per line, as though text were being sent. A single
line consisting solely of one period followed by CR-LF will terminate
the list.
Date and time are in the same format as the NEWGROUPS command.
A newsgroup name containing a "*" (an asterisk) may be specified to
broaden the article search to some or all newsgroups. The asterisk
will be extended to match any part of a newsgroup name (e.g.,
net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
if only an asterisk is given as the newsgroup name, all newsgroups
will be searched for new news.
(Please note that the asterisk "*" expansion is a general
replacement; in particular, the specification of e.g., net.*.unix
should be correctly expanded to embrace names such as net.wombat.unix
and net.whocares.unix.)
Conversely, if no asterisk appears in a given newsgroup name, only
the specified newsgroup will be searched for new articles. Newsgroup
names must be chosen from those returned in the listing of available
groups. Multiple newsgroup names (including a "*") may be specified
in this command, separated by a comma. No comma shall appear after
the last newsgroup in the list. [Implementors are cautioned to keep
the 512 character command length limit in mind.]
The exclamation point ("!") may be used to negate a match. This can
be used to selectively omit certain newsgroups from an otherwise
larger list. For example, a newsgroups specification of
"net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
matched. If used, the exclamation point must appear as the first
character of the given newsgroup name or pattern.
The optional parameter "distributions" is a list of distribution
groups, enclosed in angle brackets. If specified, the distribution
portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
be examined for a match with the distribution categories listed, and
only those articles which have at least one newsgroup belonging to
Kantor & Lapsley [Page 16]
RFC 977 February 1986
Network News Transfer Protocol
the list of distributions will be listed. If more than one
distribution group is to be supplied, they must be separated by
commas within the angle brackets.
The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
news is discussed in an earlier part of this document.
Please note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible valid
response, and indicates that there is currently no new news.
3.8.2. Responses
230 list of new articles by message-id follows
3.9. The NEXT command
3.9.1. NEXT
NEXT
The internally maintained "current article pointer" is advanced to
the next article in the current newsgroup. If no more articles
remain in the current group, an error message is returned and the
current article remains selected.
The internally-maintained "current article pointer" is set by this
command.
A response indicating the current article number, and the message-id
string will be returned. No text is sent in response to this
command.
3.9.2. Responses
223 n a article retrieved - request text separately
(n = article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
421 no next article in this group
Kantor & Lapsley [Page 17]
RFC 977 February 1986
Network News Transfer Protocol
3.10. The POST command
3.10.1. POST
POST
If posting is allowed, response code 340 is returned to indicate that
the article to be posted should be sent. Response code 440 indicates
that posting is prohibited for some installation-dependent reason.
If posting is permitted, the article should be presented in the
format specified by RFC850, and should include all required header
lines. After the article's header and body have been completely sent
by the client to the server, a further response code will be returned
to indicate success or failure of the posting attempt.
The text forming the header and body of the message to be posted
should be sent by the client using the conventions for text received
from the news server: A single period (".") on a line indicates the
end of the text, with lines starting with a period in the original
text having that period doubled during transmission.
No attempt shall be made by the server to filter characters, fold or
limit lines, or otherwise process incoming text. It is our intent
that the server just pass the incoming message to be posted to the
server installation's news posting software, which is separate from
this specification. See RFC850 for more details.
Since most installations will want the client news program to allow
the user to prepare his message using some sort of text editor, and
transmit it to the server for posting only after it is composed, the
client program should take note of the herald message that greeted it
when the connection was first established. This message indicates
whether postings from that client are permitted or not, and can be
used to caution the user that his access is read-only if that is the
case. This will prevent the user from wasting a good deal of time
composing a message only to find posting of the message was denied.
The method and determination of which clients and hosts may post is
installation dependent and is not covered by this specification.
3.10.2. Responses
240 article posted ok
340 send article to be posted. End with <CR-LF>.<CR-LF>
440 posting not allowed
441 posting failed
Kantor & Lapsley [Page 18]
RFC 977 February 1986
Network News Transfer Protocol
(for reference, one of the following codes will be sent upon initial
connection; the client program should determine whether posting is
generally permitted from these:) 200 server ready - posting allowed
201 server ready - no posting allowed
3.11. The QUIT command
3.11.1. QUIT
QUIT
The server process acknowledges the QUIT command and then closes the
connection to the client. This is the preferred method for a client
to indicate that it has finished all its transactions with the NNTP
server.
If a client simply disconnects (or the connection times out, or some
other fault occurs), the server should gracefully cease its attempts
to service the client.
3.11.2. Responses
205 closing connection - goodbye!
3.12. The SLAVE command
3.12.1. SLAVE
SLAVE
Indicates to the server that this client connection is to a slave
server, rather than a user.
This command is intended for use in separating connections to single
users from those to subsidiary ("slave") servers. It may be used to
indicate that priority should therefore be given to requests from
this client, as it is presumably serving more than one person. It
might also be used to determine which connections to close when
system load levels are exceeded, perhaps giving preference to slave
servers. The actual use this command is put to is entirely
implementation dependent, and may vary from one host to another. In
NNTP servers which do not give priority to slave servers, this
command must nonetheless be recognized and acknowledged.
3.12.2. Responses
202 slave status noted
Kantor & Lapsley [Page 19]
RFC 977 February 1986
Network News Transfer Protocol
4. Sample Conversations
These are samples of the conversations that might be expected with
the news server in hypothetical sessions. The notation C: indicates
commands sent to the news server from the client program; S: indicate
responses received from the server by the client.
4.1. Example 1 - relative access with NEXT
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 wombatvax news server ready - posting ok
(client asks for a current newsgroup list)
C: LIST
S: 215 list of newsgroups follows
S: net.wombats 00543 00501 y
S: net.unix-wizards 10125 10011 y
(more information here)
S: net.idiots 00100 00001 n
S: .
(client selects a newsgroup)
C: GROUP net.unix-wizards
S: 211 104 10011 10125 net.unix-wizards group selected
(there are 104 articles on file, from 10011 to 10125)
(client selects an article to read)
C: STAT 10110
S: 223 10110 <23...@sdcsvax.ARPA> article retrieved - statistics
only (article 10110 selected, its message-id is
<23...@sdcsvax.ARPA>)
(client examines the header)
C: HEAD
S: 221 10110 <23...@sdcsvax.ARPA> article retrieved - head
follows (text of the header appears here)
S: .
(client wants to see the text body of the article)
C: BODY
S: 222 10110 <23...@sdcsvax.ARPA> article retrieved - body
follows (body text here)
S: .
(client selects next article in group)
Kantor & Lapsley [Page 20]
RFC 977 February 1986
Network News Transfer Protocol
C: NEXT
S: 223 10113 <21...@nudebch.uucp> article retrieved - statistics
only (article 10113 was next in group)
(client finishes session)
C: QUIT
S: 205 goodbye.
4.2. Example 2 - absolute article access with ARTICLE
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 UCB-VAX netnews server ready -- no posting allowed
C: GROUP msgs
S: 211 103 402 504 msgs Your new group is msgs
(there are 103 articles, from 402 to 504)
C: ARTICLE 401
S: 423 No such article in this newsgroup
C: ARTICLE 402
S: 220 402 <41...@ucbvax.ARPA> Article retrieved, text follows
S: (article header and body follow)
S: .
C: HEAD 403
S: 221 403 <31...@mcvax.UUCP> Article retrieved, header follows
S: (article header follows)
S: .
C: QUIT
S: 205 UCB-VAX news server closing connection. Goodbye.
4.3. Example 3 - NEWGROUPS command
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 Imaginary Institute News Server ready (posting ok)
(client asks for new newsgroups since April 3, 1985)
C: NEWGROUPS 850403 020000
S: 231 New newsgroups since 03/04/85 02:00:00 follow
Kantor & Lapsley [Page 21]
RFC 977 February 1986
Network News Transfer Protocol
S: net.music.gdead
S: net.games.sources
S: .
C: GROUP net.music.gdead
S: 211 0 1 1 net.music.gdead Newsgroup selected
(there are no articles in that newsgroup, and
the first and last article numbers should be ignored)
C: QUIT
S: 205 Imaginary Institute news server ceasing service. Bye!
4.4. Example 4 - posting a news article
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 BANZAIVAX news server ready, posting allowed.
C: POST
S: 340 Continue posting; Period on a line by itself to end
C: (transmits news article in RFC850 format)
C: .
S: 240 Article posted successfully.
C: QUIT
S: 205 BANZAIVAX closing connection. Goodbye.
4.5. Example 5 - interruption due to operator request
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 genericvax news server ready, no posting allowed.
(assume normal conversation for some time, and
that a newsgroup has been selected)
C: NEXT
S: 223 1013 <57...@mcvax.UUCP> Article retrieved; text separate.
C: HEAD
C: 221 1013 <57...@mcvax.UUCP> Article retrieved; head follows.
S: (sends head of article, but halfway through is
interrupted by an operator request. The following
then occurs, without client intervention.)
Kantor & Lapsley [Page 22]
RFC 977 February 1986
Network News Transfer Protocol
S: (ends current line with a CR-LF pair)
S: .
S: 400 Connection closed by operator. Goodbye.
S: (closes connection)
4.6. Example 6 - Using the news server to distribute news between
systems.
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 Foobar NNTP server ready (no posting)
(client asks for new newsgroups since 2 am, May 15, 1985)
C: NEWGROUPS 850515 020000
S: 235 New newsgroups since 850515 follow
S: net.fluff
S: net.lint
S: .
(client asks for new news articles since 2 am, May 15, 1985)
C: NEWNEWS * 850515 020000
S: 230 New news since 850515 020000 follows
S: <17...@foo.UUCP>
S: <87...@baz.UUCP>
S: <17...@GOLD.CSNET>
S: .
(client asks for article <17...@foo.UUCP>)
C: ARTICLE <17...@foo.UUCP>
S: 220 <17...@foo.UUCP> All of article follows
S: (sends entire message)
S: .
(client asks for article <87...@baz.UUCP>
C: ARTICLE <87...@baz.UUCP>
S: 220 <87...@baz.UUCP> All of article follows
S: (sends entire message)
S: .
(client asks for article <17...@GOLD.CSNET>
C: ARTICLE <17...@GOLD.CSNET>
S: 220 <17...@GOLD.CSNET> All of article follows
S: (sends entire message)
S: .
Kantor & Lapsley [Page 23]
RFC 977 February 1986
Network News Transfer Protocol
(client offers an article it has received recently)
C: IHAVE <41...@ucbvax.ARPA>
S: 435 Already seen that one, where you been?
(client offers another article)
C: IHAVE <41...@ucbvax.ARPA>
S: 335 News to me! <CRLF.CRLF> to end.
C: (sends article)
C: .
S: 235 Article transferred successfully. Thanks.
(or)
S: 436 Transfer failed.
(client is all through with the session)
C: QUIT
S: 205 Foobar NNTP server bids you farewell.
4.7. Summary of commands and responses.
The following are the commands recognized and responses returned by
the NNTP server.
4.7.1. Commands
ARTICLE
BODY
GROUP
HEAD
HELP
IHAVE
LAST
LIST
NEWGROUPS
NEWNEWS
NEXT
POST
QUIT
SLAVE
STAT
4.7.2. Responses
100 help text follows
199 debug output
Kantor & Lapsley [Page 24]
RFC 977 February 1986
Network News Transfer Protocol
200 server ready - posting allowed
201 server ready - no posting allowed
202 slave status noted
205 closing connection - goodbye!
211 n f l s group selected
215 list of newsgroups follows
220 n <a> article retrieved - head and body follow 221 n <a> article
retrieved - head follows
222 n <a> article retrieved - body follows
223 n <a> article retrieved - request text separately 230 list of new
articles by message-id follows
231 list of new newsgroups follows
235 article transferred ok
240 article posted ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
340 send article to be posted. End with <CR-LF>.<CR-LF>
400 service discontinued
411 no such news group
412 no newsgroup has been selected
420 no current article has been selected
421 no next article in this group
422 no previous article in this group
423 no such article number in this group
430 no such article found
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again.
440 posting not allowed
441 posting failed
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
4.8. A Brief Word about the USENET News System
In the UNIX world, which traditionally has been linked by 1200 baud
dial-up telephone lines, the USENET News system has evolved to handle
central storage, indexing, retrieval, and distribution of news. With
the exception of its underlying transport mechanism (UUCP), USENET
News is an efficient means of providing news and bulletin service to
subscribers on UNIX and other hosts worldwide. The USENET News
Kantor & Lapsley [Page 25]
RFC 977 February 1986
Network News Transfer Protocol
system is discussed in detail in RFC 850. It runs on most versions
of UNIX and on many other operating systems, and is customarily
distributed without charge.
USENET uses a spooling area on the UNIX host to store news articles,
one per file. Each article consists of a series of heading text,
which contain the sender's identification and organizational
affiliation, timestamps, electronic mail reply paths, subject,
newsgroup (subject category), and the like. A complete news article
is reproduced in its entirety below. Please consult RFC 850 for more
details.
Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
sdcsvax.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
!honman
From: honman@unitek.uucp (Man Wong)
Newsgroups: net.unix-wizards
Subject: foreground -> background ?
Message-ID: <16...@unitek.uucp>
Date: 25 Sep 85 23:51:52 GMT
Date-Received: 29 Sep 85 09:54:48 GMT
Reply-To: honman@unitek.UUCP (Hon-Man Wong)
Distribution: net.all
Organization: Unitek Technologies Corporation
Lines: 12
I have a process (C program) which generates a child and waits for
it to return. What I would like to do is to be able to run the
child process interactively for a while before kicking itself into
the background so I can return to the parent process (while the
child process is RUNNING in the background). Can it be done? And
if it can, how?
Please reply by E-mail. Thanks in advance.
Hon-Man Wong
Kantor & Lapsley [Page 26]
RFC 977 February 1986
Network News Transfer Protocol
5. References
[1] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC-822, Department of Electrical Engineering,
University of Delaware, August, 1982.
[2] Horton, M., "Standard for Interchange of USENET Messages",
RFC-850, USENET Project, June, 1983.
[3] Postel, J., "Transmission Control Protocol- DARPA Internet
Program Protocol Specification", RFC-793, USC/Information
Sciences Institute, September, 1981.
[4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
USC/Information Sciences Institute, August, 1982.
6. Acknowledgements
The authors wish to express their heartfelt thanks to those many
people who contributed to this specification, and especially to Erik
Fair and Chuq von Rospach, without whose inspiration this whole thing
would not have been necessary.
7. Notes
<1> UNIX is a trademark of Bell Laboratories.
Kantor & Lapsley [Page 27]
1.1 jakarta-james/docs/rfclist/rfc822.txt
Index: rfc822.txt
===================================================================
RFC # 822
Obsoletes: RFC #733 (NIC #41952)
STANDARD FOR THE FORMAT OF
ARPA INTERNET TEXT MESSAGES
August 13, 1982
Revised by
David H. Crocker
Dept. of Electrical Engineering
University of Delaware, Newark, DE 19711
Network: DCrocker @ UDel-Relay
Standard for ARPA Internet Text Messages
TABLE OF CONTENTS
PREFACE .................................................... ii
1. INTRODUCTION ........................................... 1
1.1. Scope ............................................ 1
1.2. Communication Framework .......................... 2
2. NOTATIONAL CONVENTIONS ................................. 3
3. LEXICAL ANALYSIS OF MESSAGES ........................... 5
3.1. General Description .............................. 5
3.2. Header Field Definitions ......................... 9
3.3. Lexical Tokens ................................... 10
3.4. Clarifications ................................... 11
4. MESSAGE SPECIFICATION .................................. 17
4.1. Syntax ........................................... 17
4.2. Forwarding ....................................... 19
4.3. Trace Fields ..................................... 20
4.4. Originator Fields ................................ 21
4.5. Receiver Fields .................................. 23
4.6. Reference Fields ................................. 23
4.7. Other Fields ..................................... 24
5. DATE AND TIME SPECIFICATION ............................ 26
5.1. Syntax ........................................... 26
5.2. Semantics ........................................ 26
6. ADDRESS SPECIFICATION .................................. 27
6.1. Syntax ........................................... 27
6.2. Semantics ........................................ 27
6.3. Reserved Address ................................. 33
7. BIBLIOGRAPHY ........................................... 34
APPENDIX
A. EXAMPLES ............................................... 36
B. SIMPLE FIELD PARSING ................................... 40
C. DIFFERENCES FROM RFC #733 .............................. 41
D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44
August 13, 1982 - i - RFC #822
Standard for ARPA Internet Text Messages
PREFACE
By 1977, the Arpanet employed several informal standards for
the text messages (mail) sent among its host computers. It was
felt necessary to codify these practices and provide for those
features that seemed imminent. The result of that effort was
Request for Comments (RFC) #733, "Standard for the Format of ARPA
Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
The specification attempted to avoid major changes in existing
software, while permitting several new features.
This document revises the specifications in RFC #733, in
order to serve the needs of the larger and more complex ARPA
Internet. Some of RFC #733's features failed to gain adequate
acceptance. In order to simplify the standard and the software
that follows it, these features have been removed. A different
addressing scheme is used, to handle the case of inter-network
mail; and the concept of re-transmission has been introduced.
This specification is intended for use in the ARPA Internet.
However, an attempt has been made to free it of any dependence on
that environment, so that it can be applied to other network text
message systems.
The specification of RFC #733 took place over the course of
one year, using the ARPANET mail environment, itself, to provide
an on-going forum for discussing the capabilities to be included.
More than twenty individuals, from across the country, partici-
pated in the original discussion. The development of this
revised specification has, similarly, utilized network mail-based
group discussion. Both specification efforts greatly benefited
from the comments and ideas of the participants.
The syntax of the standard, in RFC #733, was originally
specified in the Backus-Naur Form (BNF) meta-language. Ken L.
Harrenstien, of SRI International, was responsible for re-coding
the BNF into an augmented BNF that makes the representation
smaller and easier to understand.
August 13, 1982 - ii - RFC #822
Standard for ARPA Internet Text Messages
1. INTRODUCTION
1.1. SCOPE
This standard specifies a syntax for text messages that are
sent among computer users, within the framework of "electronic
mail". The standard supersedes the one specified in ARPANET
Request for Comments #733, "Standard for the Format of ARPA Net-
work Text Messages".
In this context, messages are viewed as having an envelope
and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. The contents
compose the object to be delivered to the recipient. This stan-
dard applies only to the format and some of the semantics of mes-
sage contents. It contains no specification of the information
in the envelope.
However, some message systems may use information from the
contents to create the envelope. It is intended that this stan-
dard facilitate the acquisition of such information by programs.
Some message systems may store messages in formats that
differ from the one specified in this standard. This specifica-
tion is intended strictly as a definition of what message content
format is to be passed BETWEEN hosts.
Note: This standard is NOT intended to dictate the internal for-
mats used by sites, the specific message system features
that they are expected to support, or any of the charac-
teristics of user interface programs that create or read
messages.
A distinction should be made between what the specification
REQUIRES and what it ALLOWS. Messages can be made complex and
rich with formally-structured components of information or can be
kept small and simple, with a minimum of such information. Also,
the standard simplifies the interpretation of differing visual
formats in messages; only the visual aspect of a message is
affected and not the interpretation of information within it.
Implementors may choose to retain such visual distinctions.
The formal definition is divided into four levels. The bot-
tom level describes the meta-notation used in this document. The
second level describes basic lexical analyzers that feed tokens
to higher-level parsers. Next is an overall specification for
messages; it permits distinguishing individual fields. Finally,
there is definition of the contents of several structured fields.
August 13, 1982 - 1 - RFC #822
Standard for ARPA Internet Text Messages
1.2. COMMUNICATION FRAMEWORK
Messages consist of lines of text. No special provisions
are made for encoding drawings, facsimile, speech, or structured
text. No significant consideration has been given to questions
of data compression or to transmission and storage efficiency,
and the standard tends to be free with the number of bits con-
sumed. For example, field names are specified as free text,
rather than special terse codes.
A general "memo" framework is used. That is, a message con-
sists of some information in a rigid format, followed by the main
part of the message, with a format that is not specified in this
document. The syntax of several fields of the rigidly-formated
("headers") section is defined in this specification; some of
these fields must be included in all messages.
The syntax that distinguishes between header fields is
specified separately from the internal syntax for particular
fields. This separation is intended to allow simple parsers to
operate on the general structure of messages, without concern for
the detailed structure of individual header fields. Appendix B
is provided to facilitate construction of these parsers.
In addition to the fields specified in this document, it is
expected that other fields will gain common use. As necessary,
the specifications for these "extension-fields" will be published
through the same mechanism used to publish this document. Users
may also wish to extend the set of fields that they use
privately. Such "user-defined fields" are permitted.
The framework severely constrains document tone and appear-
ance and is primarily useful for most intra-organization communi-
cations and well-structured inter-organization communication.
It also can be used for some types of inter-process communica-
tion, such as simple file transfer and remote job entry. A more
robust framework might allow for multi-font, multi-color, multi-
dimension encoding of information. A less robust one, as is
present in most single-machine message systems, would more
severely constrain the ability to add fields and the decision to
include specific fields. In contrast with paper-based communica-
tion, it is interesting to note that the RECEIVER of a message
can exercise an extraordinary amount of control over the
message's appearance. The amount of actual control available to
message receivers is contingent upon the capabilities of their
individual message systems.
August 13, 1982 - 2 - RFC #822
Standard for ARPA Internet Text Messages
2. NOTATIONAL CONVENTIONS
This specification uses an augmented Backus-Naur Form (BNF)
notation. The differences from standard BNF involve naming rules
and indicating repetition and "local" alternatives.
2.1. RULE NAMING
Angle brackets ("<", ">") are not used, in general. The
name of a rule is simply the name itself, rather than "<name>".
Quotation-marks enclose literal text (which may be upper and/or
lower case). Certain basic rules are in uppercase, such as
SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in
rule definitions, and in the rest of this document, whenever
their presence will facilitate discerning the use of rule names.
2.2. RULE1 / RULE2: ALTERNATIVES
Elements separated by slash ("/") are alternatives. There-
fore "foo / bar" will accept foo or bar.
2.3. (RULE1 RULE2): LOCAL ALTERNATIVES
Elements enclosed in parentheses are treated as a single
element. Thus, "(elem (foo / bar) elem)" allows the token
sequences "elem foo elem" and "elem bar elem".
2.4. *RULE: REPETITION
The character "*" preceding an element indicates repetition.
The full form is:
<l>*<m>element
indicating at least <l> and at most <m> occurrences of element.
Default values are 0 and infinity so that "*(element)" allows any
number, including zero; "1*element" requires at least one; and
"1*2element" allows one or two.
2.5. [RULE]: OPTIONAL
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
2.6. NRULE: SPECIFIC REPETITION
"<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
number, and 3ALPHA is a string of three alphabetic characters.
August 13, 1982 - 3 - RFC #822
Standard for ARPA Internet Text Messages
2.7. #RULE: LISTS
A construct "#" is defined, similar to "*", as follows:
<l>#<m>element
indicating at least <l> and at most <m> elements, each separated
by one or more commas (","). This makes the usual form of lists
very easy; a rule such as '(element *("," element))' can be shown
as "1#element". Wherever this construct is used, null elements
are allowed, but do not contribute to the count of elements
present. That is, "(element),,(element)" is permitted, but
counts as only two elements. Therefore, where at least one ele-
ment is required, at least one non-null element must be present.
Default values are 0 and infinity so that "#(element)" allows any
number, including zero; "1#element" requires at least one; and
"1#2element" allows one or two.
2.8. ; COMMENTS
A semi-colon, set off some distance to the right of rule
text, starts a comment that continues to the end of line. This
is a simple way of including useful notes in parallel with the
specifications.
August 13, 1982 - 4 - RFC #822
Standard for ARPA Internet Text Messages
3. LEXICAL ANALYSIS OF MESSAGES
3.1. GENERAL DESCRIPTION
A message consists of header fields and, optionally, a body.
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
3.1.1. LONG HEADER FIELDS
Each header field can be viewed as a single, logical line of
ASCII characters, comprising a field-name and a field-body.
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called "folding". The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted. Thus, the single line
To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
can be represented as:
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN
and
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBN
and
To: "Joe &
J. Harvey" <ddd @ Org>, JJV @ BBN
The process of moving from this folded multiple-line
representation of a header field to its single line represen-
tation is called "unfolding". Unfolding is accomplished by
regarding CRLF immediately followed by a LWSP-char as
equivalent to the LWSP-char.
Note: While the standard permits folding wherever linear-
white-space is permitted, it is recommended that struc-
tured fields, such as those containing addresses, limit
folding to higher-level syntactic breaks. For address
fields, it is recommended that such folding occur
August 13, 1982 - 5 - RFC #822
Standard for ARPA Internet Text Messages
between addresses, after the separating comma.
3.1.2. STRUCTURE OF HEADER FIELDS
Once a field has been unfolded, it may be viewed as being com-
posed of a field-name followed by a colon (":"), followed by a
field-body, and terminated by a carriage-return/line-feed.
The field-name must be composed of printable ASCII characters
(i.e., characters that have values between 33. and 126.,
decimal, except colon). The field-body may be composed of any
ASCII characters, except CR or LF. (While CR and/or LF may be
present in the actual text, they are removed by the action of
unfolding the field.)
Certain field-bodies of headers may be interpreted according
to an internal syntax that some systems may wish to parse.
These fields are called "structured fields". Examples
include fields containing dates and addresses. Other fields,
such as "Subject" and "Comments", are regarded simply as
strings of text.
Note: Any field which has a field-body that is defined as
other than simply <text> is to be treated as a struc-
tured field.
Field-names, unstructured field bodies and structured
field bodies each are scanned by their own, independent
"lexical" analyzers.
3.1.3. UNSTRUCTURED FIELD BODIES
For some fields, such as "Subject" and "Comments", no struc-
turing is assumed, and they are treated simply as <text>s, as
in the message body. Rules of folding apply to these fields,
so that such field bodies which occupy several lines must
therefore have the second and successive lines indented by at
least one LWSP-char.
3.1.4. STRUCTURED FIELD BODIES
To aid in the creation and reading of structured fields, the
free insertion of linear-white-space (which permits folding
by inclusion of CRLFs) is allowed between lexical tokens.
Rather than obscuring the syntax specifications for these
structured fields with explicit syntax for this linear-white-
space, the existence of another "lexical" analyzer is assumed.
This analyzer does not apply for unstructured field bodies
that are simply strings of text, as described above. The
analyzer provides an interpretation of the unfolded text
August 13, 1982 - 6 - RFC #822
Standard for ARPA Internet Text Messages
composing the body of the field as a sequence of lexical sym-
bols.
These symbols are:
- individual special characters
- quoted-strings
- domain-literals
- comments
- atoms
The first four of these symbols are self-delimiting. Atoms
are not; they are delimited by the self-delimiting symbols and
by linear-white-space. For the purposes of regenerating
sequences of atoms and quoted-strings, exactly one SPACE is
assumed to exist, and should be used, between them. (Also, in
the "Clarifications" section on "White Space", below, note the
rules about treatment of multiple contiguous LWSP-chars.)
So, for example, the folded body of an address field
":sysmail"@ Some-Group. Some-Org,
Muhammed.(I am the greatest) Ali @(the)Vegas.WBA
August 13, 1982 - 7 - RFC #822
Standard for ARPA Internet Text Messages
is analyzed into the following lexical symbols and types:
:sysmail quoted string
@ special
Some-Group atom
. special
Some-Org atom
, special
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atom
The canonical representations for the data in these addresses
are the following strings:
":sysmail"@Some-Group.Some-Org
and
Muhammed.Ali@Vegas.WBA
Note: For purposes of display, and when passing such struc-
tured information to other systems, such as mail proto-
col services, there must be NO linear-white-space
between <word>s that are separated by period (".") or
at-sign ("@") and exactly one SPACE between all other
<word>s. Also, headers should be in a folded form.
August 13, 1982 - 8 - RFC #822
Standard for ARPA Internet Text Messages
3.2. HEADER FIELD DEFINITIONS
These rules show a field meta-syntax, without regard for the
particular type or internal syntax. Their purpose is to permit
detection of fields; also, they present to higher-level parsers
an image of each field as fitting on one line.
field = field-name ":" [ field-body ] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
August 13, 1982 - 9 - RFC #822
Standard for ARPA Internet Text Messages
3.3. LEXICAL TOKENS
The following rules are used to define an underlying lexical
analyzer, which feeds tokens to higher level parsers. See the
ANSI references, in the Bibliography.
; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
CRLF = CR LF
LWSP-char = SPACE / HTAB ; semantics = SPACE
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
delimiters = specials / linear-white-space / comment
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
domain-literal = "[" *(dtext / quoted-pair) "]"
August 13, 1982 - 10 - RFC #822
Standard for ARPA Internet Text Messages
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
comment = "(" *(ctext / quoted-pair / comment) ")"
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
quoted-pair = "\" CHAR ; may quote any char
phrase = 1*word ; Sequence of words
word = atom / quoted-string
3.4. CLARIFICATIONS
3.4.1. QUOTING
Some characters are reserved for special interpretation, such
as delimiting lexical tokens. To permit use of these charac-
ters as uninterpreted data, a quoting mechanism is provided.
To quote a character, precede it with a backslash ("\").
This mechanism is not fully general. Characters may be quoted
only within a subset of the lexical constructs. In particu-
lar, quoting is limited to use within:
- quoted-string
- domain-literal
- comment
Within these constructs, quoting is REQUIRED for CR and "\"
and for the character(s) that delimit the token (e.g., "(" and
")" for a comment). However, quoting is PERMITTED for any
character.
Note: In particular, quoting is NOT permitted within atoms.
For example when the local-part of an addr-spec must
contain a special character, a quoted string must be
used. Therefore, a specification such as:
Full\ Name@Domain
is not legal and must be specified as:
"Full Name"@Domain
August 13, 1982 - 11 - RFC #822
Standard for ARPA Internet Text Messages
3.4.2. WHITE SPACE
Note: In structured field bodies, multiple linear space ASCII
characters (namely HTABs and SPACEs) are treated as
single spaces and may freely surround any symbol. In
all header fields, the only place in which at least one
LWSP-char is REQUIRED is at the beginning of continua-
tion lines in a folded field.
When passing text to processes that do not interpret text
according to this standard (e.g., mail protocol servers), then
NO linear-white-space characters should occur between a period
(".") or at-sign ("@") and a <word>. Exactly ONE SPACE should
be used in place of arbitrary linear-white-space and comment
sequences.
Note: Within systems conforming to this standard, wherever a
member of the list of delimiters is allowed, LWSP-chars
may also occur before and/or after it.
Writers of mail-sending (i.e., header-generating) programs
should realize that there is no network-wide definition of the
effect of ASCII HT (horizontal-tab) characters on the appear-
ance of text at another network host; therefore, the use of
tabs in message headers, though permitted, is discouraged.
3.4.3. COMMENTS
A comment is a set of ASCII characters, which is enclosed in
matching parentheses and which is not within a quoted-string
The comment construct permits message originators to add text
which will be useful for human readers, but which will be
ignored by the formal semantics. Comments should be retained
while the message is subject to interpretation according to
this standard. However, comments must NOT be included in
other cases, such as during protocol exchanges with mail
servers.
Comments nest, so that if an unquoted left parenthesis occurs
in a comment string, there must also be a matching right
parenthesis. When a comment acts as the delimiter between a
sequence of two lexical symbols, such as two atoms, it is lex-
ically equivalent with a single SPACE, for the purposes of
regenerating the sequence, such as when passing the sequence
onto a mail protocol server. Comments are detected as such
only within field-bodies of structured fields.
If a comment is to be "folded" onto multiple lines, then the
syntax for folding must be adhered to. (See the "Lexical
August 13, 1982 - 12 - RFC #822
Standard for ARPA Internet Text Messages
Analysis of Messages" section on "Folding Long Header Fields"
above, and the section on "Case Independence" below.) Note
that the official semantics therefore do not "see" any
unquoted CRLFs that are in comments, although particular pars-
ing programs may wish to note their presence. For these pro-
grams, it would be reasonable to interpret a "CRLF LWSP-char"
as being a CRLF that is part of the comment; i.e., the CRLF is
kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a
backslash followed by a CR followed by a LF) still must be
followed by at least one LWSP-char.
3.4.4. DELIMITING AND QUOTING CHARACTERS
The quote character (backslash) and characters that delimit
syntactic units are not, generally, to be taken as data that
are part of the delimited or quoted unit(s). In particular,
the quotation-marks that define a quoted-string, the
parentheses that define a comment and the backslash that
quotes a following character are NOT part of the quoted-
string, comment or quoted character. A quotation-mark that is
to be part of a quoted-string, a parenthesis that is to be
part of a comment and a backslash that is to be part of either
must each be preceded by the quote-character backslash ("\").
Note that the syntax allows any character to be quoted within
a quoted-string or comment; however only certain characters
MUST be quoted to be included as data. These characters are
the ones that are not part of the alternate text group (i.e.,
ctext or qtext).
The one exception to this rule is that a single SPACE is
assumed to exist between contiguous words in a phrase, and
this interpretation is independent of the actual number of
LWSP-chars that the creator places between the words. To
include more than one SPACE, the creator must make the LWSP-
chars be part of a quoted-string.
Quotation marks that delimit a quoted string and backslashes
that quote the following character should NOT accompany the
quoted-string when the string is passed to processes that do
not interpret data according to this specification (e.g., mail
protocol servers).
3.4.5. QUOTED-STRINGS
Where permitted (i.e., in words in structured fields) quoted-
strings are treated as a single symbol. That is, a quoted-
string is equivalent to an atom, syntactically. If a quoted-
string is to be "folded" onto multiple lines, then the syntax
for folding must be adhered to. (See the "Lexical Analysis of
August 13, 1982 - 13 - RFC #822
Standard for ARPA Internet Text Messages
Messages" section on "Folding Long Header Fields" above, and
the section on "Case Independence" below.) Therefore, the
official semantics do not "see" any bare CRLFs that are in
quoted-strings; however particular parsing programs may wish
to note their presence. For such programs, it would be rea-
sonable to interpret a "CRLF LWSP-char" as being a CRLF which
is part of the quoted-string; i.e., the CRLF is kept and the
LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol-
lowed by a CR followed by a LF) are also subject to rules of
folding, but the presence of the quoting character (backslash)
explicitly indicates that the CRLF is data to the quoted
string. Stripping off the first following LWSP-char is also
appropriate when parsing quoted CRLFs.
3.4.6. BRACKETING CHARACTERS
There is one type of bracket which must occur in matched pairs
and may have pairs nested within each other:
o Parentheses ("(" and ")") are used to indicate com-
ments.
There are three types of brackets which must occur in matched
pairs, and which may NOT be nested:
o Colon/semi-colon (":" and ";") are used in address
specifications to indicate that the included list of
addresses are to be treated as a group.
o Angle brackets ("<" and ">") are generally used to
indicate the presence of a one machine-usable refer-
ence (e.g., delimiting mailboxes), possibly including
source-routing to the machine.
o Square brackets ("[" and "]") are used to indicate the
presence of a domain-literal, which the appropriate
name-domain is to use directly, bypassing normal
name-resolution mechanisms.
3.4.7. CASE INDEPENDENCE
Except as noted, alphabetic strings may be represented in any
combination of upper and lower case. The only syntactic units
August 13, 1982 - 14 - RFC #822
Standard for ARPA Internet Text Messages
which requires preservation of case information are:
- text
- qtext
- dtext
- ctext
- quoted-pair
- local-part, except "Postmaster"
When matching any other syntactic unit, case is to be ignored.
For example, the field-names "From", "FROM", "from", and even
"FroM" are semantically equal and should all be treated ident-
ically.
When generating these units, any mix of upper and lower case
alphabetic characters may be used. The case shown in this
specification is suggested for message-creating processes.
Note: The reserved local-part address unit, "Postmaster", is
an exception. When the value "Postmaster" is being
interpreted, it must be accepted in any mixture of
case, including "POSTMASTER", and "postmaster".
3.4.8. FOLDING LONG HEADER FIELDS
Each header field may be represented on exactly one line con-
sisting of the name of the field and its body, and terminated
by a CRLF; this is what the parser sees. For readability, the
field-body portion of long header fields may be "folded" onto
multiple lines of the actual field. "Long" is commonly inter-
preted to mean greater than 65 or 72 characters. The former
length serves as a limit, when the message is to be viewed on
most simple terminals which use simple display software; how-
ever, the limit is not imposed by this standard.
Note: Some display software often can selectively fold lines,
to suit the display terminal. In such cases, sender-
provided folding can interfere with the display
software.
3.4.9. BACKSPACE CHARACTERS
ASCII BS characters (Backspace, decimal 8) may be included in
texts and quoted-strings to effect overstriking. However, any
use of backspaces which effects an overstrike to the left of
the beginning of the text or quoted-string is prohibited.
August 13, 1982 - 15 - RFC #822
Standard for ARPA Internet Text Messages
3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS
During transmission through heterogeneous networks, it may be
necessary to force data to conform to a network's local con-
ventions. For example, it may be required that a CR be fol-
lowed either by LF, making a CRLF, or by <null>, if the CR is
to stand alone). Such transformations are reversed, when the
message exits that network.
When crossing network boundaries, the message should be
treated as passing through two modules. It will enter the
first module containing whatever network-specific transforma-
tions that were necessary to permit migration through the
"current" network. It then passes through the modules:
o Transformation Reversal
The "current" network's idiosyncracies are removed and
the message is returned to the canonical form speci-
fied in this standard.
o Transformation
The "next" network's local idiosyncracies are imposed
on the message.
------------------
From ==> | Remove Net-A |
Net-A | idiosyncracies |
------------------
||
\/
Conformance
with standard
||
\/
------------------
| Impose Net-B | ==> To
| idiosyncracies | Net-B
------------------
August 13, 1982 - 16 - RFC #822
Standard for ARPA Internet Text Messages
4. MESSAGE SPECIFICATION
4.1. SYNTAX
Note: Due to an artifact of the notational conventions, the syn-
tax indicates that, when present, some fields, must be in
a particular order. Header fields are NOT required to
occur in any particular order, except that the message
body must occur AFTER the headers. It is recommended
that, if present, headers be sent in the order "Return-
Path", "Received", "Date", "From", "Subject", "Sender",
"To", "cc", etc.
This specification permits multiple occurrences of most
fields. Except as noted, their interpretation is not
specified here, and their use is discouraged.
The following syntax for the bodies of various fields should
be thought of as describing each field body as a single long
string (or line). The "Lexical Analysis of Message" section on
"Long Header Fields", above, indicates how such long strings can
be represented on more than one line in the actual transmitted
message.
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
trace = return ; path to sender
1*received ; receipt tags
return = "Return-path" ":" route-addr ; return address
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
August 13, 1982 - 17 - RFC #822
Standard for ARPA Internet Text Messages
";" date-time ; time received
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
dates = orig-date ; Original
[ resent-date ] ; Forwarded
orig-date = "Date" ":" date-time
resent-date = "Resent-Date" ":" date-time
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
msg-id = "<" addr-spec ">" ; Unique message id
August 13, 1982 - 18 - RFC #822
Standard for ARPA Internet Text Messages
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
4.2. FORWARDING
Some systems permit mail recipients to forward a message,
retaining the original headers, by adding some new fields. This
standard supports such a service, through the "Resent-" prefix to
field names.
Whenever the string "Resent-" begins a field name, the field
has the same semantics as a field whose name does not have the
prefix. However, the message is assumed to have been forwarded
by an original recipient who attached the "Resent-" field. This
new field is treated as being more recent than the equivalent,
original field. For example, the "Resent-From", indicates the
person that forwarded the message, whereas the "From" field indi-
cates the original author.
Use of such precedence information depends upon partici-
pants' communication needs. For example, this standard does not
dictate when a "Resent-From:" address should receive replies, in
lieu of sending them to the "From:" address.
Note: In general, the "Resent-" fields should be treated as con-
taining a set of information that is independent of the
set of original fields. Information for one set should
not automatically be taken from the other. The interpre-
tation of multiple "Resent-" fields, of the same type, is
undefined.
In the remainder of this specification, occurrence of legal
"Resent-" fields are treated identically with the occurrence of
August 13, 1982 - 19 - RFC #822
Standard for ARPA Internet Text Messages
fields whose names do not contain this prefix.
4.3. TRACE FIELDS
Trace information is used to provide an audit trail of mes-
sage handling. In addition, it indicates a route back to the
sender of the message.
The list of known "via" and "with" values are registered
with the Network Information Center, SRI International, Menlo
Park, California.
4.3.1. RETURN-PATH
This field is added by the final transport system that
delivers the message to its recipient. The field is intended
to contain definitive information about the address and route
back to the message's originator.
Note: The "Reply-To" field is added by the originator and
serves to direct replies, whereas the "Return-Path"
field is used to identify a path back to the origina-
tor.
While the syntax indicates that a route specification is
optional, every attempt should be made to provide that infor-
mation in this field.
4.3.2. RECEIVED
A copy of this field is added by each transport service that
relays the message. The information in the field can be quite
useful for tracing transport problems.
The names of the sending and receiving hosts and time-of-
receipt may be specified. The "via" parameter may be used, to
indicate what physical mechanism the message was sent over,
such as Arpanet or Phonenet, and the "with" parameter may be
used to indicate the mail-, or connection-, level protocol
that was used, such as the SMTP mail protocol, or X.25 tran-
sport protocol.
Note: Several "with" parameters may be included, to fully
specify the set of protocols that were used.
Some transport services queue mail; the internal message iden-
tifier that is assigned to the message may be noted, using the
"id" parameter. When the sending host uses a destination
address specification that the receiving host reinterprets, by
August 13, 1982 - 20 - RFC #822
Standard for ARPA Internet Text Messages
expansion or transformation, the receiving host may wish to
record the original specification, using the "for" parameter.
For example, when a copy of mail is sent to the member of a
distribution list, this parameter may be used to record the
original address that was used to specify the list.
4.4. ORIGINATOR FIELDS
The standard allows only a subset of the combinations possi-
ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
and Resent-Reply-To fields. The limitation is intentional.
4.4.1. FROM / RESENT-FROM
This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).
4.4.2. SENDER / RESENT-SENDER
This field contains the authenticated identity of the AGENT
(person, system or process) that sends the message. It is
intended for use when the sender is not the author of the mes-
sage, or to indicate who among a group of authors actually
sent the message. If the contents of the "Sender" field would
be completely redundant with the "From" field, then the
"Sender" field need not be present and its use is discouraged
(though still legal). In particular, the "Sender" field MUST
be present if it is NOT the same as the "From" Field.
The Sender mailbox specification includes a word sequence
which must correspond to a specific agent (i.e., a human user
or a computer program) rather than a standard address. This
indicates the expectation that the field will identify the
single AGENT (person, system, or process) responsible for
sending the mail and not simply include the name of a mailbox
from which the mail was sent. For example in the case of a
shared login name, the name, by itself, would not be adequate.
The local-part address unit, which refers to this agent, is
expected to be a computer system term, and not (for example) a
generalized person reference which can be used outside the
network text message context.
August 13, 1982 - 21 - RFC #822
Standard for ARPA Internet Text Messages
Since the critical function served by the "Sender" field is
identification of the agent responsible for sending mail and
since computer programs cannot be held accountable for their
behavior, it is strongly recommended that when a computer pro-
gram generates a message, the HUMAN who is responsible for
that program be referenced as part of the "Sender" field mail-
box specification.
4.4.3. REPLY-TO / RESENT-REPLY-TO
This field provides a general mechanism for indicating any
mailbox(es) to which responses are to be sent. Three typical
uses for this feature can be distinguished. In the first
case, the author(s) may not have regular machine-based mail-
boxes and therefore wish(es) to indicate an alternate machine
address. In the second case, an author may wish additional
persons to be made aware of, or responsible for, replies. A
somewhat different use may be of some help to "text message
teleconferencing" groups equipped with automatic distribution
services: include the address of that service in the "Reply-
To" field of all messages submitted to the teleconference;
then participants can "reply" to conference submissions to
guarantee the correct distribution of any submission of their
own.
Note: The "Return-Path" field is added by the mail transport
service, at the time of final deliver. It is intended
to identify a path back to the orginator of the mes-
sage. The "Reply-To" field is added by the message
originator and is intended to direct replies.
4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
For systems which automatically generate address lists for
replies to messages, the following recommendations are made:
o The "Sender" field mailbox should be sent notices of
any problems in transport or delivery of the original
messages. If there is no "Sender" field, then the
"From" field mailbox should be used.
o The "Sender" field mailbox should NEVER be used
automatically, in a recipient's reply message.
o If the "Reply-To" field exists, then the reply should
go to the addresses indicated in that field and not to
the address(es) indicated in the "From" field.
August 13, 1982 - 22 - RFC #822
Standard for ARPA Internet Text Messages
o If there is a "From" field, but no "Reply-To" field,
the reply should be sent to the address(es) indicated
in the "From" field.
Sometimes, a recipient may actually wish to communicate with
the person that initiated the message transfer. In such
cases, it is reasonable to use the "Sender" address.
This recommendation is intended only for automated use of
originator-fields and is not intended to suggest that replies
may not also be sent to other recipients of messages. It is
up to the respective mail-handling programs to decide what
additional facilities will be provided.
Examples are provided in Appendix A.
4.5. RECEIVER FIELDS
4.5.1. TO / RESENT-TO
This field contains the identity of the primary recipients of
the message.
4.5.2. CC / RESENT-CC
This field contains the identity of the secondary (informa-
tional) recipients of the message.
4.5.3. BCC / RESENT-BCC
This field contains the identity of additional recipients of
the message. The contents of this field are not included in
copies of the message sent to the primary and secondary reci-
pients. Some systems may choose to include the text of the
"Bcc" field only in the author(s)'s copy, while others may
also include it in the text sent to all those indicated in the
"Bcc" list.
4.6. REFERENCE FIELDS
4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID
This field contains a unique identifier (the local-part
address unit) which refers to THIS version of THIS message.
The uniqueness of the message identifier is guaranteed by the
host which generates it. This identifier is intended to be
machine readable and not necessarily meaningful to humans. A
message identifier pertains to exactly one instantiation of a
particular message; subsequent revisions to the message should
August 13, 1982 - 23 - RFC #822
Standard for ARPA Internet Text Messages
each receive new message identifiers.
4.6.2. IN-REPLY-TO
The contents of this field identify previous correspon-
dence which this message answers. Note that if message iden-
tifiers are used in this field, they must use the msg-id
specification format.
4.6.3. REFERENCES
The contents of this field identify other correspondence
which this message references. Note that if message identif-
iers are used, they must use the msg-id specification format.
4.6.4. KEYWORDS
This field contains keywords or phrases, separated by
commas.
4.7. OTHER FIELDS
4.7.1. SUBJECT
This is intended to provide a summary, or indicate the
nature, of the message.
4.7.2. COMMENTS
Permits adding text comments onto the message without
disturbing the contents of the message's body.
4.7.3. ENCRYPTED
Sometimes, data encryption is used to increase the
privacy of message contents. If the body of a message has
been encrypted, to keep its contents private, the "Encrypted"
field can be used to note the fact and to indicate the nature
of the encryption. The first <word> parameter indicates the
software used to encrypt the body, and the second, optional
<word> is intended to aid the recipient in selecting the
proper decryption key. This code word may be viewed as an
index to a table of keys held by the recipient.
Note: Unfortunately, headers must contain envelope, as well
as contents, information. Consequently, it is neces-
sary that they remain unencrypted, so that mail tran-
sport services may access them. Since names,
addresses, and "Subject" field contents may contain
August 13, 1982 - 24 - RFC #822
Standard for ARPA Internet Text Messages
sensitive information, this requirement limits total
message privacy.
Names of encryption software are registered with the Net-
work Information Center, SRI International, Menlo Park, Cali-
fornia.
4.7.4. EXTENSION-FIELD
A limited number of common fields have been defined in
this document. As network mail requirements dictate, addi-
tional fields may be standardized. To provide user-defined
fields with a measure of safety, in name selection, such
extension-fields will never have names that begin with the
string "X-".
Names of Extension-fields are registered with the Network
Information Center, SRI International, Menlo Park, California.
4.7.5. USER-DEFINED-FIELD
Individual users of network mail are free to define and
use additional header fields. Such fields must have names
which are not already used in the current specification or in
any definitions of extension-fields, and the overall syntax of
these user-defined-fields must conform to this specification's
rules for delimiting and folding fields. Due to the
extension-field publishing process, the name of a user-
defined-field may be pre-empted
Note: The prefatory string "X-" will never be used in the
names of Extension-fields. This provides user-defined
fields with a protected set of names.
August 13, 1982 - 25 - RFC #822
Standard for ARPA Internet Text Messages
5. DATE AND TIME SPECIFICATION
5.1. SYNTAX
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
time = hour zone ; ANSI and Military
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
5.2. SEMANTICS
If included, day-of-week must be the day implied by the date
specification.
Time zone may be indicated in several ways. "UT" is Univer-
sal Time (formerly called "Greenwich Mean Time"); "GMT" is per-
mitted as a reference to Universal Time. The military standard
uses a single character for each zone. "Z" is Universal Time.
"A" indicates one hour earlier, and "M" indicates 12 hours ear-
lier; "N" is one hour later, and "Y" is 12 hours later. The
letter "J" is not used. The other remaining two forms are taken
from ANSI standard X3.51-1975. One allows explicit indication of
the amount of offset from UT; the other uses common 3-character
strings for indicating time zones in North America.
August 13, 1982 - 26 - RFC #822
Standard for ARPA Internet Text Messages
6. ADDRESS SPECIFICATION
6.1. SYNTAX
address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
route-addr = "<" [route] addr-spec ">"
route = 1#("@" domain) ":" ; path-relative
addr-spec = local-part "@" domain ; global address
local-part = word *("." word) ; uninterpreted
; case-preserved
domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom ; symbolic reference
6.2. SEMANTICS
A mailbox receives mail. It is a conceptual entity which
does not necessarily pertain to file storage. For example, some
sites may choose to print mail on their line printer and deliver
the output to the addressee's desk.
A mailbox specification comprises a person, system or pro-
cess name reference, a domain-dependent string, and a name-domain
reference. The name reference is optional and is usually used to
indicate the human name of a recipient. The name-domain refer-
ence specifies a sequence of sub-domains. The domain-dependent
string is uninterpreted, except by the final sub-domain; the rest
of the mail service merely transmits it as a literal string.
6.2.1. DOMAINS
A name-domain is a set of registered (mail) names. A name-
domain specification resolves to a subordinate name-domain
specification or to a terminal domain-dependent string.
Hence, domain specification is extensible, permitting any
number of registration levels.
August 13, 1982 - 27 - RFC #822
Standard for ARPA Internet Text Messages
Name-domains model a global, logical, hierarchical addressing
scheme. The model is logical, in that an address specifica-
tion is related to name registration and is not necessarily
tied to transmission path. The model's hierarchy is a
directed graph, called an in-tree, such that there is a single
path from the root of the tree to any node in the hierarchy.
If more than one path actually exists, they are considered to
be different addresses.
The root node is common to all addresses; consequently, it is
not referenced. Its children constitute "top-level" name-
domains. Usually, a service has access to its own full domain
specification and to the names of all top-level name-domains.
The "top" of the domain addressing hierarchy -- a child of the
root -- is indicated by the right-most field, in a domain
specification. Its child is specified to the left, its child
to the left, and so on.
Some groups provide formal registration services; these con-
stitute name-domains that are independent logically of
specific machines. In addition, networks and machines impli-
citly compose name-domains, since their membership usually is
registered in name tables.
In the case of formal registration, an organization implements
a (distributed) data base which provides an address-to-route
mapping service for addresses of the form:
person@registry.organization
Note that "organization" is a logical entity, separate from
any particular communication network.
A mechanism for accessing "organization" is universally avail-
able. That mechanism, in turn, seeks an instantiation of the
registry; its location is not indicated in the address specif-
ication. It is assumed that the system which operates under
the name "organization" knows how to find a subordinate regis-
try. The registry will then use the "person" string to deter-
mine where to send the mail specification.
The latter, network-oriented case permits simple, direct,
attachment-related address specification, such as:
user@host.network
Once the network is accessed, it is expected that a message
will go directly to the host and that the host will resolve
August 13, 1982 - 28 - RFC #822
Standard for ARPA Internet Text Messages
the user name, placing the message in the user's mailbox.
6.2.2. ABBREVIATED DOMAIN SPECIFICATION
Since any number of levels is possible within the domain
hierarchy, specification of a fully qualified address can
become inconvenient. This standard permits abbreviated domain
specification, in a special case:
For the address of the sender, call the left-most
sub-domain Level N. In a header address, if all of
the sub-domains above (i.e., to the right of) Level N
are the same as those of the sender, then they do not
have to appear in the specification. Otherwise, the
address must be fully qualified.
This feature is subject to approval by local sub-
domains. Individual sub-domains may require their
member systems, which originate mail, to provide full
domain specification only. When permitted, abbrevia-
tions may be present only while the message stays
within the sub-domain of the sender.
Use of this mechanism requires the sender's sub-domain
to reserve the names of all top-level domains, so that
full specifications can be distinguished from abbrevi-
ated specifications.
For example, if a sender's address is:
sender@registry-A.registry-1.organization-X
and one recipient's address is:
recipient@registry-B.registry-1.organization-X
and another's is:
recipient@registry-C.registry-2.organization-X
then ".registry-1.organization-X" need not be specified in the
the message, but "registry-C.registry-2" DOES have to be
specified. That is, the first two addresses may be abbrevi-
ated, but the third address must be fully specified.
When a message crosses a domain boundary, all addresses must
be specified in the full format, ending with the top-level
name-domain in the right-most field. It is the responsibility
of mail forwarding services to ensure that addresses conform
August 13, 1982 - 29 - RFC #822
Standard for ARPA Internet Text Messages
with this requirement. In the case of abbreviated addresses,
the relaying service must make the necessary expansions. It
should be noted that it often is difficult for such a service
to locate all occurrences of address abbreviations. For exam-
ple, it will not be possible to find such abbreviations within
the body of the message. The "Return-Path" field can aid
recipients in recovering from these errors.
Note: When passing any portion of an addr-spec onto a process
which does not interpret data according to this stan-
dard (e.g., mail protocol servers). There must be NO
LWSP-chars preceding or following the at-sign or any
delimiting period ("."), such as shown in the above
examples, and only ONE SPACE between contiguous
<word>s.
6.2.3. DOMAIN TERMS
A domain-ref must be THE official name of a registry, network,
or host. It is a symbolic reference, within a name sub-
domain. At times, it is necessary to bypass standard mechan-
isms for resolving such references, using more primitive
information, such as a network host address rather than its
associated host name.
To permit such references, this standard provides the domain-
literal construct. Its contents must conform with the needs
of the sub-domain in which it is interpreted.
Domain-literals which refer to domains within the ARPA Inter-
net specify 32-bit Internet addresses, in four 8-bit fields
noted in decimal, as described in Request for Comments #820,
"Assigned Numbers." For example:
[10.0.3.19]
Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It
is permitted only as a means of bypassing temporary
system limitations, such as name tables which are not
complete.
The names of "top-level" domains, and the names of domains
under in the ARPA Internet, are registered with the Network
Information Center, SRI International, Menlo Park, California.
6.2.4. DOMAIN-DEPENDENT LOCAL STRING
The local-part of an addr-spec in a mailbox specification
(i.e., the host's name for the mailbox) is understood to be
August 13, 1982 - 30 - RFC #822
Standard for ARPA Internet Text Messages
whatever the receiving mail protocol server allows. For exam-
ple, some systems do not understand mailbox references of the
form "P. D. Q. Bach", but others do.
This specification treats periods (".") as lexical separators.
Hence, their presence in local-parts which are not quoted-
strings, is detected. However, such occurrences carry NO
semantics. That is, if a local-part has periods within it, an
address parser will divide the local-part into several tokens,
but the sequence of tokens will be treated as one uninter-
preted unit. The sequence will be re-assembled, when the
address is passed outside of the system such as to a mail pro-
tocol service.
For example, the address:
First.Last@Registry.Org
is legal and does not require the local-part to be surrounded
with quotation-marks. (However, "First Last" DOES require
quoting.) The local-part of the address, when passed outside
of the mail system, within the Registry.Org domain, is
"First.Last", again without quotation marks.
6.2.5. BALANCING LOCAL-PART AND DOMAIN
In some cases, the boundary between local-part and domain can
be flexible. The local-part may be a simple string, which is
used for the final determination of the recipient's mailbox.
All other levels of reference are, therefore, part of the
domain.
For some systems, in the case of abbreviated reference to the
local and subordinate sub-domains, it may be possible to
specify only one reference within the domain part and place
the other, subordinate name-domain references within the
local-part. This would appear as:
mailbox.sub1.sub2@this-domain
Such a specification would be acceptable to address parsers
which conform to RFC #733, but do not support this newer
Internet standard. While contrary to the intent of this stan-
dard, the form is legal.
Also, some sub-domains have a specification syntax which does
not conform to this standard. For example:
sub-net.mailbox@sub-domain.domain
August 13, 1982 - 31 - RFC #822
Standard for ARPA Internet Text Messages
uses a different parsing sequence for local-part than for
domain.
Note: As a rule, the domain specification should contain
fields which are encoded according to the syntax of
this standard and which contain generally-standardized
information. The local-part specification should con-
tain only that portion of the address which deviates
from the form or intention of the domain field.
6.2.6. MULTIPLE MAILBOXES
An individual may have several mailboxes and wish to receive
mail at whatever mailbox is convenient for the sender to
access. This standard does not provide a means of specifying
"any member of" a list of mailboxes.
A set of individuals may wish to receive mail as a single unit
(i.e., a distribution list). The <group> construct permits
specification of such a list. Recipient mailboxes are speci-
fied within the bracketed part (":" - ";"). A copy of the
transmitted message is to be sent to each mailbox listed.
This standard does not permit recursive specification of
groups within groups.
While a list must be named, it is not required that the con-
tents of the list be included. In this case, the <address>
serves only as an indication of group distribution and would
appear in the form:
name:;
Some mail services may provide a group-list distribution
facility, accepting a single mailbox reference, expanding it
to the full distribution list, and relaying the mail to the
list's members. This standard provides no additional syntax
for indicating such a service. Using the <group> address
alternative, while listing one mailbox in it, can mean either
that the mailbox reference will be expanded to a list or that
there is a group with one member.
6.2.7. EXPLICIT PATH SPECIFICATION
At times, a message originator may wish to indicate the
transmission path that a message should follow. This is
called source routing. The normal addressing scheme, used in
an addr-spec, is carefully separated from such information;
the <route> portion of a route-addr is provided for such occa-
sions. It specifies the sequence of hosts and/or transmission
August 13, 1982 - 32 - RFC #822
Standard for ARPA Internet Text Messages
services that are to be traversed. Both domain-refs and
domain-literals may be used.
Note: The use of source routing is discouraged. Unless the
sender has special need of path restriction, the choice
of transmission route should be left to the mail tran-
sport service.
6.3. RESERVED ADDRESS
It often is necessary to send mail to a site, without know-
ing any of its valid addresses. For example, there may be mail
system dysfunctions, or a user may wish to find out a person's
correct address, at that site.
This standard specifies a single, reserved mailbox address
(local-part) which is to be valid at each site. Mail sent to
that address is to be routed to a person responsible for the
site's mail system or to a person with responsibility for general
site operation. The name of the reserved local-part address is:
Postmaster
so that "Postmaster@domain" is required to be valid.
Note: This reserved local-part must be matched without sensi-
tivity to alphabetic case, so that "POSTMASTER", "postmas-
ter", and even "poStmASteR" is to be accepted.
August 13, 1982 - 33 - RFC #822
Standard for ARPA Internet Text Messages
7. BIBLIOGRAPHY
ANSI. "USA Standard Code for Information Interchange," X3.4.
American National Standards Institute: New York (1968). Also
in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand-
book", NIC 7104.
ANSI. "Representations of Universal Time, Local Time Differen-
tials, and United States Time Zone References for Information
Interchange," X3.51-1975. American National Standards Insti-
tute: New York (1975).
Bemer, R.W., "Time and the Computer." In: Interface Age (Feb.
1979).
Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther-
ford and Appleton Laboratory: Didcot, England.
Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E.
"Standardizing Network Mail Headers," ARPANET Request for
Comments No. 561, Network Information Center No. 18516; SRI
International: Menlo Park (September 1973).
Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D.
"Grapevine: An Exercise in Distributed Computing," Communica-
tions of the ACM 25, 4 (April 1982), 260-274.
Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A.
"Standard for the Format of ARPA Network Text Message,"
ARPANET Request for Comments No. 733, Network Information
Center No. 41952. SRI International: Menlo Park (November
1977).
Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net-
work Information Center No. 7104 (NTIS AD A003890). SRI
International: Menlo Park (April 1976).
Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass.
(1969).
Levin, R. and Schroeder, M. "Transport of Electronic Messages
through a Network," TeleInformatics 79, pp. 29-33. North
Holland (1979). Also as Xerox Palo Alto Research Center
Technical Report CSL-79-4.
Myer, T.H. and Henderson, D.A. "Message Transmission Protocol,"
ARPANET Request for Comments, No. 680, Network Information
Center No. 32116. SRI International: Menlo Park (1975).
August 13, 1982 - 34 - RFC #822
Standard for ARPA Internet Text Messages
NBS. "Specification of Message Format for Computer Based Message
Systems, Recommended Federal Information Processing Standard."
National Bureau of Standards: Gaithersburg, Maryland
(October 1981).
NIC. Internet Protocol Transition Workbook. Network Information
Center, SRI-International, Menlo Park, California (March
1982).
Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized
Agent for Locating Named Objects in a Distributed Environ-
ment," OPD-T8103. Xerox Office Products Division: Palo Alto,
CA. (October 1981).
Postel, J.B. "Assigned Numbers," ARPANET Request for Comments,
No. 820. SRI International: Menlo Park (August 1982).
Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request
for Comments, No. 821. SRI International: Menlo Park (August
1982).
Shoch, J.F. "Internetwork naming, addressing and routing," in
Proc. 17th IEEE Computer Society International Conference, pp.
72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
Su, Z. and Postel, J. "The Domain Naming Convention for Internet
User Applications," ARPANET Request for Comments, No. 819.
SRI International: Menlo Park (August 1982).
August 13, 1982 - 35 - RFC #822
Standard for ARPA Internet Text Messages
APPENDIX
A. EXAMPLES
A.1. ADDRESSES
A.1.1. Alfred Neuman <Ne...@BBN-TENEXA>
A.1.2. Neuman@BBN-TENEXA
These two "Alfred Neuman" examples have identical seman-
tics, as far as the operation of the local host's mail sending
(distribution) program (also sometimes called its "mailer")
and the remote host's mail protocol server are concerned. In
the first example, the "Alfred Neuman" is ignored by the
mailer, as "Neuman@BBN-TENEXA" completely specifies the reci-
pient. The second example contains no superfluous informa-
tion, and, again, "Neuman@BBN-TENEXA" is the intended reci-
pient.
Note: When the message crosses name-domain boundaries, then
these specifications must be changed, so as to indicate
the remainder of the hierarchy, starting with the top
level.
A.1.3. "George, Ted" <Sh...@Group.Arpanet>
This form might be used to indicate that a single mailbox
is shared by several users. The quoted string is ignored by
the originating host's mailer, because "Shared@Group.Arpanet"
completely specifies the destination mailbox.
A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US
The "(the Stilt)" is a comment, which is NOT included in
the destination mailbox address handed to the originating
system's mailer. The local-part of the address is the string
"Wilt.Chamberlain", with NO space between the first and second
words.
A.1.5. Address Lists
Gourmets: Pompous Person <Wh...@Cordon-Bleu>,
Childs@WGBH.Boston, Galloping Gourmet@
ANT.Down-Under (Australian National Television),
Cheapie@Discount-Liquors;,
Cruisers: Port@Portugal, Jones@SEA;,
Another@Somewhere.SomeOrg
August 13, 1982 - 36 - RFC #822
Standard for ARPA Internet Text Messages
This group list example points out the use of comments and the
mixing of addresses and groups.
A.2. ORIGINATOR ITEMS
A.2.1. Author-sent
George Jones logs into his host as "Jones". He sends
mail himself.
From: Jones@Group.Org
or
From: George Jones <Jo...@Group.Org>
A.2.2. Secretary-sent
George Jones logs in as Jones on his host. His secre-
tary, who logs in as Secy sends mail for him. Replies to the
mail should go to George.
From: George Jones <Jo...@Group>
Sender: Secy@Other-Group
A.2.3. Secretary-sent, for user of shared directory
George Jones' secretary sends mail for George. Replies
should go to George.
From: George Jones<Sh...@Group.Org>
Sender: Secy@Other-Group
Note that there need not be a space between "Jones" and the
"<", but adding a space enhances readability (as is the case
in other examples.
A.2.4. Committee activity, with one author
George is a member of a committee. He wishes to have any
replies to his message go to all committee members.
From: George Jones <Jo...@Host.Net>
Sender: Jones@Host
Reply-To: The Committee: Jones@Host.Net,
Smith@Other.Org,
Doe@Somewhere-Else;
Note that if George had not included himself in the
August 13, 1982 - 37 - RFC #822
Standard for ARPA Internet Text Messages
enumeration of The Committee, he would not have gotten an
implicit reply; the presence of the "Reply-to" field SUPER-
SEDES the sending of a reply to the person named in the "From"
field.
A.2.5. Secretary acting as full agent of author
George Jones asks his secretary (Secy@Host) to send a
message for him in his capacity as Group. He wants his secre-
tary to handle all replies.
From: George Jones <Gr...@Host>
Sender: Secy@Host
Reply-To: Secy@Host
A.2.6. Agent for user without online mailbox
A friend of George's, Sarah, is visiting. George's
secretary sends some mail to a friend of Sarah in computer-
land. Replies should go to George, whose mailbox is Jones at
Registry.
From: Sarah Friendly <Se...@Registry>
Sender: Secy-Name <Se...@Registry>
Reply-To: Jones@Registry.
A.2.7. Agent for member of a committee
George's secretary sends out a message which was authored
jointly by all the members of a committee. Note that the name
of the committee cannot be specified, since <group> names are
not permitted in the From field.
From: Jones@Host,
Smith@Other-Host,
Doe@Somewhere-Else
Sender: Secy@SHost
August 13, 1982 - 38 - RFC #822
Standard for ARPA Internet Text Messages
A.3. COMPLETE HEADERS
A.3.1. Minimum required
Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org or From: Jones@Registry.Org
Bcc: To: Smith@Registry.Org
Note that the "Bcc" field may be empty, while the "To" field
is required to have at least one address.
A.3.2. Using some of the additional fields
Date: 26 Aug 76 1430 EDT
From: George Jones<Gr...@Host>
Sender: Secy@SHOST
To: "Al Neuman"@Mad-Host,
Sam.Irving@Other-Host
Message-ID: <so...@SHOST>
A.3.3. About as complex as you're going to get
Date : 27 Aug 76 0932 PDT
From : Ken Davis <KD...@This-Host.This-net>
Subject : Re: The Syntax in the RFC
Sender : KSecy@Other-Host
Reply-To : Sam.Irving@Reg.Organization
To : George Jones <Gr...@Some-Reg.An-Org>,
Al.Neuman@MAD.Publisher
cc : Important folk:
Tom Softwood <Ba...@Tree.Root>,
"Sam Irving"@Other-Host;,
Standard Distribution:
/main/davis/people/standard@Other-Host,
"<Jo...@Tops-20-Host>;
Comment : Sam is away on business. He asked me to handle
his mail for him. He'll be able to provide a
more accurate explanation when he returns
next week.
In-Reply-To: <so...@DBM.Group>, George's message
X-Special-action: This is a sample of user-defined field-
names. There could also be a field-name
"Special-action", but its name might later be
preempted
Message-ID: <42...@Other-Host>
August 13, 1982 - 39 - RFC #822
Standard for ARPA Internet Text Messages
B. SIMPLE FIELD PARSING
Some mail-reading software systems may wish to perform only
minimal processing, ignoring the internal syntax of structured
field-bodies and treating them the same as unstructured-field-
bodies. Such software will need only to distinguish:
o Header fields from the message body,
o Beginnings of fields from lines which continue fields,
o Field-names from field-contents.
The abbreviated set of syntactic rules which follows will
suffice for this purpose. It describes a limited view of mes-
sages and is a subset of the syntactic rules provided in the main
part of this specification. One small exception is that the con-
tents of field-bodies consist only of text:
B.1. SYNTAX
message = *field *(CRLF *text)
field = field-name ":" [field-body] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = *text [CRLF LWSP-char field-body]
B.2. SEMANTICS
Headers occur before the message body and are terminated by
a null line (i.e., two contiguous CRLFs).
A line which continues a header field begins with a SPACE or
HTAB character, while a line beginning a field starts with a
printable character which is not a colon.
A field-name consists of one or more printable characters
(excluding colon, space, and control-characters). A field-name
MUST be contained on one line. Upper and lower case are not dis-
tinguished when comparing field-names.
August 13, 1982 - 40 - RFC #822
Standard for ARPA Internet Text Messages
C. DIFFERENCES FROM RFC #733
The following summarizes the differences between this stan-
dard and the one specified in Arpanet Request for Comments #733,
"Standard for the Format of ARPA Network Text Messages". The
differences are listed in the order of their occurrence in the
current specification.
C.1. FIELD DEFINITIONS
C.1.1. FIELD NAMES
These now must be a sequence of printable characters. They
may not contain any LWSP-chars.
C.2. LEXICAL TOKENS
C.2.1. SPECIALS
The characters period ("."), left-square bracket ("["), and
right-square bracket ("]") have been added. For presentation
purposes, and when passing a specification to a system that
does not conform to this standard, periods are to be contigu-
ous with their surrounding lexical tokens. No linear-white-
space is permitted between them. The presence of one LWSP-
char between other tokens is still directed.
C.2.2. ATOM
Atoms may not contain SPACE.
C.2.3. SPECIAL TEXT
ctext and qtext have had backslash ("\") added to the list of
prohibited characters.
C.2.4. DOMAINS
The lexical tokens <domain-literal> and <dtext> have been
added.
C.3. MESSAGE SPECIFICATION
C.3.1. TRACE
The "Return-path:" and "Received:" fields have been specified.
August 13, 1982 - 41 - RFC #822
Standard for ARPA Internet Text Messages
C.3.2. FROM
The "From" field must contain machine-usable addresses (addr-
spec). Multiple addresses may be specified, but named-lists
(groups) may not.
C.3.3. RESENT
The meta-construct of prefacing field names with the string
"Resent-" has been added, to indicate that a message has been
forwarded by an intermediate recipient.
C.3.4. DESTINATION
A message must contain at least one destination address field.
"To" and "CC" are required to contain at least one address.
C.3.5. IN-REPLY-TO
The field-body is no longer a comma-separated list, although a
sequence is still permitted.
C.3.6. REFERENCE
The field-body is no longer a comma-separated list, although a
sequence is still permitted.
C.3.7. ENCRYPTED
A field has been specified that permits senders to indicate
that the body of a message has been encrypted.
C.3.8. EXTENSION-FIELD
Extension fields are prohibited from beginning with the char-
acters "X-".
C.4. DATE AND TIME SPECIFICATION
C.4.1. SIMPLIFICATION
Fewer optional forms are permitted and the list of three-
letter time zones has been shortened.
C.5. ADDRESS SPECIFICATION
August 13, 1982 - 42 - RFC #822
Standard for ARPA Internet Text Messages
C.5.1. ADDRESS
The use of quoted-string, and the ":"-atom-":" construct, have
been removed. An address now is either a single mailbox
reference or is a named list of addresses. The latter indi-
cates a group distribution.
C.5.2. GROUPS
Group lists are now required to to have a name. Group lists
may not be nested.
C.5.3. MAILBOX
A mailbox specification may indicate a person's name, as
before. Such a named list no longer may specify multiple
mailboxes and may not be nested.
C.5.4. ROUTE ADDRESSING
Addresses now are taken to be absolute, global specifications,
independent of transmission paths. The <route> construct has
been provided, to permit explicit specification of transmis-
sion path. RFC #733's use of multiple at-signs ("@") was
intended as a general syntax for indicating routing and/or
hierarchical addressing. The current standard separates these
specifications and only one at-sign is permitted.
C.5.5. AT-SIGN
The string " at " no longer is used as an address delimiter.
Only at-sign ("@") serves the function.
C.5.6. DOMAINS
Hierarchical, logical name-domains have been added.
C.6. RESERVED ADDRESS
The local-part "Postmaster" has been reserved, so that users can
be guaranteed at least one valid address at a site.
August 13, 1982 - 43 - RFC #822
Standard for ARPA Internet Text Messages
D. ALPHABETICAL LISTING OF SYNTAX RULES
address = mailbox ; one addressee
/ group ; named list
addr-spec = local-part "@" domain ; global address
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
atom = 1*<any CHAR except specials, SPACE and CTLs>
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
; or not sender
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
comment = "(" *(ctext / quoted-pair / comment) ")"
CR = <ASCII CR, carriage return> ; ( 15, 13.)
CRLF = CR LF
ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
dates = orig-date ; Original
[ resent-date ] ; Forwarded
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
delimiters = specials / linear-white-space / comment
destination = "To" ":" 1#address ; Primary
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Secondary
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Blind carbon
/ "Resent-bcc" ":" #address
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
domain = sub-domain *("." sub-domain)
domain-literal = "[" *(dtext / quoted-pair) "]"
domain-ref = atom ; symbolic reference
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
extension-field =
<Any field which is defined in a document
published as a formal extension to this
specification; none will have names beginning
with the string "X-">
August 13, 1982 - 44 - RFC #822
Standard for ARPA Internet Text Messages
field = field-name ":" [ field-body ] CRLF
fields = dates ; Creation time,
source ; author id & one
1*destination ; address required
*optional-field ; others optional
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
group = phrase ":" [#mailbox] ";"
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding
local-part = word *("." word) ; uninterpreted
; case-preserved
LWSP-char = SPACE / HTAB ; semantics = SPACE
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
msg-id = "<" addr-spec ">" ; Unique message id
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field ; To be defined
/ user-defined-field ; May be pre-empted
orig-date = "Date" ":" date-time
originator = authentic ; authenticated addr
[ "Reply-To" ":" 1#address] )
phrase = 1*word ; Sequence of words
August 13, 1982 - 45 - RFC #822
Standard for ARPA Internet Text Messages
qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
quoted-pair = "\" CHAR ; may quote any char
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
received = "Received" ":" ; one per relay
["from" domain] ; sending host
["by" domain] ; receiving host
["via" atom] ; physical path
*("with" atom) ; link/mail protocol
["id" msg-id] ; receiver msg id
["for" addr-spec] ; initial form
";" date-time ; time received
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
resent-date = "Resent-Date" ":" date-time
return = "Return-path" ":" route-addr ; return address
route = 1#("@" domain) ":" ; path-relative
route-addr = "<" [route] addr-spec ">"
source = [ trace ] ; net traversals
originator ; original mail
[ resent ] ; forwarded
SPACE = <ASCII SP, space> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
sub-domain = domain-ref / domain-literal
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
time = hour zone ; ANSI and Military
trace = return ; path to sender
1*received ; receipt tags
user-defined-field =
<Any field which has not been defined
in this specification or published as an
extension to this specification; names for
such fields must be unique and may be
pre-empted by published extensions>
word = atom / quoted-string
August 13, 1982 - 46 - RFC #822
Standard for ARPA Internet Text Messages
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
<"> = <ASCII quote mark> ; ( 42, 34.)
August 13, 1982 - 47 - RFC #822
1.1 jakarta-james/docs/rfclist/rfc1036.txt
Index: rfc1036.txt
===================================================================
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]
1.1 jakarta-james/docs/rfclist/README
Index: README
===================================================================
This Document contains references to relevant RFCs and Drafts.
Basic RFC
---------
RFC 822: Mail Message Format
SMTP
----
POP3
----
IMAP
----
NNTP
----
RFC 977 : NNTP Protocol.
draft-ietf-nntpext-base-13.txt: Latest draft of NNTP protocol
RFC 2980: Common NNTP Extensions
RFC 1036: Format of News Messages
NNTP Working group: http://www.academ.com/academ/nntp/
LDAP
----
1.1 jakarta-james/docs/rfclist/draft-ietf-nntpext-base-13.txt
Index: draft-ietf-nntpext-base-13.txt
===================================================================
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Network News Transport Protocol
draft-ietf-nntpext-base-13.txt
1. Status of this Document
This document is an Internet-Draft and is in full conformance
with Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accesses at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft shadow directories can be accessed
at http://www.ietf.org/shadow.html.
This section will be updated with the appropriate verbiage
from RFC 2223 should this document has been found ready for
publication as an RFC.
This document is a product of the NNTP Working Group, chaired
by Ned Freed and Stan Barber.
2. Abstract
The Network News Transport Protocol has been in use in the
Internet for a decade and remains one of the most popular
protocols (by volume) in use today. This document is a
replacement for RFC 977 and officially updates the protocol
specification. It clarifies some vagueness in RFC 977,
includes some new base functionality and provides a specific
mechanism to add standardized extensions to NNTP.
3. Introduction
This document specifies the Network News Transport Protocol
(NNTP), which is used for the distribution, inquiry,
retrieval, and posting of net news articles using a reliable
stream-based mechanism. For news reading clients, NNTP enables
retrieval of news articles that are stored in a central
Barber [Page 1]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
database, giving subscribers the ability to select only those
articles they wish to read.
The netnews model provides for indexing, cross-referencing,
and expiration of aged messages. For server-to-server
interaction, NNTP is designed for efficient transmission of
net news articles over a reliable full duplex communication
method.
Every attempt is made to insure that the protocol
specification in this document is compatible with the version
specified in RFC 977[1]. However, this version does not
support the ill-defined SLAVE command and permits four digit
years to be specified in the NEWNEWS and NEWGROUPS commands.
It changes the default character set to UTF-8[2] instead of
US-ASCII[3]. It also extends the newsgroup name matching
capabilities already documented in RFC 977.
Generally, new functionality is available using new keywords.
Part of that new functionality involves a mechanism to
discover what new functionality is available to clients from a
server.
This mechanism can also be used to add more functionality as
needs merit such additions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119[4].
An implementation is not compliant if it fails to satisfy one
or more of the MUST requirements for this protocol. An
implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but
not all the SHOULD requirements for NNTP is said to be
"conditionally compliant".
For the remainder of this memo, the term "client host" refers
to a host making use of the NNTP service, while the term
"server host" refers to a host that offers the NNTP service.
In addition, where examples of interactions between a client
host and a server host are provided a "[C]" will be used to
represent the client host and a "[S]" will be used to
represent the server host.
4. Basic Operation.
Every NNTP session MUST involve the following in this order:
Barber [Page 2]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
CONNECTION
GREETING
DISCONNECTION
Other steps may occur between the GREETING and DISCONNECTION
step. They are:
CAPABILITIES DISCOVERY
NEWS EXCHANGE
CONCLUSION
NNTP operates over any reliable data stream 8-bit-wide
channel. When running over TCP/IP, the official port for the
NNTP service is 119. Initially, the server host starts the
NNTP service by listening on a TCP port. When a client host
wishes to make use of the service, it MUST establish a TCP
connection with the server host by connecting to that host on
the same port on which the server is listening. This is the
CONNECTION step. When the connection is established, the NNTP
server host MUST send a greeting. This is the GREETING step.
The client host and server host SHOULD then exchange commands
and responses (respectively) until the connection is closed or
aborted. This final step is called the DISCONNECTION step.
If there is a CONCLUSION step, it MUST immediately precede the
DISCONNECTION step. There MUST be only one CONNECTION,
CONCLUSION and DISCONNECTION step for each NNTP session. All
other steps MAY be repeated as needed. For example, the
GREETING step may be repeated if the client makes use of the
MODE READER command (See Section 7.2 for more on the MODE
READER command).
The character set for all NNTP commands is UTF-8. Commands in
the NNTP MUST consist of an US-ASCII case-insensitive keyword,
which MAY be followed by one or more arguments. An US-ASCII
CRLF pair MUST terminate all commands. Multiple commands MUST
NOT be on the same line. Keywords MUST consist of printable
US-ASCII characters. Unless otherwise noted elsewhere in this
document, arguments SHOULD consist of printable US-ASCII
characters. Keywords and arguments MUST be each separated by
one or more US-ASCII SPACE or US-ASCII TAB characters.
Keywords MUST be at least three US-ASCII characters and MUST
NOT exceed 12 US-ASCII characters. Command lines MUST NOT
exceed 512 octets, which includes the terminating US-ASCII
CRLF pair. Arguments MUST NOT exceed 497 octets.
Each response MUST start with a three-digit response code that
is sufficient to distinguish all responses. Certain valid
responses are defined to be multi-line; for all others, the
response is contained in a single line. All multi-line
Barber [Page 3]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
responses MUST adhere to the following format: After sending
the first line of the response and an US-ASCII CRLF, any
additional lines are sent, each terminated by an US-ASCII CRLF
pair. When all lines of the response have been sent, a final
line MUST be sent, consisting of a termination octet (US-ASCII
decimal code 046, ".") and an US-ASCII CRLF pair. If any line
of the multi-line response begins with the termination octet,
the line MUST be "byte-stuffed" by pre-pending the termination
octet to that line of the response. Hence, a multi-line
response is terminated with the five octets "CRLF.CRLF" (in
US-ASCII). When examining a multi-line response, the client
MUST check to see if the line begins with the termination
octet. If so and if octets other than US-ASCII CRLF follow,
the first octet of the line (the termination octet) MUST be
stripped away. If so and if US-ASCII CRLF immediately follows
the termination character, then the response from the NNTP
server is ended and the line containing ".CRLF" (in US-ASCII)
MUST NOT be considered part of the multi-line response. Where
a response is multi-line, the description of the command will
define the format of the response before "byte-stuffing" takes
place.
An NNTP server MAY have an inactivity autologout timer. Such a
timer MUST be of at least three minutes duration. The receipt
of any command from the client during that interval SHOULD
suffice to reset the autologout timer. When the timer
expires, the server should close the TCP connection without
sending any response to the client.
4.1 Response Codes
Each response MUST begin with a three-digit status indicator.
These are status reports from the server and indicate the
response to the last command received from the client.
The first digit of the response broadly indicates the success,
failure, or progress of the previous command.
1xx - Informative message
2xx - Command ok
3xx - Command ok so far, send the rest of it.
4xx - Command was correct, but couldn't be performed for some
reason.
5xx - Command unimplemented, or incorrect, or a serious
program error occurred.
The next digit in the code indicates the function response
category.
x0x - Connection, setup, and miscellaneous messages
Barber [Page 4]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
x1x - Newsgroup selection
x2x - Article selection
x3x - Distribution functions
x4x - Posting
x8x - Reserved for authentication and authorization extensions
x9x - Reserved for private use (non-standard extensions)
Certain responses contain parameters such as numbers and names
in addition to the status indicator. In those cases, the
number and type of such parameters is fixed for each response
code to simplify interpretation by the client (any extension
MUST follow this principle as well). In all other cases, the
client MUST only use the status indicator itself to determine
the nature of the response. The exact response codes that can
be returned in response to a given command are detailed in the
description of the keyword that is the first part of the
command.
Parameters MUST be separated from the numeric status indicator
and from each other by a single US-ASCII space. All numeric
parameters MUST be in base 10 (decimal) format, and MAY have
leading zeros. String parameters MUST contain at least one
character and MUST NOT contain US-ASCII spaces, CR, LF, or
tab). The server MAY add any text after the response code or
last parameter as appropriate, and the client MUST NOT make
decisions based on this text. Such text MUST be separated from
the numeric status indicator or the last parameter by at least
one US-ASCII space.
The server MUST respond to any command with the appropriate
generic response (given in section 4.1.1) if it represents the
situation. Otherwise, each recognized command MUST return one
of the response codes specifically listed in its description
or in an extension. A server MAY provide extensions to this
specification, including new commands, new features of
existing commands, and other ways of changing the internal
state of the server. However, the server MUST NOT produce any
other responses to a client that does not invoke any of the
additional features. (Therefore a client that restricts itself
to this specification will only receive the responses that are
listed).
Each recognized command MUST return 501 (as above) or one of
the response codes specifically listed in its description or
in an extension. A server MAY provide extensions to this
specification, including new commands, new features of
existing commands, and other ways of changing the internal
state of the server. However, the server MUST NOT produce any
other responses to a client that does not invoke any of the
Barber [Page 5]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
additional features. (Therefore a client that restricts itself
to this specification will only receive the responses that are
listed).
If a client receives an unexpected response, it SHOULD use the
first digit of the response to determine the result. For
example, an unexpected 2xx should be taken as success and an
unexpected 4xx or 5xx as failure.
Response codes not specified in this standard MAY be used for
any installation-specific additional commands also not
specified. These SHOULD be chosen to fit the pattern of x9x
specified above.
Neither this document nor any extension registered with IANA
(see section 12) will specify any response codes of the x9x
pattern. (Implementers of extensions are accordingly cautioned
not to use such responses for extensions that may subsequently
be submitted for registration.)
4.1.1 Generic Response Codes
The server MUST respond to any command with the appropriate
one of the following generic responses if it represents the
situation.
If the command is not recognized, or it is an optional command
or extension that is not implemented by the server, the
response code 500 MUST be returned.
If there is a syntax error in the arguments of a recognized
command, the response code 501 MUST be returned. Note that
where a command has variants depending on a keyword (e.g. LIST
ACTIVE and LIST NEWSGROUPS), then 501 MUST be used when the
requested variant is not implemented but the base command is.
If the client is not authorized to use the specified facility
when the server is in its current state, the response code 502
MUST be returned. A different command MIGHT change the server
state and permit the command if it is retried.
If the server does not provide an optional feature, then the
response code 403 MUST be returned if the omission is
temporary (e.g. because a necessary facility is unavailable)
and the code 503 if it is permanent (e.g. because the server
does not store the required information).
If the server has to terminate the connection for some reason,
it MUST give a 400 response code to the next command and then
immediately close the TCP connection. It MAY give a 401
response code to any command to indicate that termination is
Barber [Page 6]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
imminent (following a 401 response, it MUST NOT close the TCP
connection immediately).
5. The WILDMAT format
The WILDMAT format[5] described here is based on the version
first developed by Rich Salz which was derived from the format
used in the UNIX "find" command to articulate file names. It
was developed to provide a uniform mechanism for matching
patterns in the same manner that the UNIX shell matches
filenames. Patterns are implicitly anchored at the beginning
and end of each string when testing for a match. There are
five pattern-matching operations other than a strict one-to-
one match between the pattern and the source to be checked for
a match. The first is an asterisk (*) to match any sequence of
zero or more UTF-8 characters. The second is a question mark
(?) to match any single UTF-8 character. The third specifies a
specific set of characters. The set is specified as a list of
characters, or as a range of characters where the beginning
and end of the range are separated by a minus (or dash)
character, or as any combination of lists and ranges. The dash
can also be included in the set as a character it if is the
beginning or end of the set. This set is enclosed in square
brackets. The close square bracket (]) may be used in a set if
it is the first character in the set. The fourth operation is
the same as the logical not of the third operation and is
specified the same way as the third with the addition of a
caret character (^) at the beginning of the test string just
inside the open square bracket. The final operation uses the
backslash character to invalidate the special meaning of the
open square bracket ([), the asterisk, backslash, or the
question mark. Two backslashes in sequence will result in the
evaluation of the backslash as a character with no special
meaning.
Implementers must be careful to apply the pattern-matching
operators to whole characters encoded in UTF-8, and not to
individual octets.
5.1 Negating the wildmat pattern
The exclamation point can be used at the beginning of a
wildmat to negate it. That is, if the remainder of the pattern
would match the string then the negated pattern does not, and
vice versa. If it appears as any other character other than
the first one, it has no special meaning.
Barber [Page 7]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
5.2 Examples
a) [^]-] -- matches any single character other than a
close square bracket or a minus sign/dash.
b) *bdc -- matches any string that ends with the string
"bdc" including the string "bdc" (without quotes).
c) [0-9a-zA-Z] -- matches any single printable
alphanumeric ASCII character.
d) a??d -- matches any four character string which
begins with a and ends with d.
e)!bc*d -- matches any string that does not start with
"bc" and end with "d" (without quotes)
f)!\\x -- matches any string that does not start with
"\x" (without quotes)
6. Format for Keyword Descriptions
On the following pages are descriptions of each keyword
recognized by the NNTP server and the responses that will be
returned by those commands. These keywords are grouped by the
functional step in which they are used.
Each keyword is shown in upper case for clarity, although the
NNTP server ignores case in the interpretation of commands.
Parameters are shown as follows:
. UPPERCASE indicates literal text to be included in the
command;
. lowercase indicates a token described elsewhere;
. [brackets] indicate that the parameter is optional;
. ellipsis... indicates that the parameter may be repeated
any number of times (it must occur at least once);
. vertical|bar indicates a choice of two mutually exclusive
parameters (exactly one must be provided).
Parameters are case or language specific only when specified
(either in this document or in RFC 1036[6]).
The name "wildmat" for a parameter indicates that it is a
wildmat format pattern as defined in section 5.
7. The GREETING Step
7.1 Initial Connection
There is no keyword presented by the client upon initial
connection to the server. The server MUST present an
appropriate response code as a greeting to the client. This
Barber [Page 8]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
response informs the client about what steps the client should
take to reach the news exchange step.
If the server will accept further commands from the client
including POST, the server MUST present a 200 greeting code.
If the server will accept further commands from the client,
but it is not authorized to post articles using the POST
command, the server MUST present a 201 greeting code.
Otherwise the server MUST present a 400 or 502 greeting code
and then immediately close the connection. 502 MUST be used if
the client is not permitted under any circumstances to
interact with the server and 400 otherwise.
7.1.1 Initial Connection Example
Example of a normal connection from an authorized client
[Initial TCP connection setup completed.]
[C] Initial TCP connection completed
[S] 200 NNTP Service Ready, posting permitted
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Example of a normal connection from an unauthorized client
[C] Initial TCP connection completed
[S] 502 NNTP Service Unavailable
[Server closes connection.]
Example of a normal connection from an authorized client that
is not permitted to post
[Initial TCP connection setup completed.]
[S] 201 NNTP Service Ready, posting prohibited
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Barber [Page 9]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of a connection from any client where the server is
unable to provide service
[Initial TCP connection setup completed.]
[S] 400 NNTP Service temporarily unavailable
[Server closes connection.]
7.2 MODE READER
MODE READER
MODE READER SHOULD be sent by any client that intends to use
any command other than IHAVE, HEAD, STAT, LIST, LIST
EXTENSIONS, or commands advertised by the server as available
via LIST EXTENSIONS.
Servers MAY require that this command be issued before any
other commands are sent and MAY reject any other commands
until after a MODE READER command has been sent.
The server MUST present a response using the same codes as the
initial greeting (as described in section 7.1) to indicate its
ability to provide reading service to the client.
Clients SHOULD wait for a response to MODE READER after
sending this command and SHOULD NOT send any additional
commands until that response has been received from the
server.
Once MODE READER is sent, IHAVE (and any extensions intended
for peer-to-peer article transfer) MAY no longer be permitted,
even if it were permitted before the MODE READER command. The
results of LIST EXTENSIONS MAY be different following a
MODE READER command than prior to the issuing of that command.
Servers are encouraged to not require this command even though
clients SHOULD send it when appropriate. It is present to
support some news architectures that switch between modes
based on whether a given connection is a peer-to-peer
connection with another server or a news reading client.
7.2.1 Responses
200 Posting Permitted
201 Posting Not Permitted
400 Service temporarily unavailable
502 Service unavailable
Following a 400 or 502 response the server MUST immediately
close the connection.
Barber [Page 10]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Note that the response need not be the same as the one
presented during the initial greeting.
7.2.2 MODE READER Examples
Example of use of the MODE READER command by an authorized
client
[C] MODE READER
[S] 200 NNTP Service Ready, posting permitted
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Example of use of MODE READER by a client not authorized to
receive service from the server as a news reader
[C] MODE READER
[S] 502 Service Unavailable
[Server closes connection.]
Example of a normal connection from an authorized client that
is not permitted to post
[C] MODE READER
[S] 201 NNTP Service Ready, posting prohibited
Client can send commands at this point. In this example, the
client jumps directly to the conclusion step (See section 10).
[C] QUIT
[S] 205 NNTP Service exits normally
[Server closes connection.]
Example of a connection from any client where the server is
unable to provide news reader service
[C] MODE READER
[S] 400 NNTP Service temporarily unavailable
[Server closes connection.]
Barber [Page 11]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
8. The CAPABILITIES DISCOVERY Step
To discover what extensions are available, an NNTP client can
query the server with the LIST EXTENSIONS command.
If a particular extension is unavailable, the client can
attempt to work around it or it may wish to terminate the
session.
See section 12 for further discussion of extensions.
8.1 LIST EXTENSIONS
The LIST EXTENSIONS command allows a client to determine which
extensions are supported by the server.
To discover what extensions are available, an NNTP client
SHOULD query the server early in the session for extensions
information by issuing the LIST EXTENSIONS command. This
command MAY be issued at anytime during a session. It is not
required that the client issues this command before attempting
to make use of any extension. The response generated by this
command MAY change during a session because of other state
information. However, an NNTP client MUST NOT cache (for use
in another session) any information returned if the LIST
EXTENSIONS command succeeds. That is, an NNTP client is only
able to get the current and correct information concerning
available extensions during a session by issuing a LIST
EXTENSIONS command during that session and processing that
response.
A successful response starts with a 202 code and is followed
by a list of extensions, one per line. Each line MUST begin
with exactly one space followed by an extension-label and
optionally one or more parameters (separated by single
spaces). The extension-label and the meaning of the parameters
are specified as part of the definition of the extension. The
extension-label MUST be in uppercase.
The server MUST NOT list the same extension twice in the
response, and MUST list all supported extensions. The order in
which the extensions are listed is not significant. The server
need not even consistently return the same order.
If the server does not support any extensions, it SHOULD
return a 402 failure response but MAY return an empty list
instead.
Barber [Page 12]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
8.1.1 Responses
202 extension list follows (multiline)
400 service about to terminate
402 no extensions available
503 unable to list extensions
Following a 503 response an extension might still be
available, and the client MAY attempt to use it.
The LIST EXTENSIONS command is optional, and a server MAY
issue a 500 (unknown command) or 501 (syntax error) response
to it.
8.1.1.1 LIST EXTENSIONS Examples
Example of a successful response:
[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] OVER
[S] PAT
[S] LISTGROUP
[S] .
The particular extensions shown here are simply examples of
what might be defined in other places, and no particular
meaning should be attributed to them.
Example where no extensions are available, using preferred
format:
[C] LIST EXTENSIONS
[S] 402 Server has no extensions
Example where no extensions are available, using an empty
list:
[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] .
Barber [Page 13]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
9. The NEWS EXCHANGE Step
During this step, two basic types of transactions occur:
. article retrieval from the server
. article posting to the server
9.1 Article Retrieval
News reading clients have available a variety of mechanisms to
retrieve articles via NNTP. The news articles are stored and
indexed using three types of keys. One key is the message id
of an article. According to RFC 1036, this identifier should
be globally unique. Another key is composed of the newsgroup
name and the article number within that newsgroup. That key
MUST be unique to a particular server (there will be only one
article with that number within a particular newsgroup), but
is not required to be globally unique. Additionally, because
the same article can be cross-posted to multiple newsgroups,
there may be multiple keys that point to the same article on
the same server. The final key is the arrival timestamp,
giving the time that the article arrived at the server.
The server MUST ensure that article numbers are issued in
order of arrival timestamp; that is, articles arriving later
MUST have higher numbers than those that arrive earlier. The
server SHOULD allocate the next sequential unused number to
each new article.
Article numbers MUST lie between 1 and 4,294,967,295
inclusive. The client and server SHOULD NOT use leading zeroes
in specifying article numbers, and MUST NOT use more than 16
digits. In some situations, the value zero replaces an article
number to show some special situation.
9.1.1 Article Retrieval by Newsgroup Name and Article Number
The following commands are used to set the current newsgroup
name and the "current article pointer" which is used by other
commands for article retrieval. At the start of an NNTP
session, both of these values are undefined.
9.1.1.1 GROUP
GROUP ggg
The required parameter ggg is the name of the newsgroup to be
selected (e.g. "news.software.b"). A list of valid newsgroups
Barber [Page 14]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
may be obtained by using the LIST keyword. See section 9.4
for more information on the LIST keyword.
The successful selection response will return the article
numbers of the first and last articles in the group at the
moment of selection (these numbers are referred to as the
"reported low water mark" and the "reported high water mark"),
and an estimate of the number of articles on file in the
group.
If the group is not empty, the estimate MUST be at least the
actual number of articles available, and MUST be no greater
than one more than the difference between the reported low and
high water marks. (Some implementations will actually count
the number of articles on file. Others will just subtract the
low water mark from the high water mark and add one to get an
estimate.)
If the group is empty, one of the following three situations
will occur. Clients MUST accept all three cases; servers MUST
NOT represent an empty group in any other way.
. The high water mark will be one less than the low water
mark, and the estimated article count will be zero.
Servers SHOULD use this method to show an empty group.
This is the only time that the high water mark can be
less than the low water mark.
. All three numbers will be zero.
. The high water mark is greater than or equal to the low
water mark; the estimated article count might be zero or
non-zero; if non-zero, the same requirements apply as for
a non-empty group.
The set of articles in a group may change after the GROUP
command is carried out. That is:
. articles may be removed from the group
. articles may be reinstated in the group with the same
article number, but those articles MUST have numbers no
less than the reported low water mark (note that this is
a reinstatement of the previous article, not a new
article reusing the number)
. new articles may be added with article numbers greater
than the reported high water mark (if an article that was
the one with the highest number has been removed, the
next new article will not have the number one greater
than the reported high water mark)
Barber [Page 15]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Except when the group is empty and all three numbers are zero,
whenever a subsequent GROUP command for the same newsgroup is
issued, either by the same client or a different client, the
reported low water mark in the response MUST be no less than
that in any previous response for that newsgroup sent to any
client. The client may make use of the low water mark to
remove all remembered information about articles with lower
numbers, as these will never recur. This includes the
situation when the high water mark is one less than the low
water mark.
No similar assumption can be made about the high water mark,
as this can decrease if an article is removed, and then
increase again if it is reinstated or if new articles arrive.
When a valid group is selected by means of this command, the
internally maintained "current article pointer" MUST be set to
the first article in the group and the name of the current
newsgroup MUST be set to the selected newsgroup name. If an
invalid group is specified, the previously selected group, if
any, and article MUST remain selected. If an empty newsgroup
is selected, the "current article pointer" is in an
indeterminate state and MUST NOT be used.
The GROUP keyword (or the LISTGROUP keyword, if implemented)
MUST be used by a client and a successful response received
before the any other command is used that depends on having
the "current article pointer" be valid.
9.1.1.1.1 Responses
211 n f l s group selected
(n = estimated number of articles in group, f = first
article number in the group, l = last article number
in the group, s = name of the group.)
411 no such newsgroup
9.1.1.1.2 GROUP Examples
Example for a group known to the server
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
Example for a group unknown to the server
[C] GROUP example.is.sob.bradner.or.barber
Barber [Page 16]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 411 example.is.sob.bradner.or.barber is unknown
9.1.1.2 LAST
LAST
If the current newsgroup is valid, the internally maintained
"current article pointer" MUST be set to the previous article
in the current newsgroup. If already positioned at the first
article of the newsgroup, an error message MUST be returned
and the current article MUST remain selected.
There MAY be no previous article in the group, although the
current article number is not the reported low water mark.
There MUST NOT be a previous article when the current article
number is the reported low water mark.
Because articles can be removed and added, the results of
multiple LAST and NEXT commands MAY not be consistent over the
life of a particular NNTP session.
If successful, a response indicating the current article
number and a message-id string MUST be returned. No article
text is sent in response to this command.
9.1.1.2.1 Responses
223 n a article retrieved - request text separately (n =
article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
422 no previous article in this group
9.1.1.2.2 LAST Examples
Example of a successful article retrieval using LAST
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] NEXT
[S] 223 3000237 <66...@domain.com> retrieved
[C] LAST
[S] 223 3000234 <45...@to.to> retrieved
Barber [Page 17]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of an attempt to retrieve an article without having
selected a group (via the GROUP command) first
[S] 200 NNTP Service ready
[C] LAST
[S] 412 no newsgroup selected
Example of an attempt to retrieve an article using the LAST
command when the current article pointer is pointing at the
first article in the group
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] LAST
[S] 422 No previous article to retrieve
Example of an attempt to retrieve an article using the LAST
command when the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] LAST
[S] 420 No current article selected
9.1.1.3 NEXT
NEXT
If the current newsgroup is valid, the internally maintained
"current article pointer" MUST be advanced to the next article
in the current newsgroup. If no more articles remain in the
current group, an error message MUST be returned and the
current article MUST remain selected.
If successful, a response indicating the current article
number and the message-id string MUST be returned. No article
text is sent in response to this command.
9.1.1.3.1 Responses
Barber [Page 18]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
223 n a article retrieved - request text separately (n =
article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
421 no next article in this group
9.1.1.3.2 NEXT Examples
Example of a successful article retrieval using NEXT
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] NEXT
[S] 223 3000237 <66...@domain.com> retrieved
Example of an attempt to retrieve an article without having
selected a group (via the GROUP command) first
[S] 200 NNTP Service ready
[C] NEXT
[S] 412 no newsgroup selected
Example of an attempt to retrieve an article using the NEXT
command when the current article pointer is pointing at the
last article in the group
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] ARTICLE 3002322
[S] 220 3002322 <41...@whitehouse.gov> retrieved
[S] Path: pathost!demo!whitehouse!not-for-mail
[S] From: nobody@whitehouse.gov(Demo User)
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: The White House, Washington, DC
[S] Message-ID: <41...@whitehouse.gov>
Barber [Page 19]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S]
[S] This is just a test article.
[S] .
[C] NEXT
[S] 422 No next article to retrieve
Example of an attempt to retrieve an article using the NEXT
command when the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] NEXT
[S] 420 No current article selected
9.2 Retrieval of Articles and Article Sections
The ARTICLE, BODY, HEAD, and STAT commands are very similar.
They differ only in the parts of the article that are
presented to the client and in the successful response code.
The ARTICLE command is described here in full, while the other
commands are described in terms of the differences.
An article, as defined by RFC 1036, consists of two parts: the
article headers and the article body. When responding to one
of these commands, the server presents the entire article or
appropriate part and does not attempt to alter or translate it
in any way.
9.2.1 ARTICLE
ARTICLE <message-id>
ARTICLE [number]
The ARTICLE command selects an article based on the arguments
and presents the header, a blank line, and the body of that
article. The command has two forms.
In the first form, a message-id is specified (including the
angle brackets), and the server presents the article with that
message-id in its headers. In this case, the server MUST NOT
alter the "current article pointer". This is both to
Barber [Page 20]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
facilitate the presentation of articles that may be referenced
within another article being read, and because of the semantic
difficulties of determining the proper sequence and membership
of an article which may have been posted to more than one
newsgroup.
In the second form, an article number may be specified. If so,
and if there is an article with that number in the currently
selected group, the server MUST set the current article
pointer to that number.
Then, whether or not a number was specified, the article
indicated by the current article pointer is presented to the
client.
Note that a previously valid article number MAY become invalid
if the article has been removed. A previously invalid article
number MAY become valid if the article has been reinstated,
but such an article number MUST be no less than the reported
low water mark for that group.
The server MUST NOT change the currently selected group as a
result of this command. The server MUST NOT change the current
selected article except when an article number argument was
provided and the article exists; in particular, it MUST NOT
change it following an unsuccessful response.
9.2.1.1 Responses
First form (message-id specified):
220 0 a article retrieved and follows (multiline, a =
unique article id)
430 no such article
502 service unavailable
Second form (optional article number specified):
220 n a article retrieved and follows (multiline, n =
article number, a = unique article id)
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
The 420 response only occurs if no article number has been
specified.
In the 220 response, the first parameter is 0 for the first
form and the article number (within the current group) for the
Barber [Page 21]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
second form. The second parameter is the message-id of the
article (within angle brackets). This is taken from the
message-id header line of the article (required by RFC 1036).
If there is no such line, the message-id "<0>" MUST be used
instead (without the double quotes).
Since the message-id field is unique for each article, it may
be used by a client to skip duplicate displays of articles
that have been posted more than once, or to more than one
newsgroup.
The article headers and body are returned as a multiline
response following the initial response line.
9.2.1.2 Examples
Example of a successful retrieval of an article (using no
article number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] ARTICLE
[S] 220 3000234 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S]
[S] This is just a test article.
[S] .
Example of a successful retrieval of an article by message-id
[S] 200 NNTP Service Ready
[C] ARTICLE <45...@to.to>
[S] 220 0 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
Barber [Page 22]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S]
[S] This is just a test article.
[S] .
Example of an unsuccessful retrieval of an article by message-
id
[S] 200 NNTP Service Ready
[C] ARTICLE <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of an article by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 news.groups
[C] ARTICLE 300256
[S] 423 No such article number in this group
Example of an unsuccessful retrieval of an article by number
because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] ARTICLE 300256
[S] 412 No newsgroup selected
Example of an attempt to retrieve an article when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] ARTICLE
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] ARTICLE <i....@nowhere.to>
Barber [Page 23]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 502 Service unavailable
9.2.2 HEAD
HEAD <message-id>
HEAD [number]
The HEAD command behaves identically to the ARTICLE command
except that, if the article exists, only the headers are
presented (the blank line separating the headers and body MUST
NOT be included).
9.2.2.1 Responses
First form (message-id specified):
221 0 a article retrieved, headers follow (multiline)
430 no such article
502 service unavailable
Second form (optional article number specified):
221 n a article retrieved, headers follow (multiline)
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
Except that only the headers are included in the response, the
221 response behaves identically to the 220 response of the
ARTICLE command.
9.2.2.2 Examples
Example of a successful retrieval of the headers in an article
(using no article number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HEAD
[S] 220 3000234 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
Barber [Page 24]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S] .
Example of a successful retrieval of the headers in an article
by message-id
[S] 200 NNTP Service Ready
[C] HEAD <45...@to.to>
[S] 220 0 <45...@to.to>
[S] Path: pathost!demo!somewhere!not-for-mail
[S] From: nobody@nowhere.to (Demo User)
[S] Newsgroups: misc.test
[S] Subject: I am just a test article
[S] Date: 6 Oct 1998 04:38:40 -0500
[S] Organization: Nowhere, To
[S] Message-ID: <45...@to.to>
[S] .
Example of an unsuccessful retrieval of the header of an
article by message-id
[S] 200 NNTP Service Ready
[C] HEAD <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of the header of an
article by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HEAD 300256
[S] 423 No such article number in this group
Example of an unsuccessful retrieval the header of an article
by number because no newsgroup was selected first
[S] 200 NNTP Service Ready
Barber [Page 25]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] HEAD 300256
[S] 412 No newsgroup selected
Example of an attempt to retrieve the header of an article
when the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] HEAD
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] HEAD <i....@nowhere.to>
[S] 502 Service unavailable
9.2.3 BODY
BODY <message-id>
BODY [number]
The BODY command behaves identically to the ARTICLE command
except that, if the article exists, only the body is presented
(the blank line separating the headers and body MUST NOT be
included).
9.2.3.1 Responses
First form (message-id specified):
222 0 a article retrieved, body follows (multiline)
430 no such article
502 service unavailable
Second form (optional article number specified):
222 n a article retrieved, body follows (multiline)
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
Barber [Page 26]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Except that only the body is included in the response, the 222
response behaves identically to the 220 response of the
ARTICLE command.
9.2.3.2 Examples
Example of a successful retrieval of the body of an article
(using no article number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] BODY
[S] 222 3000234 <45...@to.to>
[S] This is just a test article.
[S] .
Example of a successful retrieval of the body of an article by
message-id
[S] 200 NNTP Service Ready
[C] BODY <45...@to.to>
[S] 222 0 <45...@to.to>
[S] This is just a test article.
[S] .
Example of an unsuccessful retrieval of the body of an article
by message-id
[S] 200 NNTP Service Ready
[C] BODY <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of the body of an article
by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] BODY 300256
[S] 423 No such article number in this group
Example of an unsuccessful retrieval of the body of an article
by number because no newsgroup was selected first
Barber [Page 27]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 200 NNTP Service Ready
[C] BODY 300256
[S] 412 No newsgroup selected
Example of an attempt to retrieve the body of an article when
the current group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] BODY
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] BODY <i....@nowhere.to>
[S] 502 Service unavailable
9.2.4 STAT
STAT <message-id>
STAT [number]
The STAT command behaves identically to the ARTICLE command
except that, if the article exists, it is NOT presented to the
client.
This command allows the client to determine whether an article
exists, and in the second form what its message-id is, without
having to process an arbitrary amount of text.
9.2.4.1 Responses
First form (message-id specified):
223 0 a article exists
430 no such article
502 service unavailable
Second form (optional article number specified):
223 n a article exists
412 no newsgroup selected
420 no current article selected
423 no such article number in this group
502 service unavailable
Barber [Page 28]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
The parameters of the 223 response are identical to those that
would have been given in a 220 response to the equivalent
ARTICLE command. However, the response is NOT multiline.
9.2.4.2 Examples
Example of STAT on an existing article (using no article
number)
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] STAT
[S] 223 3000234 <45...@to.to>
Example of a STAT of an existing article by message-id
[S] 200 NNTP Service Ready
[C] STAT <45...@to.to>
[S] 223 0 <45...@to.to>
Example of an STAT of an article not on the server by message-
id
[S] 200 NNTP Service Ready
[C] STAT <i....@nowhere.to>
[S] 430 No Such Article Found
Example of STAT of an article not in the server by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] STAT 300256
[S] 423 No such article number in this group
Example of STAT of an article by number when no newsgroup was
selected first
[S] 200 NNTP Service Ready
[C] STAT 300256
[S] 412 No newsgroup selected
Barber [Page 29]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of STAT of an article when the current group selected
is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] STAT
[S] 420 No current article selected
Example of a failure due to the service being unavailable
[S] 200 NNTP Service Ready
[C] STAT <i....@nowhere.to>
[S] 502 Service unavailable
9.3 Article Posting
Article posting is done in one of two modes: individual
article posting from news reading clients and article transfer
from other news servers.
9.3.1 POST
POST
If posting is allowed, response code 340 MUST be returned to
indicate that the article to be posted should be sent.
Response code 440 MUST be sent if that posting is prohibited
for some installation-dependent reason.
If posting is permitted, the article MUST be presented to the
server by the client in the format specified by RFC 1036. The
text forming the header and body of the message to be posted
MUST be sent by the client using the conventions for text
received from the news server: A single period (".") on a line
indicates the end of the text, with lines starting with a
period in the original text having that period doubled during
transmission.
Following the presentation of the termination sequence by the
client, the server MUST return a response code indicating
success or failure of the article transfer. Note that response
codes 340 and 440 are used in direct response to the POST
command. Others are returned following the sending of the
article.
Barber [Page 30]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
No attempt shall be made by the server to filter characters,
fold or limit lines, or otherwise process incoming text. The
intent is that the server just passes the incoming message to
be posted to the server installation's news posting software,
which is not part of this specification.
9.3.1.1 Responses
240 article received ok
340 send article to be posted. End with <CR-LF>.<CR-LF>
440 posting not allowed
441 posting failed
9.3.1.2 Examples
Example of a successful posting
[S] 200 NNTP Service Ready
[C] POST
[S] 340 Input article. End with <CR-LF>.<CR-LF>
[C] From: demo@testdomain.com(Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: Testdomain, USA
[C]
[C] This is just a test article.
[C] .
[S] 240 Article received ok
Example of an unsuccessful posting
[S] 200 NNTP Service Ready
[C] POST
[S] 340 Input article. End with <CR-LF>.<CR-LF>
[C] From: demo@testdomain.com(Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: Testdomain, USA
[C]
Barber [Page 31]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] This is just a test article.
[C] .
[S] 441 Posting failed
Example of an attempt to posting when posting is not allowed
[S] 201 NNTP Service Ready, read-only
[C] POST
[S] 440 Posting not permitted
9.3.2 IHAVE
IHAVE <message-id>
The IHAVE command informs the server that the client has an
article whose id is <message-id>. If the server desires a copy
of that article, it MUST return a response instructing the
client to send the entire article. If the server does not want
the article (if, for example, the server already has a copy of
it), a response indicating that the article is not wanted MUST
be returned.
If transmission of the article is requested, the client MUST
send the entire article, including header and body, in the
manner specified for text transmission from the server. The
server MUST return a response code indicating success or
failure of the transferal of the article.
This function differs from the POST command in that it is
intended for use in transferring already-posted articles
between hosts. It SHOULD NOT be used when the client is a
personal news reading program. In particular, this function
will invoke the server's news posting program with the
appropriate settings (flags, options, etc.) to indicate that
the forthcoming article is being forwarded from another host.
However, the server MAY elect not to post or forward the
article if after further examination of the article it deems
it inappropriate to do so. Reasons for such subsequent
rejection of an article may include such problems as
inappropriate newsgroups or distributions, disk space
limitations, article lengths, garbled headers, and the like.
These are typically restrictions enforced by the server host's
news software and not necessarily the NNTP server itself.
9.3.2.1 Responses
Barber [Page 32]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
235 article transferred ok
335 send article to be transferred. End with <CR-
LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again
Because some host news posting software may not be able to
immediately render status on the whether an article is
inappropriate for posting or forwarding, an NNTP server MAY
acknowledge the successful transfer of the article and later
silently discard it. Thus, an NNTP server MAY return the 235
acknowledgment code and later discard the received article.
9.3.2.2 Examples
Example of successfully sending an article to another site
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 235 Article transferred ok
Example of sending an article to another site that rejects it
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
Barber [Page 33]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 437 Article rejected. Don't send again
Example of sending an article to another site where the
transfer fails
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 436 Transfer failed
Example of sending an article to another site that rejects it
[S] 200 NNTP Service Ready
[C] IHAVE <i....@nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
Barber [Page 34]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] From: nobody@nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i....@nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 435 Don't send it again
9.4 The LIST Keyword
9.4.1 LIST
LIST [ACTIVE [wildmat]]
The response to the LIST keyword with no parameters returns a
list of valid newsgroups and associated information. Each
newsgroup is sent as a line of text in the following format:
group first last status
where <group> is the name of the newsgroup, <last> is the
number of the last known article currently in that newsgroup,
<first> is the number of the first article currently in the
newsgroup, and <status> indicates the current status of the
group on this server. Typically, the <status> will be consist
of the US-ASCII character 'y' where posting is permitted, 'n'
where posting is not permitted and 'm' where postings will be
forwarded to the newsgroup moderator by the news server. Other
status strings may exist. The definition of these other values
and the circumstances under which they are returned is covered
in other specifications.
The <first> and <last> fields will always be numeric. They
may have leading zeros. The <first> field corresponds to the
"reported low water mark" and the <last> field corresponds to
the "reported high water mark" described in the GROUP command
(see Section 9.1.1.1).
The status of a newsgroup only indicates how posts to that
newsgroup are processed. It does not indicate if the current
client is permitted to post. That is indicated by the status
code returned as part of the greeting.
Barber [Page 35]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Please note that an empty list (i.e., the text body returned
by this command consists only of the terminating period) is a
possible valid response, and indicates that there are
currently no valid newsgroups.
If the optional wildmat parameter is specified, the list is
limited to only the groups that match the pattern.
Specifying a single group is usually very efficient for the
server. Multiple groups may be specified by using wildmat
patterns (described in section 5).
9.4.1.1 Responses
215 list of newsgroups follows
9.4.1.2 Examples
Example of LIST returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST
[S] 215 list of newsgroups follows
[S] misc.test 3000234 3002322 y
[S] alt.fc-writers.recovery 1 4 y
[S] tx.natives.recovery 56 89 y
[S] .
Example of LIST returning no newsgroups
[S] 200 NNTP Service Ready
[C] LIST
[S] 215 list of newsgroups follows
[S] .
9.4.2 LIST ACTIVE.TIMES
LIST ACTIVE.TIMES [wildmat]
The active.times file is maintained by some news transport
systems to contain information about who created a particular
newsgroup and when. The format of this file includes three
fields. The first field is the name of the newsgroup. The
second is the time when this group was created on this news
server measured in seconds since the start of January 1, 1970.
The third is the email address of the entity that created the
newsgroup. When executed, the information is displayed
Barber [Page 36]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
following the 215 response. When display is completed, the
server will send a period on a line by itself. If the
information is not available, the server will return the 503
error response. If the server does not recognize the command,
it SHOULD return the 501 error response.
If the optional wildmat parameter is specified, the list is
limited to only the groups that match the pattern.
Specifying a single group is usually very efficient for the
server. Multiple groups may be specified by using wildmat
patterns (described in section 5).
9.4.2.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
9.4.2.2 Examples
Example of LIST ACTIVE.TIMES returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST ACTIVE.TIMES
[S] 215 information follows
[S] misc.test 930445408 <cr...@isc.org>
[S] alt.rfc-writers.recovery 930562309 <m...@nowhere.to>
[S] tx.natives.recovery 930678923 <so...@academ.com>
[S] .
Example of LIST ACTIVE.TIMES returning an error (The server
software is not configured to maintain this information, but
does recognize the command as valid.)
[S] 200 NNTP Service Ready
[C] LIST ACTIVE.TIMES
[S] 503 program error, function not performed
Example of LIST ACTIVE.TIMES sent to a server that does not
recognize this argument (e.g. The software does not maintain
this information.)
[S] 200 NNTP Service Ready
Barber [Page 37]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] LIST ACTIVE.TIMES
[S] 501 Syntax Error
9.4.3 LIST DISTRIBUTIONS
LIST DISTRIBUTIONS
The distributions file is maintained by some news transport
systems to contain information about valid values for the
Distribution: line in a news article header and about what the
values mean. Each line contains two fields, the value and a
short explanation on the meaning of the value. When executed,
the information is displayed following the 215 response. When
display is completed, the server will send a period on a line
by itself. If the information is not available, the server
will return the 503 error response. If the server does not
recognize this command, it SHOULD return the 501 error
response.
9.4.3.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
9.4.3.2 Examples
Example of LIST DISTRIBUTIONS returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST DISTRIBUTIONS
[S] 215 information follows
[S] usa United States of America
[S] na North America
[S] world All over the World
[S] .
Example of LIST DISTRIBUTIONS returning an error (e.g. The
server software is not configured to maintain this
information, but does recognize the command as valid.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIBUTIONS
[S] 503 program error, function not performed
Barber [Page 38]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of LIST DISTRIBUTIONS sent to a server that does not
recognize the command (e.g. The server does not maintain this
information regardless of configuration.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIBUTIONS
[S] 501 Syntax Error
9.4.4 LIST DISTRIB.PATS
LIST DISTRIB.PATS
The distrib.pats file is maintained by some news transport
systems to allow clients to choose a value for the
Distribution: line in the header of a news article being
posted. The information returned consists of lines, in no
particular order, each of which contains three fields
separated by colons. These fields are a weight, a group name
or wildmat pattern, and a Distribution: value, in that order.
The client MAY use this information to select a Distribution:
value based on the name of a newsgroup. To do so, it should
determine the lines whose second field matches the newsgroup
name, select that line with the highest weight (with 0 being
the lowest), and use the Distribution: field from that line.
When executed, the information is displayed following the 215
response. When display is completed, the server will send a
period on a line by itself. If the information is not
available, the server will return the 503 error response. If
this command is not recognized, the server SHOULD return the
501 error response.
9.4.4.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
9.4.4.2 Examples
Example of LIST DISTRIB.PATS returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST DISTRIB.PATS
[S] 215 information follows
[S] 10:local.*:local
Barber [Page 39]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] .
Example of LIST DISTRIB.PATS returning an error (e.g. The
server software is not configured to maintain this
information, but does recognize the command as valid.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIB.PATS
[S] 503 program error, function not performed
Example of LIST DISTRIB.PATS sent to a server that does not
recognize the command (e.g. The software does not maintain
this information regardless of configuration.)
[S] 200 NNTP Service Ready
[C] LIST DISTRIB.PATS
[S] 501 Syntax Error
9.4.5 LIST NEWSGROUPS
LIST NEWSGROUPS [wildmat]
The newsgroups file is maintained by some news transport
systems to contain the name of each newsgroup that is
active on the server and a short description about the
purpose of each newsgroup. Each line in the file contains
two fields, the newsgroup name and a short explanation of
the purpose of that newsgroup. When executed, the
information is displayed following the 215 response. When
display is completed, the server will send a period on a
line by itself. If the information is not available, the
server will return the 503 response. If the server does not
recognize the command it should return a 501 response. If
the optional matching parameter is specified, the list is
limited to only the groups that match the pattern (no
matching is done on the group descriptions). Specifying a
single group is usually very efficient for the server, and
multiple groups may be specified by using a wildmat(see
section 5), not regular expressions. If nothing is matched
an empty list is returned, not an error.
9.4.5.1 Responses
215 information follows
501 Syntax error
503 program error, function not performed
Barber [Page 40]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
9.4.5.2 Examples
Example of LIST NEWSGROUPS returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST NEWSGROUPS
[S] 215 information follows
[S] misc.test General Usenet testing
[S] alt.rfc-writers.recovery RFC Writers Recovery
[S] tx.natives.recovery Texas Natives Recovery
[S] .
Example of LIST NEWSGROUPS returning an error (e.g. The server
software recognizes the command as valid, but the information
is not available.)
[S] 200 NNTP Service Ready
[C] LIST NEWSGROUPS
[S] 503 program error, function not performed
9.5 Standard extensions
Each of the following sections describes an extension that a
server MAY provide. If the server provides the extension, it
MUST include the appropriate extension label in the response
to LIST EXTENSIONS. If it does not provide it, it MUST NOT
include the appropriate extension label. The descriptions of
facilities in each section are written as if the extension is
provided. If it is not provided, the entire section should be
ignored.
9.5.1 LISTGROUP extension
This extension provides one command and has the extension
label LISTGROUP.
9.5.1.1 The LISTGROUP Command
LISTGROUP [ggg]
The LISTGROUP command is used to get a listing of all the
article numbers in a particular newsgroup.
Barber [Page 41]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
The optional parameter ggg is the name of the newsgroup to
be selected (e.g. "news.software.b"). A list of valid
newsgroups may be obtained from the LIST command. If no
group is specified, the current group is used as the
default argument.
The successful selection response will be a list of the
article numbers in the group followed by a period on a line
by itself. The list starts on the next line following the
211 response code.
When a valid group is selected by means of this command,
the internally maintained "current article pointer" MUST be
set to the first article in the group and the name of the
current newsgroup MUST be set to the selected newsgroup
name. If an invalid group is specified, the previously
selected group and article remain selected. If an empty
newsgroup is selected, the "current article pointer" may be
in an indeterminate state and should not be used.
The LISTGROUP keyword MAY be used by a client as a
replacement for the GROUP command in establishing a valid
"current article pointer." After a successful response is
received, any other command may be used that depends on
having the "current article pointer" be valid.
The group name MUST match a newsgroup obtained from the
LIST command or an error will result, else the server will
respond with the 411 error code.
A server that does not implement this command SHOULD return
a 500 error response.
9.5.1.1.1 Responses
211 list of article numbers follow
411 No such group
412 Not currently in newsgroup
500 Command not recognized
9.5.1.1.2 Examples
Example of a successful execution with a group that exists on
the server
[S] 200 NNTP Service Ready
[C] LISTGROUP misc.test
[S] 211 list of article numbers follow
Barber [Page 42]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 3000234
[S] 3000237
[S] 3000238
[S] 3000239
[S] 3002322
[S] .
Example of an unsuccessful execution with a group that does
not exist on the server
[S] 200 NNTP Service Ready
[C] LISTGROUP this.group.is.not.here
[S] 411 no such group
Example of an attempt to retrieve an article when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] LISTGROUP example.empty.newsgroup
[S] 412 No current article selected
9.5.2 The OVER Extension
This extension provides two commands, OVER and LIST
OVERVIEW.FMT. The label for this extension is OVER.
9.5.2.1 LIST OVERVIEW.FMT
LIST OVERVIEW.FMT
The overview.fmt file is maintained by some news transport
systems to contain the order in which header information is
stored in the overview databases for each newsgroup. When
executed, news article header fields are displayed one line at
a time in the order in which they are stored in the overview
database[6] following the 215 response. When display is
completed, the server will send a period on a line by itself.
If the information is not available, the server will return
the 503 response.
If the header has the word "full" (without quotes) after the
colon, the header's name is prepended to its field in the
output returned by the server.
This is command is part of the optional OVER extension which
includes the OVER command defined in section . If the OVER
Barber [Page 43]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
extension is not implemented, then this command MUST NOT be
implemented. If that case, the server MUST return a 501 error
response when this command is presented by the client.
9.5.2.1.1 Responses
215 information follows
501 Syntax Error
503 program error, function not performed
9.5.2.1.2 Examples
Example of LIST OVERVIEW.FMT returning a list of newsgroups
[S] 200 NNTP Service Ready
[C] LIST OVERVIEW.FMT
[S] 215 Order of fields in overview database.
[S] Subject:
[S] From:
[S] Date:
[S] Message-ID:
[S] .
Example of LIST OVERVIEW.FMT returning an error
[S] 200 NNTP Service Ready
[C] LIST OVERVIEW.FMT
[S] 503 program error, function not performed
9.5.2.2 OVER
OVER [range]
The OVER command returns specific header information for the
article(s) specified from the current selected group. The
information returned in the response to this command can be
used by clients to follow discussion threads.
The optional range argument may be any of the following:
. an article number
. an article number followed by a dash to indicate all
following
Barber [Page 44]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
. an article number followed by a dash followed by another
article number
If no argument is specified, then information from the current
article is displayed. Successful responses start with a 224
response followed by the overview information for all matched
messages. Once the output is complete, a period is sent on a
line by itself. If no argument is specified, the information
for the current article is returned. A newsgroup must have
been selected earlier, else a 412 error response is returned.
If no articles are in the range specified, the server returns
a 420 error response. A 502 response will be returned if the
client only has permission to transfer articles. A 500
response SHOULD be returned by servers do not implement this
command.
The output consists of one line per article, sorted in
numerical order of article number. Each line consists of a
number of fields separated by an US-ASCII TAB character. The
first 8 fields MUST be the following, in order:
article number, subject, author, date, message-ID, references,
byte count, line count
The content of any subsequent field is given by the response
to the LIST OVERVIEW.FMT command. A field may be empty (in
which case there will be two adjacent US-ASCII tabs, and a
sequence of trailing US-ASCII tabs may be omitted). Any
sequence of US-ASCII space or non-printing characters in a
field MUST be replaced by a single US-ASCII space.
The server SHOULD not produce output for articles that no
longer exist.
9.5.2.2.1 Responses
224 Overview information follows
412 No newsgroup current selected
420 No article(s) selected
500 Command not recognized
502 Service Unavailable
9.5.2.2.2 Examples
Example of a successful retrieval of overview information for
an article (using no article number)
[S] 200 NNTP Service Ready
Barber [Page 45]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER
[S] 224 Overview information follows
300234|I am just a test article|nobody@nowhere.to
(Demo User)|6 Oct 1998 04:38:40 -0500|
<45...@to.to>
[S] .
[Please note that the line that begins with 300234 is all one
line that has been wrapped for readability. A vertical bar has
been inserted to show where the US-ASCII TAB should actually
be.]
Example of an unsuccessful retrieval of overview information
on an article by number
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER 300256
[S] 420 No such article in this group
Example of an unsuccessful retrieval of overview information
by number because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] OVER
[S] 412 No newsgroup selected
Example of an attempt to retrieve an article when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] OVER
[S] 420 No current article selected
9.5.3 The HDR Extension
This extension provides one new command, HDR. The label for
this extension is PAT.
Barber [Page 46]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
9.5.3.1 HDR
HDR range|<message-id>
The HDR command is used to retrieve specific headers from
specific articles in the currently selected group.
The required header parameter is the name of a header line
(e.g. "subject") in a newsgroup article. See RFC-1036 for a
list of valid header lines. The required range argument may be
any of the following:
. an article number
. an article number followed by a dash to indicate all
following
. an article number followed by a dash followed by another
article number.
The required message-id argument indicates a specific article.
The range and message-id arguments are mutually exclusive.
A successful response consists of a 221 code followed by the
output from the command. The output consists of one line for
each article where the relevant header line exists. The line
consists of the article number, a US-ASCII space, and then the
contents of the header (without the header name). A valid
response includes an empty list (indicating that there were no
matches). Once the output is complete, a period is sent on a
line by itself. If the optional argument is a message-id and
no such article exists, a 430 error response shall be
returned. A 502 response shall be returned if the client only
has permission to transfer articles. A 500 response SHOULD be
issued by all servers that do not recognize this command.
9.5.3.1.1 Responses
221 Header follows
412 no newsgroup selected
430 no such article
500 Command not recognized
502 Service Unavailable
9.5.3.1.2 Examples
Example of a successful retrieval of subject lines from a
range of articles
Barber [Page 47]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HDR Subject 3000234-300238
[S] 221 Header Follows
[S] 3000234 I am just a test article
[S] 3000237 Re: I am just a test article
[S] 3000238 Ditto
[S] .
Example of a successful retrieval of header from an article by
message-id
[S] 200 NNTP Service Ready
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HDR subject <i....@nowhere.to>
[S] 221 Header information follows
[S] 3000345 I am just a test article
[S] .
Example of an unsuccessful retrieval of a header from an
article by message-id
[S] 200 NNTP Service Ready
[C] HDR subject <i....@nowhere.to>
[S] 430 No Such Article Found
Example of an unsuccessful retrieval of headers from articles
by number because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] HDR subject 300256-
[S] 412 No newsgroup selected
Example of an unsuccessful retrieval of headers from articles
by message-id because no newsgroup was selected first
[S] 200 NNTP Service Ready
[C] HDR subject <i....@nowhere.to>
[S] 412 No newsgroup selected
Barber [Page 48]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Example of retrieving header information when the current
group selected is empty
[S] 200 NNTP Service Ready
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] HDR subject 0-
[S] 221 Headers follow
.
Example of a failure due to restrictions configured into the
server
[S] 200 NNTP Service Ready
[C] GROUP news.group
[S] 211 1234 3000234 3002322 misc.test
[C] HDR Subject 3000234-300238
[S] 502 Service Unavailable
10. The CONCLUSION Step
10.1 QUIT
QUIT
The server process MUST acknowledge the QUIT command and then
close the connection to the client. This is the preferred
method for a client to indicate that it has finished all its
transactions with the NNTP server.
If a client simply disconnects (or the connection times out or
some other fault occurs), the server MUST gracefully cease its
attempts to service the client, disconnecting from its end if
necessary.
10.1.1 Responses
205 closing connection - goodbye!
10.1.2 Example
[S] 200 NNTP Service Ready
[C] QUIT
[S] 205 closing connection
Barber [Page 49]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[Server closes connection.]
11. Other Keywords
There are other keywords that may be used at any time between
the beginning of a session and its termination. Using these
keywords does not alter any state information, but the
response generated from the use of these keywords may provide
useful information to clients that use them.
11.1 DATE
DATE
This command exists to help clients find out the current
Coordinated Universal Time[7] from the server's perspective.
This command SHOULD NOT be used as a substitute for NTP[8],
but to provide information that might be useful when using the
NEWNEWS command (see section 11.4). A system providing NNTP
service SHOULD implement NTP for the purposes of keeping the
system clock as accurate as possible.
This command returns a one-line response code of 111 followed
by the date and time on the server in the form YYYYMMDDhhmmss.
11.1.1 Responses
111 YYYYMMDDhhmmss
11.1.2 Example
[S] 200 NNTP Service Ready
[C] DATE
[S] 111 19990623135624
11.2 The HELP Command
HELP
This command provides a short summary of commands that are
understood by this implementation of the server. The help text
will be presented as a textual response terminated by a single
period on a line by itself.
This text is not guaranteed to be in any particular format and
SHALL NOT be used by clients as a replacement for the LIST
EXTENSIONS command described in section 8.1.
Barber [Page 50]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
11.2.1 Responses
100 help text follows
11.2.2 Example
[S] 200 NNTP Service Ready
[C] HELP
[S] 100 Help text follows
[S] This is some help text. There is no specific
[S] formatting requirement for this test, though
[S] it is customary for it to list the valid commands
[S] and give a brief definition of what they do
[S] .
11.3 NEWGROUPS
NEWGROUPS date time [GMT]
A list of newsgroups created since <date and time> MUST be
listed in the same format as the LIST command.
The date is sent as 6 or 8 digits in the format [XX]YYMMDD,
where XX is the first two digits of the year, YY is the last
two digits of the year, MM is the two digits of the month
(with leading zero, if appropriate), and DD is the day of the
month (with leading zero, if appropriate). If the first two
digits of the year are not specified, the year is to be taken
from the current century if YY is smaller than or equal to the
current year, otherwise the year is from the previous century.
Time must also be specified. It must be as 6 digits HHMMSS
with HH being hours in the 24-hour clock 00-23, MM minutes 00-
59, and SS seconds 00-60, which allows for leap seconds. The
token "GMT" specifies that the date and time are given in
Coordinated Universal Time. If the token "GMT" is omitted then
the date and time are specified in the server's local
timezone. Note that there is no way within this specification
of NNTP to establish the server's local timezone.
Note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible
valid response, and indicates that there are currently no new
newsgroups.
Barber [Page 51]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Clients SHOULD make all queries using Coordinated Universal
Time when possible.
11.3.1 Responses
231 list of new newsgroups follows
11.3.2 Examples
Example where there are new groups
[S] 200 NNTP Service Ready
[C] NEWGROUPS 19990624 000000 GMT
[S] 230 list of new newsgroups follows
[S] alt.rfc-writers.recovery
[S] tx.natives.recovery
[S] .
Example where there are no new groups
[S] 200 NNTP Service Ready
[C] NEWGROUPS 19990624 000000 GMT
[S] 230 list of new newsgroups follows
[S] .
11.4 NEWNEWS
NEWNEWS newsgroups date time [GMT]
A list of message-ids of articles posted or received to the
specified newsgroup or groups since "date" will be listed. The
format of the listing will be one message-id per line, as
though text were being sent. Each message-id SHALL appear only
once in a response. The order of the response has no specific
significance and may vary from response to response in the
same session. A single line consisting solely of one period
followed by CR-LF will terminate the list.
Date and time are in the same format as the NEWGROUPS command.
The newsgroups parameter MUST be in wildmat format and MAY
consist of multiple wildmat constructs separated by an US-
ASCII comma character.
Note that an empty list (i.e., the text body returned by this
command consists only of the terminating period) is a possible
valid response, and indicates that there is currently no new
news.
Barber [Page 52]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Clients SHOULD make all queries in Coordinated Universal Time
when possible.
11.4.1 Responses
230 list of new articles by message-id follows
11.4.2 Examples
Example where there are new articles
[S] 200 NNTP Service Ready
[C] NEWNEWS news.*,sci.* 19990624 000000
[S] 230 list of new articles by message-id follows
[S] <i....@nowhere.to>
[S] <i....@nowhere.to>
Example where there are no new articles
[S] 200 NNTP Service Ready
[C] NEWNEWS alt.* 19990624 000000
[S] 230 list of new articles by message-id follows
[S] .
12. Framework for NNTP Extensions
Although NNTP is widely and robustly deployed, some parts of
the Internet community might wish to extend the NNTP service.
This memo defines a means whereby an extended NNTP client may
query the server to determine the service extensions that it
supports.
It must be emphasized that any extension to the NNTP service
should not be considered lightly. NNTP's strength comes
primarily from its simplicity. Experience with many protocols
has shown that:
Protocols with few options tend towards ubiquity, whilst
protocols with many options tend towards obscurity.
This means that each and every extension, regardless of its
benefits, must be carefully scrutinized with respect to its
implementation, deployment, and interoperability costs. In
many cases, the cost of extending the NNTP service will likely
outweigh the benefit.
Barber [Page 53]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
Given this environment, the framework for the extensions
described in this memo consists of:
a)a mechanism for clients to determine a server's available
extensions
b)a registry of NNTP service extensions
The LIST EXTENSIONS command is described in section 8.1 of
this memo and is the mechanism for clients to use to determine
what extensions are available for client use.
The IANA shall maintain a registry of NNTP service extensions.
An extension is identified by a unique extension-label, which
is a string of 1 to 12 uppercase letters. The extension-label
will often be the name of a new command that the extension
adds. However this is not a requirement: an extension might
not add any new commands or keywords.
An extension is either a private extension or else it is
included in the IANA registry and is defined in an RFC. Such
RFCs either must be on the standards-track or must define an
IESG-approved experimental protocol.
The definition of an extension must include:
. a descriptive name for the extension
. the extension-label (which is returned by LIST EXTENSIONS
to indicate to the client that the server supports this
particular extension)
. the syntax, values, and meanings of any parameters
following the extension-label in the output of LIST
EXTENSIONS
. any new NNTP keywords associated with the extension
. the syntax and possible values of parameters associated
with the new NNTP keywords
. any new parameters the extension associates with any
other pre-existing NNTP keywords
. how support for the extension affects the behavior of a
server and NNTP client
. any increase in the maximum length of commands over the
value specified in this memo
The extension-label of private extensions MUST begin with "X".
The extension-label of registered extensions MUST NOT begin
with "X".
Any keyword values presented in the NNTP response that do not
begin with "X" MUST correspond to a standard, standards-track,
Barber [Page 54]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
or IESG-approved experimental NNTP service extension
registered with IANA. A conforming server MUST NOT offer non
"X" prefixed keyword values that are not described in a
registered extension.
Except where stated otherwise, the commands in this document
are understood (even if not supported) by all servers and are
not described in the list of features returned by the LIST
EXTENSIONS command.
A server MAY provide additional keywords - either new commands
or new parameters to existing commands - as part of a private
extension. These new keywords MUST begin with "X".
A server MUST NOT send different response codes to basic NNTP
commands documented here or commands documented in registered
extensions in response to the availability or use of a private
extension.
12.1 Initial IANA Registry
The IANA's initial registry of NNTP service extensions
consists of these entries:
Service Extension NNTP Extension Label Added Behavior
Overview Support OVER Defined in this
document
Specific Article LISTGROUP Defined in this
Numbers document
Header Pattern HDR Defined in this
Matching document
13. Augmented BNF[9] Syntax for NNTP Commands
This syntax defines the non-terminal "command". The non-terminal
"parameter" is used for command parameters whose syntax is
specified elsewhere. The syntax is in alphabetical order. Note
that ABNF strings are case insensitive.
article-command = "ARTICLE" [1*WSP (msg-id / article-number)]
*WSP CRLF
article-number = 1*16DIGIT
argument = parameter ; excluding sequence ".."
body-command = "BODY" [1*WSP (msg-id / article-number)] *WSP
CRLF
command = article-command /
body-command /
Barber [Page 55]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
date-command /
group-command /
head-command /
help-command /
ihave-command /
last-command /
list-active-times-command /
list-distrib-pats-command /
list-distributions-command /
list-extensions-command /
list-newsgroups-command /
list-overview-fmt-command /
list-command /
listgroup-command /
mode-reader-command /
newgroups-command /
newnews-command /
next-command /
over-command /
hdr-command /
post-command /
quit-command /
stat-command
CR = %x0D
CRLF = CR LF
date-command = "DATE" *WSP CRLF
date = 6*8DIGIT
DIGIT = %x30-39
group-command = "GROUP" 1*WSP newsgroup *WSP CRLF
hdr-command = "PAT" 1*WSP header 1*WSP (range / msg-id) *WSP
CRLF
head-command = "HEAD" [1*WSP (msg-id / article-number)] *WSP
CRLF
header = parameter
help-command = "HELP" *WSP CRLF
HT = %x09
ihave-command = "IHAVE" 1*WSP msg-id *WSP CRLF
last-command = "LAST" *WSP CRLF
LF = %x0A
list-active-times-command = "LIST" 1*WSP "ACTIVE.TIMES"
[1*WSP wildmat] *WSP CRLF
list-command = "LIST" [1*WSP "ACTIVE" [1*WSP wildmat]] *WSP
CRLF
list-distrib-pats-command = "LIST" 1*WSP "DISTRIB.PATS" *WSP
CRLF
list-distributions-command = "LIST" 1*WSP "DISTRIBUTIONS" *WSP
CRLF
Barber [Page 56]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
list-extensions-command = "LIST" 1*WSP "EXTENSIONS" *WSP CRLF
list-newsgroups-command = "LIST" 1*WSP "NEWSGROUPS" [1*WSP
wildmat]
*WSP CRLF
list-overview-fmt-command = "LIST" 1*WSP "OVERVIEW.FMT" *WSP
CRLF
listgroup-command = "LISTGROUP" [1*WSP newsgroup] *WSP CRLF
mode-reader-command = "MODE" 1*WSP "READER" *WSP CRLF
msg-id = <defined in RFC822>
newgroups-command = "NEWGROUPS" 1*WSP date 1*WSP time [1*WSP
"GMT"] *WSP CRLF
newnews-command = "NEWNEWS" 1*WSP newsgroup *("," newsgroup)
1*WSP date 1*WSP time [1*WSP "GMT"]
*WSP CRLF
newsgroup = parameter
next-command = "NEXT" *WSP CRLF
over-command = "OVER" [1*WSP range] *WSP CRLF
parameter = 1*(%x21-FF) ; generic command parameter
post-command = "POST" *WSP CRLF
quit-command = "QUIT" *WSP CRLF
range = article-number ["-" [article-number]]
SP = %x20
stat-command = "STAT" [1*WSP (msg-id / article-number)] *WSP
CRLF
time = 6DIGIT
UTF-8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
wildmat = ["!"]1*("*" / "?" / wildmat-exact / wildmat-set /
"\" (%x22-7F / UTF-8-non-ascii))
wildmat-exact = %x22-29 / %x2B-3E / %x40-5A / %x5D-7F / UTF-8-
non-ascii ; exclude space ! * ? [ \
wildmat-non-hyphen = %x21-2C / %x2E-7F / UTF-8-non-ascii ;
exclude space -
wildmat-set = "[" ["^"] ["]" / "-"] *(wildmat-non-hyphen"["-"
wildmat-non-hyphen]) ["-"]
WSP = SP / HT
14. Security Considerations
This section is meant to inform application developers,
information providers, and users of the security limitations
in NNTP as described by this document. The discussion does not
Barber [Page 57]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
include definitive solutions to the problems revealed, though
it does make some suggestions for reducing security risks.
14.1 Personal and Proprietary Information
NNTP, because it was created to distribute network news
articles, will forward whatever information is stored in those
articles. Specification of that information is outside this
scope of this document, but it is likely that some personal
and/or proprietary information is available in some of those
articles. It is very important that designers and implementers
provide informative warnings to users so personal and/or
proprietary information is not disclosed inadvertently.
Additionally, effective and easily understood mechanisms to
manage the distribution of news articles must be provided to
NNTP Server administrators, so that they are able to report
with confidence what information is and is not being forwarded
in news articles passing though their servers.
14.2 Abuse of Server Log Information
A server is in the position to save session data about a
user's requests that might identify their reading patterns or
subjects of interest. This information is clearly confidential
in nature and its handling can be constrained by law in
certain countries. People using the NNTP protocol to provide
data are responsible for ensuring that such material is not
distributed without the permission of any individuals that are
identifiable by the published results.
14.3 DNS Spoofing
Clients and Servers using NNTP rely heavily on the Domain Name
Service, and are thus generally prone to security attacks
based on the deliberate misassociation of IP addresses and DNS
names. Clients and Servers need to be cautious in assuming the
continuing validity of an IP number/DNS name association.
In particular, NNTP clients and servers SHOULD rely on their
name resolver for confirmation of an IP number/DNS name
association, rather than caching the result of previous host
name lookups. Many platforms already can cache host name
lookups locally when appropriate, and they SHOULD be
configured to do so. It is proper for these lookups to be
cached, however, only when the TTL (Time To Live) information
reported by the name server makes it likely that the cached
information will remain useful.
Barber [Page 58]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
If NNTP clients or servers cache the results of host name
lookups in order to achieve a performance improvement, they
MUST observe the TTL information reported by DNS.
If NNTP clients or servers do not observe this rule, they
could be spoofed when a previously accessed server's IP
address changes. As network renumbering is expected to become
increasingly common, the possibility of this form of attack
will grow. Observing this requirement thus reduces this
potential security vulnerability.
This requirement also improves the load-balancing behavior of
clients for replicated servers using the same DNS name and
reduces the likelihood of a user's experiencing failure in
accessing sites that use that strategy.
14.4 Weak Authentication and Access Control
There is no user-based or token-based authentication in the
basic NNTP specification. Access is normally controlled by
server configuration files. Those files specify access by
using domain names or IP addresses. However, this
specification does permit the creation of extensions to the
NNTP protocol itself for such purposes. While including such
mechanisms is optional, doing so is strongly encouraged.
Other mechanisms are also available. For example, a proxy
server could be put in place that requires authentication
before connecting via the proxy to the NNTP server.
15. References
[1] Kantor, B and P. Lapsley, "Network News Transfer Protocol",
RFC-977, U.C. San Diego and U.C. Berkeley.
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, Alis Technologies.
[3] Coded Character Set-7-bit American Standard Code for
Information Interchange, ANSI x3.4-1986.
[4]Bradner, Scott, "Keywords for use in RFCs to Indicate
Requirement Levels", RFC-2119, Harvard University.
[5] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
distribution, UUNET Technologies, Revision 1.10, April, 1992.
[6] Robertson, Rob, "FAQ: Overview database / NOV General
Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
nov.Z, January, 1995.
[7] International Telecommunications Union-Radio, "Glossary",
ITU-R Recommendation TF.686-1, October, 1997.
[8] Mills, David L., "Network Time Protocol (Version 3),
Specification, Implementation and Analysis", RFC-1305,
University of Delaware, March 1992.
Barber [Page 59]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
[9] Crocker, D. and Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC-2234, Internet Mail Consortium and
Demon Internet, Ltd.
16. Notes
UNIX is a registered trademark of the X/Open Consortium.
17. Acknowledgments
The author acknowledges the original authors of NNTP as
documented in RFC 977: Brian Kantor and Phil Lapsey.
The author gratefully acknowledges the work of the NNTP
committee chaired by Eliot Lear. The organization of this
document was influenced by the last available draft from this
working group. A special thanks to Eliot for generously
providing the original machine-readable sources for that
document.
The author gratefully acknowledges the work of the Marshall
Rose & John G. Meyers in RFC 1939 and the work of the DRUMS
working group, specifically RFC 1869, which is the basis of
the NNTP extensions mechanism detailed in this document.
The author gratefully acknowledges the authors of RFC 2616 for
providing specific and relevant examples of security issues
that should be considered for HTTP. Since many of the same
considerations exist for NNTP, those examples that are
relevant have been included here with some minor rewrites.
The author gratefully acknowledges the comments and additional
information provided by the following individuals in preparing
one of the progenitors of this document:
. Russ Allbery <rr...@stanford.edu>
. Wayne Davison <da...@armory.com>
. Clive D.W. Feather <cl...@demon.net>
. Chris Lewis <cl...@bnr.ca>
. Tom Limoncelli <ta...@mars.superlink.net>
. Eric Schnoebelen <er...@egsner.cirr.com>
. Rich Salz <rs...@osf.org>
Barber [Page 60]
INTERNET DRAFT S. Barber
Expires: October 30, 2001 Academ Consulting Services
March 2001
This work was motivated by the work of various news reader
authors and news server authors, which includes those listed
below:
. Rick Adams-Original author of the NNTP extensions to the
RN news reader and last maintainer of Bnews
. Stan Barber-Original author of the NNTP extensions to the
news readers that are part of Bnews.
. Geoff Collyer-Original author of the OVERVIEW database
proposal and one of the original authors of CNEWS
. Dan Curry-Original author of the xvnews news reader
. Wayne Davison-Author of the first threading extensions to
the RN news reader (commonly called TRN).
. Geoff Huston-Original author of ANU NEWS
. Phil Lapsey-Original author of the UNIX reference
implementation for NNTP
. Iain Lea-Original maintainer of the TIN news reader
. Chris Lewis-First known implementer of the AUTHINFO
GENERIC extension
. Rich Salz-Original author of INN
. Henry Spencer-One of the original authors of CNEWS
. Kim Storm-Original author of the NN news reader
18. Author's Address
Stan Barber
P.O. Box 300481
Houston, Texas 77230
Email: sob@academ.com
This document expires October 30, 2001.
Barber [Page 61]
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org