Du bon usage de...
News Article Format and Transmission
5. Mandatory Headers
An article MUST have one, and only one, of each of the fol-
lowing headers: Date, From, Message-ID, Subject, Newsgroups,
NOTE: MAIL specifies (if read most carefully) that
there must be exactly one Date header and exactly
one From header, but otherwise does not restrict
multiple appearances of headers. (Notably, it
permits multiple Message-ID headers!) This
appears singularly useless, or even harmful, in
the context of news, and much current news soft-
ware will not tolerate multiple appearances of
Note also that there are situations, discussed in the rele-
vant parts of section 6, where References, Sender, or
Approved headers are mandatory.
In the discussions of the individual headers, the content of
each is specified using the syntax notation. The convention
used is that the content of, for example, the Subject header
is defined as <Subject-content>.
The Date header contains the date and time when the article
was submitted for transmission:
Date-content = [ weekday "," space ] date space time
weekday = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
date = day space month space year
day = 1*2digit
month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun"
/ "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
year = 4digit / 2digit
time = hh ":" mm [ ":" ss ] space timezone
timezone = "UT" / "GMT"
/ ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]
hh = 2digit
mm = 2digit
ss = 2digit
zone-name = 1*( <ASCII printable character except ()\> / space )
This is a restricted subset of the MAIL date format.
If a weekday is given, it MUST be consistent with the date.
The modern Gregorian calendar is used, and dates MUST be
consistent with its usual conventions; for example, if the
month is May, the day must be between 1 and 31 inclusive.
The year SHOULD be given as four digits, and posting agents
SHOULD enforce this; however, relayers MUST accept the two-
digit form, and MUST interpret it as having the implicit
NOTE: Two-digit year numbers can, should, and must
be phased out by 1999.
The time is given on the 24-hour clock, e.g. two hours
before midnight is "22:00" or "22:00:00". The hh must be
between 00 and 23 inclusive, the mm between 0 and 59 inclu-
sive, and the ss between 0 and 61 inclusive.
NOTE: Leap seconds very occasionally result in
minutes that are 61 or 62 seconds long.
The date and time SHOULD be given in the poster's local
timezone, including a specification of that timezone as a
numeric offset (which SHOULD include the timezone name, e.g.
"EST", supplied in parentheses like a MAIL comment). If
not, they MUST be given in Universal Time (abbreviated "UT";
"GMT" is a historical synonym for "UT"). The timezone name
in parentheses, if present, is a comment; software MUST
ignore it, except that reading agents might wish to display
it to the reader. Timezone names other than "UT" and "GMT"
MUST appear only in the comment.
NOTE: Attempts to deal with a full set of timezone
names have all foundered on the vast number of
such names in use and the duplications (for exam-
ple, there are at least FIVE different timezones
called "EST" by somebody). Even the limited set
of North American zone names authorized by MAIL is
subject to confusion and misinterpretation. Hence
the flat ban on non-UT timezone names except as
NOTE: RFC 1036 specified that use of GMT (aka UT,
UTC) was preferred. However, the local time (in
the poster's timezone) is arguably information of
possible interest to the reader, and this requires
some indication of the poster's timezone. Numeric
offsets are an unambiguous way of doing this, and
their use was indeed sanctioned by RFC 1036 (that
is, this is a change of preference only).
NOTE: There is frequent confusion, including
errors in some news software, regarding the sign
of numeric timezones. Zones west of Greenwich
have negative offsets. For example, North Ameri-
can Eastern Standard Time is zone -0500 and North
American Eastern Daylight Time is zone -0400.
NOTE: Implementors are warned that the hh in a
timezone can go up to about 14; it is not limited
to 12. This is because the International Date
Line does not run exactly along the boundary
between zone -1200 and zone +1200.
NOTE: The comments in section 2.6 regarding trans-
lation to other languages are relevant here. The
Date-content format, and the spellings of its com-
ponents, as found in articles themselves, are
always as defined in this Draft, regardless of the
language used to interact with readers and
posters. Reading and posting agents should trans-
late as appropriate. Actually, even English-
language reading and posting agents will probably
want to do some degree of translation on dates, if
only to abbreviate the lengthy format and
(perhaps) translate to and from the reader's time-
The From header contains the electronic address, and possi-
bly the full name, of the article's author:
From-content = address [ space "(" paren-phrase ")" ]
/ [ plain-phrase space ] "<" address ">"
paren-phrase = 1*( paren-char / space / encoded-word )
paren-char = <ASCII printable character except ()<>\>
plain-phrase = plain-word *( space plain-word )
plain-word = unquoted-word / quoted-word / encoded-word
unquoted-word = 1*unquoted-char
unquoted-char = <ASCII printable character except !()<>@,;:\".>
quoted-word = quote 1*( quoted-char / space ) quote
quote = <" (ASCII 34)>
quoted-char = <ASCII printable character except "()<>\>
address = local-part "@" domain
local-part = unquoted-word *( "." unquoted-word )
domain = unquoted-word *( "." unquoted-word )
(Encoded words are described in section 4.5.) The full name
is distinguished from the electronic address either by
enclosing the former in parentheses (making it resemble a
MAIL comment, after the address) or by enclosing the latter
in angle brackets. The second form is preferred. In the
first form, encoded words inside the full name MUST be com-
posed entirely of <paren-char>s. In the second form,
encoded words inside the full name may not contain charac-
ters other than letters (of either case), digits, and the
characters "!", "*", "+", "-", "/", "=", and "_". The local
part is case-sensitive (except that all case counterparts of
"postmaster" are deemed equivalent), the domain is case-
insensitive, and all other parts of the From content are
comments which MUST be ignored by news software (except
insofar as reading agents may wish to display them to the
reader). Posters and posting agents MUST restrict them-
selves to this subset of the MAIL From syntax; relayers MAY
accept a broader subset, but see the discussion in section
NOTE: The syntax here is a restricted subset of
the MAIL From syntax, with quoting particularly
restricted, for simple parsing. In particular,
the presence of "<" in the From content indicates
that the second form is being used, otherwise the
first form is being used. The major restrictions
here are those already de-facto imposed by exist-
NOTE: Overly-lenient posting agents sometimes per-
mit the second form with a full name containing
"(" or ")", but it is extremely rare for a full
name to contain "<" or ">" even in mail. Accord-
ingly, reading agents wishing to robustly deter-
mine which form is in use in a particular article
should key on the presence or absence of "<", not
the presence or absence of "(".
The address SHOULD be a valid and complete Internet domain
address, capable of being successfully mailed to by an
Internet host (possibly via an MX record and a forwarder).
The pseudo-domain ".uucp" MAY be used for hosts registered
in the UUCP maps (e.g. name "xyz.uucp" for registered site
"xyz"), but such hosts SHOULD discontinue this usage (either
by arranging a proper Internet address and forwarder, or by
using the "% hack" (see below)), as soon as possible. Bit-
net hosts SHOULD use Internet addresses, avoiding the obso-
lescent ".bitnet" pseudo-domain. Other forms of address
MUST not be used.
NOTE: "Other forms" specifically include UK-style
"backward" domains ("uk.oxbridge.cs" is in the
Czech Republic, not the UK), pure-UUCP addressing
("knee!shin!foot" instead of
"firstname.lastname@example.org"), and abbreviated domains
("zebra.zoo" instead of "zebra.zoo.toronto.edu").
If it is necessary to use the local part to specify a rout-
ing relative to the nearest Internet host, this MUST be done
using the "% hack", using "%" as a secondary "@". For exam-
ple, to specify that mail to the address should go to Inter-
net host "foo.bar.edu", then to non-Internet host "ein",
then to non-Internet host "deux", for delivery there to
mailbox "fred", a suitable address would be:
Analogous forms using "!" in the local part MUST not be
used, as they are ambiguous; they should be expressed in the
NOTE: "a!b@c" can be interpreted as either "b%c@a"
or "b%a@c", and there is no consistency in which
choice is made. Such addresses consequently are
unreliable. The "%" form does not suffer from
this problem, and although its use is officially
discouraged, it is a de-facto standard, to the
point that MAIL recognizes it.
Relayers MUST not, repeat MUST not, repeat MUST not, rewrite
From lines, in any way, however minor or innocent-seeming.
Trying to "fix" a non-conforming address has a very high
probability of making things worse. Either pass it along
unchanged, or reject the article.
NOTE: An additional reason for banning the use of
"!" addressing is that it has a much higher proba-
bility of being rewritten into mangled unrecogniz-
ability by old relayers.
Posters and posting agents SHOULD avoid use of the charac-
ters "!" and "@" in full names, as they may trigger unwanted
header rewriting by old, simple-minded news software.
NOTE: Also, the characters "." and ",", not infre-
quently found in names (e.g., "John W. Campbell,
Jr."), are NOT, repeat NOT, allowed in an unquoted
word. A From header like the following MUST not
be written without the quotation marks:
From: "John W. Campbell, Jr." <email@example.com>
The Message-ID header contains the article's message ID, a
unique identifier distinguishing the article from every
Message-ID-content = message-id
message-id = "<" local-part "@" domain ">"
As with From addresses, a message ID's local part is case-
sensitive and its domain is case-insensitive. The "<" and
">" are parts of the message ID, not peculiarities of the
NOTE: News message IDs are a restricted subset of
MAIL message IDs. In particular, no existing news
software copes properly with MAIL quoting conven-
tions within the local part, so they are forbid-
den. This is unfortunate, particularly for X.400
gateways that often wish to include characters
which are not legal in unquoted message IDs, but
it is impossible to fix net-wide. See the notes
on gatewaying in section 10.
The domain in the message ID SHOULD be the full Internet
domain name of the posting agent's host. Use of the ".uucp"
pseudo-domain (for hosts registered in the UUCP maps) or the
".bitnet" pseudo-domain (for Bitnet hosts) is permissible,
but SHOULD be avoided.
Posters and posting agents MUST generate the local part of a
message ID using an algorithm which obeys the specified syn-
tax (words separated by ".", with certain characters not
permitted) (see section 5.2 for details), and will not
repeat itself (ever). The algorithm SHOULD not generate
message IDs which differ only in case of letters. Note the
specification in section 6.5 of a recommended convention for
indicating subject changes. Otherwise the algorithm is up
to the implementor.
NOTE: The crucial use of message IDs is to distin-
guish circulating articles from each other and
from articles circulated recently. They are also
potentially useful as permanent indexing keys,
hence the requirement for permanent uniqueness...
but indexers cannot absolutely rely on this
because the earlier RFCs urged it but did not
demand it. All major implementations have always
generated permanently-unique message IDs by
design, but in some cases this is sensitive to
proper administration, and duplicates may have
occurred by accident.
NOTE: The most popular method of generating local
parts is to use the date and time, plus some way
of distinguishing between simultaneous postings on
the same host (e.g. a process number), and encode
them in a suitably-restricted alphabet. An older
but now less-popular alternative is to use a
sequence number, incremented each time the host
generates a new message ID; this is workable, but
requires careful design to cope properly with
simultaneous posting attempts, and is not as
robust in the presence of crashes and other mal-
NOTE: Some buggy news software considers message
IDs completely case-insensitive, hence the advice
to avoid relying on case distinctions. The
restrictions placed on the "alphabet" of local
parts and domains in section 5.2 have the useful
side effect of making it unnecessary to parse mes-
sage IDs in complex ways to break them into case-
sensitive and case-insensitive portions.
The local part of a message ID MUST not be "postmaster" or
any other string that would compare equal to "postmaster" in
a case-insensitive comparison. Message IDs MUST be no
longer than 250 octets, including the "<" and ">".
NOTE: "Postmaster" is an irksome exception to
case-sensitivity in local parts, inherited from
MAIL, and simply avoiding it is the best way to
deal with it (not that it's likely, but the issue
needs to be dealt with). The length limit is
undesirable, but is present in widely-used exist-
ing software. The limit is actually 255, but a
small safety margin is wise.
The Subject header's content (the "subject" of the article)
is a short phrase describing the topic of the article:
Subject-content = [ "Re: " ] nonblank-text
Encoded words MAY appear in this header.
If the article is a followup, the subject SHOULD begin with
"Re: " (a "back reference"). If the article is not a fol-
lowup, the subject MUST not begin with a back reference.
Back references are case-insensitive, although "Re: " is the
preferred form. A followup agent assisting a poster in
preparing a followup SHOULD prepend a back reference, UNLESS
the subject already begins with one. If the poster deter-
mines that the topic of the followup differs significantly
from what is described in the subject, a new, more descrip-
tive, subject SHOULD be substituted (with no back refer-
ence). An article whose subject begins with a back refer-
ence MUST have a References header referencing the precur-
NOTE: A back reference is FOUR characters, the
fourth being a blank. RFC 1036 was confused about
this. Observe also that only ONE back reference
should be present.
NOTE: There is a semi-standard convention, often
used, in which a subject change is flagged by mak-
ing the new Subject-content of the form:
new topic (was: old topic)
possibly with "old topic" somewhat truncated.
Posters wishing to do something like this are
urged to use this exact form, to simplify auto-
For historical reasons, the subject MUST not begin with
"cmsg " (note that this sequence ends with a blank).
NOTE: Some old news software takes a subject
beginning with "cmsg " as an indication that the
article is a control message (see sections 6.6 and
7). This mechanism is obsolete and undesirable,
but accidental triggering of it is still possible.
The subject SHOULD be terse. Posters SHOULD avoid trying to
cram their entire article into the headers; even the sim-
plest query usually benefits from a sentence or two of
elaboration and context, and the details of header display
vary widely among reading agents.
NOTE: All-in-the-subject articles are sometimes
the result of misunderstandings over the interac-
tion protocol of a posting agent. Posting agents
might wish to give special attention to the possi-
bility that a poster specifying a very long sub-
ject might have thought he was typing the body of
The Newsgroups header's content specifies which newsgroup(s)
the article is posted to:
Newsgroups-content = newsgroup-name *( ng-delim newsgroup-name )
newsgroup-name = plain-component *( "." component )
component = plain-component / encoded-word
plain-component = component-start *13component-rest
component-start = lowercase / digit
lowercase = <letter a-z>
component-rest = component-start / "+" / "-" / "_"
ng-delim = ","
Encoded words used in newsgroup names MUST not contain char-
acters other than letters, digits, "+", "-", "/", "_", "=",
and "?" (although they may encode them).
A newsgroup name consists of one or more components, which
may be plain components or (except for the first) encoded
words. A plain component MUST contain at least one letter,
MUST begin with a letter or digit, and MUST not be longer
than 14 characters. The first component MUST begin with a
letter; subsequent components SHOULD begin with a letter.
Newsgroup names MUST not contain uppercase letters, except
where required by encodings in encoded words. The sequences
"all" and "ctl" MUST not be used as components.
NOTE: The alphabet and syntax specified encom-
passes all existing names of widespread news-
groups, while avoiding various forms that are
known to cause problems. Important existing soft-
ware uses various non-alphanumeric characters as
punctuation adjacent to newsgroup names. (It
would, in fact, be preferable to ban "+" from
newsgroup names, were it not that several
widespread newsgroups related to the C++ program-
ming language already use it.)
NOTE: Much existing software converts the news-
group name into a directory path and stores the
articles themselves using numeric filenames, so
all-digit name components can be troublesome; the
"Great Renaming" early in the history of Usenet
included revisions of several newsgroup names to
eliminate such components.
NOTE: The same storage technique is the reason for
the 14-character limit. The limit is now largely
historical, since most modern systems have much
larger limits on the length of a directory entry's
name, but many old systems are still in use. Sys-
tems with shorter limits also exist, but news
software on such systems has had to deal with the
problem already, since there are several
widespread newsgroups with 14-character components
in their names. Implementors are warned that it
is intended that the successor to this Draft will
increase the 14-character limit, and are urged to
fix their software to handle longer names grace-
fully (if such fixes are necessary, given the
intended domain of application of the particular
NOTE: The requirement that the first character of
a name be a letter accommodates existing software
which assumes it can tell the difference between a
newsgroup name and other possible syntactic enti-
ties by inspecting the first character. Similar
considerations motivate excluding "+", "-", and
"_" from coming first in a component, and the
preference for components that do not begin with
digits. The "all" sequence is used as a wildcard
symbol in much existing software, and the "ctl"
sequence was involved in an obsolete historical
mechanism for marking control messages, so they
are best avoided.
NOTE: Possibly newsgroup names should have been
case-insensitive, but all existing software treats
them as case-sensitive. (RFC 977 [rrr] claims
that they are case-insensitive in NNTP, but exist-
ing implementations are believed to ignore this.)
The simplest solution is just to ban use of upper-
case letters, since no widespread newsgroup name
uses them anyway; this avoids any possibility of
NOTE: The syntax has the disadvantage of contain-
ing no white space, making it impossible to con-
tinue a Newsgroups header across several lines.
Implementors of relayers and reading agents are
warned that it is intended that the successor to
this Draft will change the definition of ng-delim
ng-delim = "," [ space ]
and are urged to fix their software to handle
(i.e., ignore) white space following the commas.
Meanwhile, posters must avoid inserting such space
(despite the natural-language convention which
permits it) and posting agents should strip it
NOTE: Encoded words as components are somewhat
problematic, but are clearly desirable for use in
non-English-speaking nations. They are not sub-
ject to the 14-character limit, and this (plus the
possibility of "/" within them) may require spe-
cial handling in news software.
Encoded words are allowed in newsgroup names ONLY where non-
ASCII characters are necessary to the name, and must use the
"b" encoding [rrr] and the first suitable character set in
the MIME order of preferred character sets [rrr].
NOTE: Since the newsgroup name is the encoded
form, NOT the underlying non-ASCII form, there is
room for terrible confusion here if the choice of
encoding for a particular name is not fully stan-
Posters SHOULD use only the names of existing newsgroups in
the Newsgroups header, because newsgroups are NOT created
simply by being posted to. However, it is legitimate to
cross-post to newsgroup(s) which do not exist on the posting
agent's host, provided that at least one of the newsgroups
DOES exist there, and followup agents MUST accept this
(posting agents MAY accept it, but SHOULD at least alert the
poster to the situation and request confirmation). Relayers
MUST not rewrite Newsgroups headers in any way, even if some
or all of the newsgroups do not exist on the relayer's host.
NOTE: Early experience with news software that
created newsgroups when they were mentioned in a
Newsgroups header was thoroughly negative: posters
frequently mistype newsgroup names.
NOTE: While it is legitimate for some of an arti-
cle's newsgroups not to exist on the host where it
is posted, this IS a rather unusual situation
except in followups (which should go to all news-
groups the precursor was posted to, even if not
all of them reach the site where the followup is
NOTE: Rewriting Newsgroups headers to strip
locally-unknown newsgroups is superficially
attractive. However, early experience with
exactly that policy was thoroughly negative: news
propagation is more redundant and much less
orderly than many people imagine, and in particu-
lar it is not unheard-of for the (sometimes)
fastest path between two (say) U of Toronto sites
to pass outside U of Toronto... in which case
newsgroup stripping can cause incomplete propaga-
tion. Having an article's set of newsgroups
change as it propagates can also result in fol-
lowups not achieving the same propagation as the
original. It's been tried; it's more trouble than
it's worth; don't do it.
NOTE: In particular, newsgroup stripping superfi-
cially looks like a solution to the problem of
duplicate regional newsgroup names. For example,
both University of Toronto and University of Texas
have "ut.general" newsgroups, and material cross-
posted to that name and a global newsgroup appears
in both universities' local newsgroups. However,
the side effects of stripping are sufficiently
unacceptable to disqualify it for this purpose.
Don't do it.
Cross-posting an article to several relevant newsgroups is
far superior to posting separate articles with duplicated
content to each newsgroup, because reading agents can detect
the situation and show the article to a reader only once.
Posters SHOULD cross-post rather than duplicate-post.
NOTE: On the other hand, cross-posting to a large
number of newsgroups usually indicates that the
poster has not thought about his audience; arti-
cles are rarely pertinent to more than (say) half
a dozen newsgroups. Posting agents might wish to
request confirmation when the number of newsgroups
exceeds (say) five in the presence of a Followup-
To header, or (say) two in the absence of such a
NOTE: One problem with cross-postings is what to
do with an article cross-posted to a set of news-
groups including both moderated and unmoderated
ones. Posters tend to expect such an article to
show up immediately in the unmoderated newsgroups,
especially if they do not realize that one or more
of the newsgroups is moderated. However, since it
is not possible for a moderator to retroactively
add an already-posted article to a moderated news-
group, the only correct action is to mail such an
article to one (and only one) of the moderators
for action. It is probably best for the posting
agent to detect this situation and ask the poster
what action is preferred. The acceptable choices
are to alter the newsgroup list or to mail to a
moderator of the poster's choice; the posting
agent should NOT offer duplicate-posting as an
easy-to-request option (if only because many mod-
erators will reject a submission that has already
been posted to unmoderated newsgroups).
NOTE: An article cross-posted to multiple moder-
ated newsgroups really should have approval from
all the moderators involved. In practice, the
only straightforward way to do this is to send the
article to one of them and have him consult the
A newsgroup SHOULD not appear more than once in the News-
Newsgroup names having only one component are reserved for
newsgroups whose propagation is restricted to a single host
(or the administrative equivalent). It is inadvisable to
name a newsgroup "poster" because that word has special
meaning in the Followup-To header (see section 6.1). The
names "control" and "junk" are frequently used for pseudo-
newsgroups internal to relayer implementations, and hence
are also best avoided.
NOTE: Beware of the duplicate-regional-newsgroup-
names problem mentioned above. In particular,
there are many, many hosts with a newsgroup named
"general", and some surprising things show up in
such newsgroups when people cross-post. It is
probably better to use multi-component names,
which are less likely to be duplicated. Fred's
Widget House should use "fwh.general" rather than
just "general" as its in-house general-topics
It is conventional to reserve newsgroup names beginning with
"to." for test messages sent on an essentially point-to-
point basis (see also the ihave/sendme protocol described in
section 7.2); newsgroup names beginning with "to." SHOULD
not be used for any other purpose. The second (and possibly
later) components of such a name should, together, comprise
the relayer name (see section 5.6) of a relayer. The news-
group exists only at the named relayer and its neighbors.
The neighbors all pass that newsgroup to the named relayer,
while the named relayer does not pass it to anyone.
The order of newsgroup names in the Newsgroups header is not
The Path header's content indicates which relayers the arti-
cle has already visited, so that unnecessary redundant
transmission can be avoided:
Path-content = [ path-list path-delimiter ] local-part
path-list = relayer-name *( path-delimiter relayer-name )
relayer-name = 1*rn-char
rn-char = letter / digit / "." / "-" / "_"
path-delimiter = "!"
The Path content is a list of relayer names, separated by
path delimiters, followed (after a final delimiter) by the
local part of a mailing address. Each relayer MUST prepend
its name, and a delimiter, to the Path content in all arti-
cles it processes. A relayer MUST not pass an article to a
neighboring relayer whose name is already mentioned in an
article's path list, unless this is explicitly requested by
the neighbor in some way. The Path content is case-
NOTE: The Path header supplied by a posting agent
should normally contain only the local part. The
relayer that the posting agent passes the article
to for posting will prepend its relayer name to
get the path list started.
NOTE: Observe that the trailing local part is NOT
part of the path list. This Path header:
contains three relayer names: "fee", "fie", and
"foe". A relayer named "fum" is still eligible to
be sent this article.
NOTE: This syntax has the disadvantage of contain-
ing no white space, making it impossible to con-
tinue a Path header across several lines. Imple-
mentors of relayers and reading agents are warned
that it is intended that the successor to this
Draft will change the definition of path delimiter
path-delimiter = "!" [ space ]
and are urged to fix their software to handle
(i.e., ignore) white space following the exclama-
tion points. They are urged to hurry; some ill-
behaved systems reportedly already feel free to
add such white space.
NOTE: RFC 1036 allows considerably more flexibil-
ity in choice of delimiter, in theory, but this
flexibility has never been used and most news
software does not implement it properly. The
grammar reflects the current reality. Note, in
particular, that RFC 1036 treats "_" as a delim-
iter, but in fact it is known to appear in relayer
Because an article will not propagate to a relayer already
mentioned in its path list, the path list MUST not contain
any names other than those of relayers the article has
passed through AS NEWS. This is trivially obvious for nor-
mal news articles, but requires attention from the modera-
tors of moderated newsgroups and the implementors and main-
tainers of gateways.
NOTE: For the same reason, a relayer and its
neighbors need to agree on the choice of relayer
name, and names should not be changed without
Relayer names need to be unique among all relayers which
will ever see the articles using them. A relayer name is
normally either an "official" name for the host the relayer
runs on, or some other "official" name controlled by the
same organization. Except in cooperating subnets that agree
to some other convention, and don't let articles using it
escape beyond the subnet, a relayer name MUST be either a
UUCP name registered in the UUCP maps (without any domain
suffix such as ".UUCP"), or a complete Internet domain name.
Use of a (registered) UUCP name is recommended, where prac-
tical, to keep the length of the path list down.
The use of Internet domain names in the path list presents
one problem: domain names are case-insensitive, but the path
list is case-sensitive. Relayers using domain names as
their relayer names MUST pick a standard form for the name,
and use that form consistently to the exclusion of all oth-
ers. The preferred form for this purpose, which relayers
SHOULD use, is the all-lowercase form.
NOTE: It is arguably unfortunate that the path
list is case-sensitive, but it is much too late to
change this. Most Internet sites do, in any
event, use one standardized form of their name
In the ordinary case, where the poster is the author of the
article, the local part following the path list SHOULD be
the local part of the poster's full Internet domain mailing
NOTE: It should be just the local part, not the
full address. The character "@" does not appear
in a Path header.
The Path content somewhat resembles a mailing address, par-
ticularly in the UUCP world with its manual routing and "!"
address syntax. Historically, this resemblance was impor-
tant, and the Path content was often used as a reply
address. This practice has always been somewhat unreliable,
since news paths are not always mail paths and news relayer
names are not always recognized by mail handlers, and its
reliability has generally worsened in recent times. The
widespread use of and recognition of Internet domain
addresses, even outside the actual Internet, has largely
eliminated the problem. Readers SHOULD not use the Path
content as a reply address. On the other hand, relayer
administrators are urged not to break this usage without
good reason; where practical, paths followed by news SHOULD
be traversable by mail, and mail handlers SHOULD recognize
relayer names as host names.
It will typically be difficult or impractical for gateways
and moderators to supply a Path content that is useful as a
reply address for the author, bearing in mind that the path
list they supply will normally be empty. (To reiterate: the
path list MUST not contain any names other than those of
relayers the article has passed through AS NEWS.) They
SHOULD supply a local part that will result in replies to a
Path-derived address being returned to the sender with a
brief explanation. Software permitting, the local part
"not-for-mail" is recommended.
NOTE: A moderator or gateway administrator who
supplies a local part that delivers such mail to
an administrative mailbox will quickly discover
why it should be bounced automatically! It is
best, however, for the returned message to include
an explanation of what has probably happened,
rather than just a mysterious "undeliverable mail"
complaint, since the sender may not be aware that
his/her software is unwisely using the Path con-
tent as a reply address. Reply software might
wish to question attempts to reply to a Path-
derived address ending in "not-for-mail" (which is
why a specific name is being recommended here).
6. Optional Headers
Many MAIL headers, and many of those specified in present
and future MAIL extensions, are potentially applicable to
news. Headers specific to MAIL's point-to-point transmis-
sion paradigm, e.g. To and Cc, SHOULD not appear in news
articles. (Gateways wishing to preserve such information
for debugging probably SHOULD hide it under different names;
prefixing "X-" to the original headers, resulting in e.g.
"X-To", is suggested.)
The following optional headers are either specific to news
or of particular note in news articles; an article MAY con-
tain some or all of them. (Note that there are some circum-
stances in which some of them are mandatory; these are
explained under the individual headers.) An article MUST
not contain two or more headers with any one of these header
NOTE: The ban on duplicate header names does not
apply to headers not specified in this Draft at
all, such as "X-" headers. Software should not
assume that all header names in a given article
The Followup-To header contents specify which newsgroup(s)
followups should be posted to:
Followup-To-content = Newsgroups-content / "poster"
The syntax is the same as that of the Newsgroups content,
with the exception that the magic word "poster" means that
followups should be mailed to the article's reply address
rather than posted. In the absence of Followup-To, the
default newsgroup(s) for a followup are those in the News-
NOTE: The way to request that followups be mailed
to a specific address other than that in the From
line is to supply "Followup-To: poster" and a
Reply-To header. Putting a mailing address in the
Followup-To line is incorrect; posting agents
should reject or rewrite such headers.
NOTE: There is no syntax for "no followups
allowed" because "Followup-To: poster" accom-
plishes this effect without extra machinery.
Although it is generally desirable to limit followups to the
smallest reasonable set of newsgroups, especially when the
precursor was cross-posted widely, posting agents SHOULD not
supply a Followup-To header except at the poster's explicit
NOTE: In particular, it is incorrect for the post-
ing agent to assume that followups to a cross-
posted article should be directed to the first
newsgroup only. Trimming the list of newsgroups
should be the poster's decision, not the posting
agent's. However, when an article is to be cross-
posted to a considerable number of newsgroups, a
posting agent might wish to SUGGEST to the poster
that followups go to a shorter list.
The Expires header content specifies a date and time when
the article is deemed to be no longer useful and should be
Expires-content = Date-content
The content syntax is the same as that of the Date content.
In the absence of Expires, the default is decided by the
administrators of each host the article reaches, who MAY
also restrict the extent to which the Expires header is hon-
The Expires header has two main applications: removing arti-
cles whose utility ends on a specific date (e.g., event
announcements which can be removed once the day of the event
is past) and preserving articles expected to be of prolonged
usefulness (e.g., information aimed at new readers of a
newsgroup). The latter application is sometimes abused.
Since individual hosts have local policies for expiration of
news (depending on available disk space, for instance),
posters SHOULD not provide Expires headers for articles
unless there is a natural expiration date associated with
the topic. Posting agents MUST not provide a default
Expires header. Leave it out and allow local policies to be
used unless there is a good reason not to. Expiry dates are
properly the decision of individual host administrators;
posters and moderators SHOULD set only expiry dates that
most administrators would agree with.
NOTE: A poster preparing an Expires header for an
article whose utility ends on a specific day
should typically specify the NEXT day as the
expiry date. A meeting on July 7th remains of
interest on the 7th.
The Reply-To header content specifies a reply address dif-
ferent from the author's address given in the From header:
Reply-To-content = From-content
In the absence of Reply-To, the reply address is the address
in the From header.
Use of a Reply-To header is preferable to including a simi-
lar request in the article body, because reply-preparation
software can take account of Reply-To automatically.
The Sender header identifies the poster, in the event that
this differs from the author identified in the From header:
Sender-content = From-content
In the absence of Sender, the default poster is the author
(named in the From header).
NOTE: The intent is that the Sender header have a
fairly high probability of identifying the person
who really posted the article. The ability to
specify a From header naming someone other than
the poster is useful but can be abused.
If the poster supplies a From header, the posting agent MUST
ensure that a Sender header is present, unless it can verify
that the mailing address in the From header is a valid mail-
ing address for the poster. A poster-supplied Sender header
MAY be used, if its mailing address is verifiably a valid
mailing address for the poster; otherwise the posting agent
MUST supply a Sender header and delete (or rename, e.g. to
X-Unverifiable-Sender) any poster-supplied Sender header.
NOTE: It might be useful to preserve a poster-
supplied Sender header so that the poster can sup-
ply the full-name part of the content. The mail-
ing address, however, must be right. Hence, the
posting agent must generate the Sender header if
it is unable to verify the mailing address of a
NOTE: NNTP implementors, in particular, are urged
to note this requirement (which would eliminate
the need for ad hoc headers like NNTP-Posting-
Host), although there are admittedly some imple-
mentation difficulties. A user name from an RFC
1413 server and a host name from an inverse map-
ping of the address, perhaps with a "full name"
comment noting the origin of the information,
would be at least a first approximation:
Sender: firstname.lastname@example.org (RFC-1413@reverse-lookup; not verified)
While this does not completely meet the specs, it
comes a lot closer than not having a Sender header
at all. Even just supplying a placeholder for the
Sender: email@example.com (user name unknown)
would be better than nothing.
The References header content lists message IDs of precur-
References-content = message-id *( space message-id )
A followup MUST have a References header, and an article
which is not a followup MUST not have a References header.
In a followup, if the precursor had a References header, the
message ID of the precursor is appended to the end of the
precursor's References-content to form the followup's Refer-
ences-content. a References header containing the precur-
sor's message ID. A followup to an article which had a Ref-
erences header MUST have a References header containing the
precursor's References content, plus the precursor's message
ID appended to the end of the list.
NOTE: Use the See-Also header (section 6.16) for
interconnection of articles which are not in a
followup relationship to each other.
NOTE: In retrospect, RFCs 850 and 1036, and the
implementations whose practice they represented,
erred here. The proper MAIL header to use for
references to precursors is In-Reply-To, and the
References header is meant to be used for the pur-
poses here ascribed to See-Also. This incompati-
bility is far too solidly established to be fixed,
unfortunately. The best that can be done is to
provide a clear mapping between the two, and urge
gateways to do the transformation. The news usage
is (now) a deliberate violation of the MAIL speci-
fications; articles containing news References
headers are technically not valid MAIL messages,
although it is unlikely that much MAIL software
will notice because the incompatibility is at a
subtle semantic level that does not affect the
UNRESOLVED ISSUE: Would it be better to just give
up and admit that news uses References for both
UNRESOLVED ISSUE: Should the syntax be generalized
to include URLs as alternatives to message IDs?
Perhaps not; too many things know about References
already. And non-articles can't be precursors of
articles, not really.
Followup agents SHOULD not shorten References headers. If
it is absolutely necessary to shorten the header, as a des-
perate last resort, a followup agent MAY do this by deleting
some of the message IDs. However, it MUST not delete the
first message ID, the last three message IDs (including that
of the immediate precursor), or any message ID mentioned in
the body of the followup. If it is possible for the fol-
lowup agent to determine the Subject content of the articles
identified in the References header, it MUST not delete the
message ID of any article where the Subject content changed
(other than by prepending of a back reference). The fol-
lowup agent MUST not delete any message ID whose local part
ends with "_-_" (underscore (ASCII 95), hyphen (ASCII 45),
underscore); followup agents are urged to use this form to
mark subject changes, and to avoid using it otherwise.
NOTE: As software capable of exploiting References
chains has grown more common, the random shorten-
ing permitted by RFC 1036 has become increasingly
troublesome. ANY shortening is undesirable, and
software should do it only in cases of dire neces-
sity. In such cases, these rules attempt to limit
NOTE: The first message ID is very important as
the starting point of the "thread" of discussion,
and absolutely should not be deleted. Keeping the
last three message IDs gives thread-following
software a fighting chance to reconstruct a full
thread even if an article or two is missing.
Keeping message IDs mentioned in the body is obvi-
NOTE: Subject changes are difficult to determine,
but they are significant as possible beginnings of
new threads. The "_-_" convention is provided so
that posting agents (which have more information
about subjects) can flag articles containing a
subject change in a way that followup agents can
detect without access to the articles themselves.
The sequence is chosen as one that is fairly
unlikely to occur by accident.
NOTE: Is "_-_" really worth having?
When a References header is shortened, at least three blanks
SHOULD be left between adjacent message IDs at each point
where deletions were made. Software preparing new Refer-
ences headers SHOULD preserve multiple blanks in older Ref-
NOTE: It's desirable to have some marker of where
deletions occurred, but the restricted syntax of
the header makes this difficult. Extra white
space is not a very good marker, since it may be
deleted by software that ill-advisedly rewrites
headers, but at least it doesn't break existing
To repeat: followup agents SHOULD not shorten References
NOTE: Unfortunately, reading agents and other
software analyzing References patterns have to be
prepared for the worst anyway. The worst includes
random deletions and the possibility of circular
References chains (when References is misused in
place of See-Also, section 6.16).
The Control header content marks the article as a control
message, and specifies the desired actions (other than the
usual ones of filing and passing on the article):
Control-content = verb *( space argument )
verb = 1*( letter / digit )
argument = 1*<ASCII printable character>
The verb indicates what action should be taken, and the
argument(s) (if any) supply details. In some cases, the
body of the article may also contain details. Section 7
describes the standard verbs. See also the Also-Control
header (section 6.15).
NOTE: Control messages are often processed and
filed rather differently than normal articles.
NOTE: The restriction of verbs to letters and dig-
its is new, but is consistent with existing prac-
tice and potentially simplifies implementation by
avoiding characters significant to command inter-
preters. Beware that the arguments are under no
such restriction in general.
NOTE: Two other conventions for distinguishing
control messages from normal articles were for-
merly in use: a three-component newsgroup name
ending in ".ctl" or a subject beginning with
"cmsg " was considered to imply that the article
was a control message. These conventions are
obsolete. Do not use them.
An article with a Control header MUST not have an Also-
Control or Supersedes header.
The Distribution header content specifies geographic or
organizational limits on an article's propagation:
Distribution-content = distribution *( dist-delim distribution )
dist-delim = ","
distribution = plain-component
A distribution is syntactically identical to a one-component
newsgroup name, and must satisfy the same rules and restric-
tions. In the absence of Distribution, the default distri-
bution is "world".
NOTE: This syntax has the disadvantage of contain-
ing no white space, making it impossible to con-
tinue a Distribution header across several lines.
Implementors of relayers and reading agents are
warned that it is intended that the successor to
this Draft will change the definition of dist
dist-delim = "," [ space ]
and are urged to fix their software to handle
(i.e., ignore) white space following the commas.
A relayer MUST not pass an article to another relayer unless
configuration information specifies transmission to that
other relayer of BOTH (a) at least one of the article's
newsgroup(s), and (b) at least one of the article's distri-
bution(s). In effect, the only role of distributions is to
limit propagation, by preventing transmission of articles
that would have been transmitted had the decision been based
solely on newsgroups.
A posting agent might wish to present a menu of possible
distributions, or suggest a default, but normally SHOULD not
supply a default without giving the poster a chance to over-
ride it. A followup agent SHOULD initially supply the same
Distribution header as found in the precursor, although the
poster MAY alter this if appropriate.
Despite the syntactic similarity and some historical confu-
sion, distributions are NOT newsgroup names. The whole
point of putting a distribution on an article is that it is
DIFFERENT from the newsgroup(s). In general, a meaningful
distribution corresponds to some sort of region of propaga-
tion: a geographical area, an organization, or a cooperating
NOTE: Distributions have historically suffered
from the completely uncontrolled nature of their
name space, the lack of feedback to posters on
incomplete propagation resulting from use of ran-
dom trash in Distribution headers, and confusion
with newsgroups (arising partly because many
regions and organizations DO have internal news-
groups with names resembling their internal dis-
tributions). This has resulted in much garbage in
Distribution headers, notably the pointless prac-
tice of automatically supplying the first compo-
nent of the newsgroup name as a distribution
(which is MOST unlikely to restrict propagation!).
Many sites have opted to maximize propagation of
such ill-formed articles by essentially ignoring
distributions. This unfortunately interferes with
legitimate uses. The situation is bad enough that
distributions must be considered largely useless
except within cooperating subnets that make an
organized effort to restrain propagation of their
NOTE: The distributions "world" and "local" have
no standard magic meaning (except that the former
is the default distribution if none is given).
Some pieces of software do assign such meanings to
The Keywords header content is one or more phrases intended
to describe some aspect of the content of the article:
Keywords-content = plain-phrase *( "," [ space ] plain-phrase )
Keywords, separated by commas, each follow the <plain-
phrase> syntax defined in section 5.2. Encoded words in
keywords MUST not contain characters other than letters (of
either case), digits, and the characters "!", "*", "+", "-",
"/", "=", and "_".
NOTE: Posters and posting agents are asked to take
note that keywords are separated by commas, not by
white space. The following Keywords header con-
tains only one keyword (a rather unlikely and
Keywords: Thompson Ritchie Multics Linux
and should probably have been written:
Keywords: Thompson, Ritchie, Multics, Linux
This particular error is unfortunately rather
NOTE: Reading agents and archivers preparing
indexes of articles should bear in mind that user-
chosen keywords are notoriously poor for indexing
purposes unless the keywords are picked from a
predefined set (which they are not in this case).
Also, some followup agents unwisely propagate the
Keywords header from the precursor into the fol-
lowup by default. At least one news-based experi-
ment has found the contents of Keywords headers to
be completely valueless for indexing.
The Summary header content is a short phrase summarizing the
Summary-content = nonblank-text
As with the subject, no restriction is placed on the content
since it is intended solely for display to humans.
NOTE: Reading agents should be aware that the Sum-
mary header is often used as a sort of secondary
Subject header, and (if present) its contents
should perhaps be displayed when the subject is
The summary SHOULD be terse. Posters SHOULD avoid trying to
cram their entire article into the headers; even the sim-
plest query usually benefits from a sentence or two of elab-
oration and context, and not all reading agents display all
The Approved header content indicates the mailing addresses
(and possibly the full names) of the persons or entities
approving the article for posting:
Approved-content = From-content *( "," [ space ] From-content )
An Approved header is required in all postings to moderated
newsgroups; the presence or absence of this header allows a
posting agent to distinguish between articles posted by the
moderator (which are normal articles to be posted normally)
and attempted contributions by others (which should be
mailed to the moderator for approval). An Approved header
is also required in certain control messages, to reduce the
probability of accidental posting of same; see the relevant
parts of section 7.
NOTE: There is, at present, no way to authenticate
Approved headers to ensure that the claimed
approval really was bestowed. Nor is there an
established mechanism for even maintaining a list
of legitimate approvers (such a list would quickly
become out of date if it had to be maintained by
hand). Such mechanisms, presumably relying on
cryptographic authentication, would be a worth-
while extension to this Draft, and experimental
work in this area is encouraged. (The problem is
harder than it sounds because news is used on many
systems which do not have real-time access to key
NOTE: Relayer implementors, please note well: it
is the POSTING AGENT that is authorized to distin-
guish between moderator postings and attempted
contributions, and to mail the latter to the mod-
erator. As discussed in section 9.1, relayers
MUST not, repeat MUST not, send such mail; on
receipt of an unApproved article in a moderated
newsgroup, they should discard the article, NOT
transform it into a mail message (except perhaps
to a local administrator).
NOTE: RFC 1036 restricted Approved to a single
From-content. However, multiple moderation is no
longer rare, and multi-moderator Approved headers
are already in use.
The Lines header content indicates the number of lines in
the body of the article:
Lines-content = 1*digit
The line count includes all body lines, including the signa-
ture if any, including empty lines (if any) at beginning or
end of the body. (The single empty separator line between
the headers and the body is not part of the body.) The
"body" here is the body as found in the posted article,
AFTER all transformations such as MIME encodings.
Reading agents SHOULD not rely on the presence of this
header, since it is optional (and some posting agents do not
supply it). They MUST not rely on it being precise, since
it frequently is not.
NOTE: The average line length in article bodies is
surprisingly consistent at about 40 characters,
and since the line count typically is used only
for approximate judgements ("is this too long to
read quickly?"), dividing the byte count of the
body by 40 gives an estimate of the body line
count that is adequate for normal use. This esti-
mate is NOT adequate if the body has been MIME
encoded... but neither is the Lines header, since
at least one major relayer will supply a Lines
header for an article that lacks one, and will not
consider the possibility of MIME encodings when
computing the line count.
NOTE: It would be better to have a Content-Size
header as part of MIME, so that body parts could
have their own sizes, and so that the units used
could be appropriate to the data type (line count
is not a useful measure of the size of an encoded
image, for example). Doing this is preferable to
trying to fix Lines.
UNRESOLVED ISSUE: Update on Content-Size?
Relayers SHOULD discard this header if they find it neces-
sary to re-encode the article in such a way that the origi-
nal Lines header would be rendered incorrect.
The Xref header content indicates where an article was filed
by the last relayer to process it:
Xref-content = relayer 1*( space location )
relayer = relayer-name
location = newsgroup-name ":" article-locator
article-locator = 1*<ASCII printable character>
The relayer's name is included so that software can deter-
mine which relayer generated the header (and specifically,
whether it really was the one that filed the copy being
examined). The locations specify what newsgroups the arti-
cle was filed under (which may differ from those in the
Newsgroups header) and where it was filed under them. The
exact form of an article locator is implementation-specific.
NOTE: Reading agents can exploit this information
to avoid presenting the same article to a reader
several times. The information is sometimes
available in system databases, but having it in
the article is convenient. Relayers traditionally
generate an Xref header only if the article is
cross-posted, but this is not mandatory, and there
is at least one new application ("mirroring":
keeping news databases on two hosts identical)
where the header is useful in all articles.
NOTE: The traditional form of an article locator
is a decimal number, with articles in each news-
group numbered consecutively starting from 1.
NNTP [rrr] demands that such a model be provided,
and there may be other software which expects it,
but it seems desirable to permit flexibility for
A relayer inserting an Xref header into an article MUST
delete any previous Xref header. A relayer which is not
inserting its own Xref header SHOULD delete any previous
Xref header. A relayer MAY delete the Xref header when
passing an article on to another relayer.
NOTE: RFC 1036 specified that the Xref header was
not transmitted when an article was passed to
another relayer, but the major news implementa-
tions have never obeyed this rule, and applica-
tions like mirroring depend on this disobedience.
A relayer MUST use the same name in Xref headers as it uses
in Path headers. Reading agents MUST ignore an Xref header
containing a relayer name that differs from the one that
begins the path list.
The Organization header content is a short phrase identify-
ing the poster's organization:
Organization-content = nonblank-text
This header is typically supplied by the posting agent. The
Organization content SHOULD mention geographical location
(e.g. city and country) when it is not obvious from the
NOTE: The motive here is that the organization is
often difficult to guess from the mailing address,
is not always supplied in a signature, and can
help identify the poster to the reader.
NOTE: There is no "s" in "Organization".
The Organization content is provided for identification
only, and does not imply that the poster speaks for the
organization or that the article represents organization
policy. Posting agents SHOULD permit the poster to override
a local default Organization header.
The Supersedes header content specifies articles to be can-
celled on arrival of this one:
Supersedes-content = message-id *( space message-id )
Supersedes is equivalent to Also-Control (section 6.15) with
an implicit verb of "cancel" (section 7.1).
NOTE: Supersedes is normally used where the arti-
cle is an updated version of the one(s) being can-
NOTE: Although the ability to use multiple message
IDs in Supersedes is highly desirable (see section
7.1), posters are warned that existing implementa-
tions often do not correctly handle more than one.
NOTE: There is no "c" in "Supersedes".
An article with a Supersedes header MUST not have an Also-
Control or Control header.
The Also-Control header content marks the article as being a
control message IN ADDITION to being a normal news article,
and specifies the desired actions:
Also-Control-content = Control-content
An article with an Also-Control header is filed and passed
on normally, but the content of the Also-Control header is
processed as if it were found in a Control header.
NOTE: It is sometimes desirable to piggyback con-
trol actions on a normal article, so that the
article will be filed normally but will also be
acted on as a control message. This header is
essentially a generalization of Supersedes.
NOTE: Be warned that some old relayers do not
An article with an Also-Control header MUST not have a Con-
trol or Supersedes header.
The See-Also header content lists message IDs of articles
that are related to this one but are not its precursors:
See-Also-content = message-id *( space message-id )
See-Also resembles References, but without the restrictions
imposed on References by the followup rules.
NOTE: See-Also provides a way to group related
articles, such as the parts of a single document
that had to be split across multiple articles due
to its size, or to cross-reference between paral-
NOTE: See the discussion (in section 6.5) on MAIL
compatibility issues of References and See-Also.
NOTE: In the specific case where it is desired to
essentially make another article PART of the cur-
rent one, e.g. for annotation of the other arti-
cle, MIME's "message/external-body" convention can
be used to do so without actual inclusion. "news-
message-ID" was registered as a standard external-
body access method, with a mandatory NAME parame-
ter giving the message ID and an optional SITE
parameter suggesting an NNTP site that might have
the article available (if it is not available
locally), by IANA 22 June 1993.
UNRESOLVED ISSUE: Could the syntax be generalized
to include URLs as alternatives to message IDs?
Here it makes much more sense than in References.
The Article-Names header content indicates any special sig-
nificance the article may have in particular newsgroups:
Article-Names-content = 1*( name-clause space )
name-clause = newsgroup-name ":" article-name
article-name = letter 1*( letter / digit / "-" )
Each name clause specifies a newsgroup (which SHOULD be
among those in the Newsgroups header) and an article name
local to that newsgroup. Article names MAY be used by
relayers to file the article in special ways, or they MAY
just be noted for possible special attention by reading
agents. Article names are case-sensitive.
NOTE: This header provides a way to mark special
postings, such as introductions, frequently-asked-
question lists, etc., so that reading agents have
a way of finding them automatically. The news-
group name is specified for each article name
because the names may be newsgroup-specific; for
example, many frequently-asked-question lists are
posted to "news.answers" in addition to their
"home" newsgroup, and they would not be known by
the same name(s) in both newsgroups.
The Article-Names header SHOULD be ignored unless the arti-
cle also contains an Approved header.
NOTE: This stipulation is made in anticipation of
the possibility that Approved headers will be
involved in cryptographic authentication.
The presence of an Article-Names header does not necessarily
imply that the article will be retained unusually long
before expiration, or that previous article(s) with similar
Article-Names headers will be cancelled by its arrival.
Posters preparing special postings SHOULD include appropri-
ate other headers, such as Expires and Supersedes, to
request such actions.
Different networks MAY establish different sets of article
names for the special postings they deem significant; it is
preferable for usage to be standardized within networks,
although it might be desirable for individual newsgroups to
have different naming conventions in some situations. Arti-
cle names MUST be 14 characters or less. The following
names are suggested but are not mandatory:
- Introduction to the newsgroup for newcomers.
- Charter, rules, organization, moderation poli-
- Biographies of special participants, history of
the newsgroup, notes on related newsgroups, etc.
- Descriptions of sub-newsgroups under this news-
group, e.g. "sci.space.news" under "sci.space".
- Information relating to the purpose of the news-
group, e.g. an acronym glossary in "sci.space".
- Where to get more information: books, journals,
FTP repositories, etc.
- Answers to frequently-asked questions.
- If present, a list of all the other article
names local to this newsgroup, with brief
descriptions of their contents.
Such articles may be divided into subsections using the MIME
"multipart/mixed" conventions. If size considerations make
it necessary to split such articles, names ending in a
hyphen and a part number are suggested; for example, a
three-part frequently-asked-questions list could have arti-
cle names "faq-1", "faq-2", and "faq-3".
NOTE: It is somewhat premature to attempt to stan-
dardize article names, since this is essentially a
new feature with no experience behind it. How-
ever, if reading agents are to attach special sig-
nificance to these names, some attempt at standard
conventions is imperative. This is a first
attempt at providing some.
The Article-Updates header content indicates what previous
articles this one is deemed (by the poster) to update (i.e.,
Article-Updates-content = message-id *( space message-id )
Each message ID identifies a previous article that this one
is deemed to update. This MUST not cause the previous arti-
cle(s) to be cancelled or otherwise altered, unless this is
implied by other headers (e.g. Supersedes); Article-Updates
is merely an advisory which MAY be noted for special atten-
tion by reading agents.
NOTE: This header provides a way to mark articles
which are only minor updates of previous ones,
containing no significant new information and not
worth reading if the previous ones have been read.
NOTE: If suitable conventions using MIME multipart
bodies and the "message/external-body" body-part
type can be developed, a replacing article might
contain only differences between the old text and
the new text, rather than a complete new copy.
This is the motivation for not making Article-
Updates also function as Supersedes does: the
replacing article might depend on the continued
presence of the replaced article.