From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Fri Apr 16 2004 - 17:52:53 CDT
Here are the changes to the draft to incorporate the Injection-Date
header. In addition to what is shown here, all occurrences of
"Injector-Info" are changed to "Injection-Info", and there are a few other
consequential changes.
Comments?
3.1. Principal Changes
| o There is a new mandatory Injection-Date-header to facilitate the
| rejection of stale articles.
| o There are several new optional headers defined, notably Archive,
Complaints-To, Injection-Info, Mail-Copies-To, Posted-And-Mailed
and User-Agent, leading to increased functionality.
3.2. Transitional Arrangements
| o Provision is made for relaying and serving agents to use the
| Date-header in the case of articles injected through existing
| agents which do not provide an Injection-Date-header.
5.1. Date
The Date-header contains the date and time that the article was
prepared by the poster ready for transmission and SHOULD express the
poster's local time. The content syntax makes use of syntax defined
in [RFC 2822] (but see the revised definition of zone in section
2.4.3).
header =/ Date-header
Date-header = "Date" ":" SP Date-content
Date-content = date-time
The date-time MUST be semantically valid as required by [RFC 2822].
Although folding white space is permitted throughout the date-time
syntax, it is RECOMMENDED that a single space be used in each place
that FWS appears (whether it is required or optional).
| The date-time MUST NOT be more than 24 hours into the future
| (injecting agents will reject such articles, possibly even when the
| margin is less than 24 hours - see 8.2.2) and it SHOULD NOT be
| inordinately far into the past. Relaying agents MUST NOT modify the
| Date-header in transit.
[Do you want me to be more specific about that "inordinately"?]
5.7. Injection-Date
| The Injection-Date-header contains the date and time that the article
| was injected into the network (or more precisely, the time at which
| the injecting agent first offered it to a relaying agent, which might
| be some time later than when the injecting agent first began to
| process it). Its purpose is to prevent the reinjection into the news
| stream of "stale" articles which have already expired by the time
| they arrive at some relaying or serving agent.
|
| header =/ Injection-Date-header
| Injection-Date-header
| = "Injection-Date" ":" SP Injection-Date-content
| *( ";" extension-parameter )
| Injection-Date-content
| = date-time
|
| See the remarks under the Date-header (5.1) regarding the syntax of a
| date-time and the requirements and recommendations to which it is
| subject.
|
| An Injection-Date-header MUST NOT be added to an article except by an
| injecting agent, hence it will never be present in a proto-article
| (8.2.1). It MUST be added by each injecting agent but, once added,
| it MUST NOT subsequently be changed or removed by any other agent,
| even during reinjection (8.2.2).
|
| NOTE: The date-time would normally be expected to be later than
| the date-time in the Date-header, but differences between the
| clocks on the various agents and other special circumstances
| might vitiate that; no provision is made for any such
| discrepancy to be corrected - better that the injecting agent
| should just insert the correct time as it sees it.
|
| Since this header is newly introduced in this standard, other
| agents cannot rely on its always being present; therefore,
| provision is made (8.3,8.4) for the Date-header to be used when
| it is absent.
|
| This header is intended to replace the currently-used but nowhere-
| documented header "NNTP-Posting-Date", whose use is now deprecated.
6.19. Injection-Info
| An Injection-Info-header MUST NOT be added to an article except by an
injecting agent. Any Injection-Info-header present when an article
| arrives at an injecting agent MUST be removed. In particular if, for
| some exceptional reason, an article is being reinjected (8.2.2), the
| Injection-Info-header will always relate to the latest injection (to
| the extent that this happens, the Injection-Info-header can be
| regarded as a variant header).
8.2. Duties of an Injecting Agent
An Injecting Agent is responsible for taking a proto-article from a
posting agent and either forwarding it to a moderator or injecting it
into the relaying system for access by readers.
As such, an injecting agent is considered responsible for ensuring
that any article it injects conforms with the rules of this standard.
It is also expected to bear some responsibility towards the rest of
the network for the behaviour of its posters (and provision is
therefore made for it to be easily contactable by email).
In the normal course of events, an article that has already been
| injected into a Netnews network will never pass through another
| injecting agent. So, if an injecting agent receives an otherwise
| valid article that has already been injected (as evidenced by the
| presence of an Injection-Date-header, an Injection-Info-header, or
| more thath one '%' path-delimiter in a Path-header) it MAY choose to
| reject it, but otherwise SHOULD cause it to be relayed, as it stands,
| by a relaying agent (8.3).
|
| Exceptionally, there may be good reasons to "reinject" an already
| injected article. This standard does not prescribe any circumstances
| in which such reinjection is to be considered legitimate (though some
| possible examples are given below); rather this is a matter of policy
| to be determined by the administrators of each injecting agent, who
| have the responsibility to ensure that only articles consistent with
| their policies are allowed to be reinjected. Nevertheless, in order
| to preserve the integrity of the network, this standard does set out
| the proper way to reinject.
|
| NOTE: Examples of some situations in which the policy of an
| injecting agent might permit reinjection to occur:
|
| o an article injected by another injecting agent which was
| temporarily unable to contact the relaying agent(s) with
| which it normally peered;
| o an attempt to relay by a site which only had permission to
| inject (whether due to some misunderstanding between the
| sites or as part of some backup relaying mechanism);
| o an article which had been gatewayed out of Netnews into
| some other medium, and then back again into the same, or a
| different, Netnews network.
8.2.1. Proto-articles
A proto-article is one that has been created by a posting agent and
has not yet been injected into a Netnews system by an injecting
agent. It SHOULD NOT be propagated in that form to other than
injecting agents. A proto-article has the same format as a normal
article except that some of the following mandatory headers MAY be
omitted: Message-Id-header, Date-header, Path-header (and even
From-header if the particular injecting agent can derive that
information from other sources). These headers MUST NOT contain
invalid values; they MUST either be correct or not present at all.
| NOTE: An article that is offered for reinjection has, by
| definition, already been injected once, and is not therefore to
| be considered as a proto-article. Hence a genuine proto-article
| will not contain any Injection-Date-header nor any '%' path-
| delimiter in its Path-header. It MAY contain path-identities
with other path-delimiters in the pre-injection portion of its
Path-header (5.6.3).
8.2.2. Procedure to be followed by Injecting Agents
An injecting agent receives proto-articles from posting and followup
agents. It verifies them, adds headers where required, and then
either forwards them to a moderator or injects them by passing them
to serving or relaying agents.
| Exceptionally, it MAY reinject an article, perhaps as a part of some
| complex gatewaying process (in which case it will add a further '%'
path-delimiter to the Path-header). It MUST NOT forward an already
injected article to a moderator.
An injecting agent processes articles as follows:
1. It MUST remove any Injection-Info- or Complaints-To-header already
present (though it might be useful to copy them to suitable X-
headers). It SHOULD likewise remove any NNTP-Posting-Host or other
undocumented tracing header.
2. It SHOULD verify that the article is from a trusted source.
However, it MAY allow articles in which headers contain unverified
email addresses, that is, addresses which are not known to be
valid for trusted source, and notably so if they end in
".invalid".
| 3. It SHOULD reject any article whose Date-header (5.1) is more than
| 24 hours into the future (and MAY use a margin less than that 24
| hours). It MUST, except when reinjecting, reject any article with
| an Injection-Date-header already present (and SHOULD do likewise
| with any NNTP-Posting-Date-header). It MAY when reinjecting, but
| only if there is no Injection-Date-header present, reject any
| article whose Date-header appears to be stale (e.g. more than 72
| hours into the past).
| 4. It MUST reject any article that does not have the correct
| mandatory headers for a proto-article (or, when reinjecting, all
| the mandatory headers other than Injection-Date), or which
contains any header that does not have legal contents. It SHOULD
reject any article which contains any header deprecated for
Netnews (4.2.1).
5. If the article is rejected (for reasons given above, or for other
formatting errors or matters of site policy) the posting agent
SHOULD be informed (such as via an NNTP 44x response code) that
posting has failed and the article MUST NOT then be processed
further.
6. The Message-ID, Date and From-headers (and their contents) MUST be
| added when not already present (but that situation could not arise
| during reinjection).
7. A Path-header with a tail-entry (5.6.3) MUST be correctly added if
not already present (except that it SHOULD NOT be added if the
| article is to be forwarded to a moderator). During reinjection,
| the existing Path-header SHOULD be retained.
8. The path-identity of the injecting agent with a '%' path-delimiter
(5.6.2) MUST be prepended to the Path-header; moreover, that
path-identity MUST be an FQDN mailable address (5.6.2).
9. An Injection-Info-header (6.19) SHOULD be added, identifying the
trusted source of the article, and a suitable Complaints-To-header
(6.20) MAY be added (except that these two headers MUST NOT be
added if the article is to be forwarded to a moderator).
10.The injecting agent MUST NOT alter the body of the article in any
| way. It MAY, except when reinjecting, add other headers not
| already provided by the poster, but SHOULD NOT alter, delete, or
reorder any existing header, with the specific exception of
"tracing" headers such as Injection-Info and Complaints-To, which
are to be removed as already mentioned.
11.If the Newsgroups-header contains no moderated groups, or if it
| contains an Approved-header, the injecting agent MUST then add an
| Injection-Date-header (5.7) if one is not already present, but it
| MUST NOT alter, or remove, an already present Injection-Date-
| header (and likewise SHOULD NOT alter, or remove, an already
| present NNTP-Posting-Date-header). Finally, it forwards the
article to one or more relaying or serving agents.
12.Otherwise, when the Newsgroups-header contains one or more
moderated groups and the article does NOT contain an Approved-
header, the injecting agent MUST forward it to the moderator of
the first (leftmost) moderated group listed in the Newsgroups-
header via email. There are two possibilities for doing this:
(a) The complete article is encapsulated (headers and all) within
the email, preferably using the Content-Type
"application/news-transmission" (6.21.4.1) with any usage
parameter set to "moderate". Moreover, there SHOULD NOT be
more than one encapsulated article within the one email.
This method has the advantage of removing any possible
conflict between Netnews and Email headers, or of changes to
those headers during transport through email.
(b) The article is sent as an email as it stands, with the
addition of such extra headers (e.g. a To-header) as are
necessary for an email.
Although both of these methods have seen use in the past, the
preponderance of current usage on Usenet has been for method (b)
and many moderators are ill-prepared to deal with method (a).
Therefore, method (a) SHOULD NOT be used until such time as the
majority of moderators are able to accept it.
13.This standard does not prescribe how the email address of the
moderator is to be determined, that being a matter of policy to be
arranged by the agency responsible for the oversight of each
hierarchy. Nevertheless, there do exist various agents worldwide
which provide the service of forwarding to moderators, and the
address to use with them is obtained as follows:
(a) Each '.' in the newsgroup-name is replaced with a '-'.
(b) The result of these operations is used as the local-part of
the mailbox of the agent. For example, articles intended for
"news.announce.important" would be emailed to "news-
announce-important@forwardingagent.example".
8.3. Duties of a Relaying Agent
A relaying agent processes articles as follows:
| 2. It MUST examine the Injection-Date-header (or, if that is absent,
| the Date-header) and reject the article as stale (5.7) if that
| predates the earliest articles of which it normally keeps record,
| or if it is more than 24 hours into the future (the margin MAY be
| less than that 24 hours).
8.4. Duties of a Serving Agent
A serving agent processes articles as follows:
| 2. It MUST examine the Injection-Date-header (or, if that is absent,
| the Date-header) and reject the article as stale (5.7) if that
| predates the earliest articles of which it normally keeps record,
| or if it is more than 24 hours into the future (the margin MAY be
| less than that 24 hours).
8.5. Duties of a Posting Agent
A Posting Agent is used to assist the poster in creating a valid
proto-article and forwarding it to an injecting agent.
Postings agents SHOULD ensure that proto-articles they create are
valid news articles according to this standard and other applicable
| policies. In particular, they MUST NOT create any Injection-Date-,
| Injection-Info- or Complaints-To-header.
Posting agents meant for use by ordinary posters SHOULD reject any
attempt to post an article which cancels or Supersedes another
article of which the poster is not the author.
8.7. Duties of a Moderator
A moderator processes an article, as submitted to any newsgroup that
he moderates, as follows:
| 4. The Date-header SHOULD be retained. Any Injection-Date-header
| already present (though there should be none) MUST be removed.
| Exceptionally, if it is known that the injecting agent does not
| yet support the Injection-Date-header and the Date-header appears
| to be stale (5.7) for reasons understood by the moderator (e.g.
| delays in the moderation process) he MAY substitute the current
| date. The Message-ID-header SHOULD also be retained unless it is
obviously non-compliant with this standard.
NOTE: A message identifier created by a conforming posting or
injecting agent, or even by a mail user agent conforming to [RFC
2822], may reasonably be supposed to be conformant (and will, in
any case, be caught by the injecting agent if it is not).
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5