usefor-usepro-01 September 2004
[< Prev]
[TOC] [ Next >]
7.3. Duties of a Relaying Agent
A Relaying Agent accepts injected articles from injecting and other
relaying agents and passes them on to relaying or serving agents
according to mutually agreed policy. Relaying agents SHOULD accept
articles ONLY from trusted agents.
An article SHOULD NOT be relayed unless the sending agent has been
configured to supply and the receiving agent to receive at least one
of the newsgroup-names in its Newsgroups-header and at least one of
the distributions in its Distribution-header, if any. Exceptionally,
ALL relaying agents are deemed willing to supply or accept the
distribution "world", and NO relaying agent should supply or accept
the distribution "local".
[That SHOULD has been demoted from a MUST in draft-13. Any objections?]
NOTE: Although it would seem redundant to filter out unwanted
distributions at both ends of a relaying link (and it is clearly
more efficient to do so at the sending end), many sending sites
have been reluctant, historically speaking, to apply such
filters (except to ensure that distributions local to their own
site or cooperating subnet did not escape); moreover they tended
to configure their filters on an "all but those listed" basis,
so that new and hitherto unheard of distributions would not be
caught. Indeed many "hub" sites actually wanted to receive all
possible distributions so that they could feed on to their
clients in all possible geographical (or organizational)
regions.
Therefore, it is desirable to provide facilities for rejecting
unwanted distributions at the receiving end. Indeed, it may be
simpler to do so locally than to inform each sending site of
what is required, especially in the case of specialized
distributions (for example for control messages, such as cancels
from certain issuers) which might need to be added at short
notice. The possibility for reading agents to filter
distributions has been provided (7.7) for the same reason.
An article SHOULD NOT be relayed if the path-identity of the
receiving agent (or some known alias thereof) appears in its Path-
header, and the receiving agent MAY detect whether its own path-
identity is already present in the Path-content so as to avoid
further unnecessary relaying.
[See related remarks under serving agents.]
A relaying agent processes articles as follows:
1. It MUST establish the trusted identity of the source of the
article and compare it with the leftmost path-identity of the
Path-content. If it matches it MUST then prepend its own path-
identity and a '/' path-delimiter to the Path-content; this SHOULD
then be followed by CRLF and WSP if it would otherwise result in a
line longer than 79 characters. If it does not match then it
prepends instead two entries to the Path-content; firstly the true
established path-identity of the source followed by a '?' path-
delimiter, and then, to the left of that, its own path-identity
followed by a '/' path-delimiter as usual. This prepending of two
entries SHOULD NOT be done if the provided and established
identities match. See a-5.6.4 for the significance of the various
path-delimiters.
NOTE: In order to prevent overloading, relaying agents should
not routinely query an external entity (such as a DNS-server) in
order to verify an article (though a local cache of the required
information might usefully be consulted).
2. It MUST examine the Injection-Date-header (or, if that is absent,
the Date-header) and reject the article as stale (a-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).
3. It MUST reject any article that does not have the correct
mandatory headers (section a-5) present with legal contents.
4. It SHOULD reject any article whose optional headers (section a-6)
do not have legal contents.
[Is that too strong? Are relaying agents really expected to check
headers in that detail? I suggest s/SHOULD/MAY/. Even the MUST in Step 4
for mandatory headers might be demoted to SHOULD.]
5. It SHOULD reject any article that has already been sent to it (a
database of message identifiers of recent messages is usually kept
and matched against).
6. It SHOULD reject any article that matches an already received
cancel message (or an equivalent Supersedes-header) issued by its
poster or by some other trusted entity.
7. It MAY reject any article without an Approved-header posted to
newsgroups known to be moderated (this practice is strongly
recommended, but the information necessary to do so may not be
available to all agents).
8. It MAY delete any Xref-header that is present.
9. Finally, it passes the articles on to neighbouring relaying and
serving agents.
If the article is rejected as being invalid, unwanted or unacceptable
due to site policy, the agent that passed the article to the relaying
agent SHOULD be informed (such as via an NNTP 43x response code) that
relaying failed. In order to prevent a large number of error messages
being sent to one location, relaying agents MUST NOT inform any other
external entity that an article was not relayed UNLESS that external
entity has explicitly requested that it be informed of such errors.
Relaying agents MUST NOT alter, delete or rearrange any part of an
article expect for headers designated as variant (a-4.2.5.3). In
particular
o they MUST NOT create or augment a User-Agent-header in order to
identify themselves;
o they MUST NOT rewrite the Newsgroups-header in any way, even if
some supposedly non-existent newsgroup is included;
o they MUST NOT refold any header (i.e. they must pass on the
folding as received), even to remove FWS from a Newsgroups-
header;
o they MUST NOT alter the Date-header or the Injection-Date-header;
o they MUST NOT delete any unrecognized header whose header-name is
syntactically correct (whether or not it is registered with IANA
[RFC 3864]);
o they MUST NOT change the Content-Transfer-Encoding of the body or
any body part.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-usepro-00/Duties_of_a_Relaying_Agent.out August 2004
+++ ../usefor-usepro-01/Duties_of_a_Relaying_Agent.out September 2004
@@ -1,23 +1,63 @@
-7.4. Duties of a Relaying Agent
+7.3. Duties of a Relaying Agent
A Relaying Agent accepts injected articles from injecting and other
relaying agents and passes them on to relaying or serving agents
according to mutually agreed policy. Relaying agents SHOULD accept
articles ONLY from trusted agents.
+ An article SHOULD NOT be relayed unless the sending agent has been
+ configured to supply and the receiving agent to receive at least one
+ of the newsgroup-names in its Newsgroups-header and at least one of
+ the distributions in its Distribution-header, if any. Exceptionally,
+ ALL relaying agents are deemed willing to supply or accept the
+ distribution "world", and NO relaying agent should supply or accept
+ the distribution "local".
+[That SHOULD has been demoted from a MUST in draft-13. Any objections?]
+
+ NOTE: Although it would seem redundant to filter out unwanted
+ distributions at both ends of a relaying link (and it is clearly
+ more efficient to do so at the sending end), many sending sites
+ have been reluctant, historically speaking, to apply such
+ filters (except to ensure that distributions local to their own
+ site or cooperating subnet did not escape); moreover they tended
+ to configure their filters on an "all but those listed" basis,
+ so that new and hitherto unheard of distributions would not be
+ caught. Indeed many "hub" sites actually wanted to receive all
+ possible distributions so that they could feed on to their
+ clients in all possible geographical (or organizational)
+ regions.
+
+ Therefore, it is desirable to provide facilities for rejecting
+ unwanted distributions at the receiving end. Indeed, it may be
+ simpler to do so locally than to inform each sending site of
+ what is required, especially in the case of specialized
+ distributions (for example for control messages, such as cancels
+ from certain issuers) which might need to be added at short
+ notice. The possibility for reading agents to filter
+ distributions has been provided (7.7) for the same reason.
+
+ An article SHOULD NOT be relayed if the path-identity of the
+ receiving agent (or some known alias thereof) appears in its Path-
+ header, and the receiving agent MAY detect whether its own path-
+ identity is already present in the Path-content so as to avoid
+ further unnecessary relaying.
+[See related remarks under serving agents.]
+
A relaying agent processes articles as follows:
1. It MUST establish the trusted identity of the source of the
article and compare it with the leftmost path-identity of the
Path-content. If it matches it MUST then prepend its own path-
- identity and a '/' path-delimiter to the Path-header. If it does
- not match then it prepends instead two entries to the Path-
- content; firstly the true established path-identity of the source
- followed by a '?' path-delimiter, and then, to the left of that,
- its own path-identity followed by a '/' path-delimiter as usual.
- This prepending of two entries SHOULD NOT be done if the provided
- and established identities match. See a-5.6.4 for the
- significance of the various path-delimiters.
+ identity and a '/' path-delimiter to the Path-content; this SHOULD
+ then be followed by CRLF and WSP if it would otherwise result in a
+ line longer than 79 characters. If it does not match then it
+ prepends instead two entries to the Path-content; firstly the true
+ established path-identity of the source followed by a '?' path-
+ delimiter, and then, to the left of that, its own path-identity
+ followed by a '/' path-delimiter as usual. This prepending of two
+ entries SHOULD NOT be done if the provided and established
+ identities match. See a-5.6.4 for the significance of the various
+ path-delimiters.
NOTE: In order to prevent overloading, relaying agents should
not routinely query an external entity (such as a DNS-server) in
@@ -35,6 +75,9 @@
4. It SHOULD reject any article whose optional headers (section a-6)
do not have legal contents.
+[Is that too strong? Are relaying agents really expected to check
+headers in that detail? I suggest s/SHOULD/MAY/. Even the MUST in Step 4
+for mandatory headers might be demoted to SHOULD.]
5. It SHOULD reject any article that has already been sent to it (a
database of message identifiers of recent messages is usually kept
@@ -44,19 +87,17 @@
cancel message (or an equivalent Supersedes-header) issued by its
poster or by some other trusted entity.
+
+
7. It MAY reject any article without an Approved-header posted to
newsgroups known to be moderated (this practice is strongly
recommended, but the information necessary to do so may not be
available to all agents).
- 8. Finally, it passes articles which match mutually agreed criteria
- on to neighbouring relaying and serving agents. However, it SHOULD
- NOT forward articles to sites whose path-identity is already in
- the Path-header.
-
- NOTE: It is usual for relaying and serving agents to restrict
- the Newsgroups, Distributions, age and size of articles that
- they wish to receive.
+ 8. It MAY delete any Xref-header that is present.
+
+ 9. Finally, it passes the articles on to neighbouring relaying and
+ serving agents.
If the article is rejected as being invalid, unwanted or unacceptable
due to site policy, the agent that passed the article to the relaying
@@ -66,8 +107,21 @@
external entity that an article was not relayed UNLESS that external
entity has explicitly requested that it be informed of such errors.
-
-
Relaying agents MUST NOT alter, delete or rearrange any part of an
- article expect for headers designated as variant (a-4.2.5.3).
+ article expect for headers designated as variant (a-4.2.5.3). In
+ particular
+
+ o they MUST NOT create or augment a User-Agent-header in order to
+ identify themselves;
+ o they MUST NOT rewrite the Newsgroups-header in any way, even if
+ some supposedly non-existent newsgroup is included;
+ o they MUST NOT refold any header (i.e. they must pass on the
+ folding as received), even to remove FWS from a Newsgroups-
+ header;
+ o they MUST NOT alter the Date-header or the Injection-Date-header;
+ o they MUST NOT delete any unrecognized header whose header-name is
+ syntactically correct (whether or not it is registered with IANA
+ [RFC 3864]);
+ o they MUST NOT change the Content-Transfer-Encoding of the body or
+ any body part.