usefor-usepro-03 February 2005

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-name>s in its Newsgroups header and at least one of
   the <dist-name>s in its Distribution header, if any.  Exceptionally,
   ALL relaying agents are deemed willing to supply or accept the
   <dist-name> "world", and NO relaying agent should supply or accept
   the <dist-name> "local".

   However, if the particular implementation does not relay non-existent
   newsgroups, even when included in the Newsgroups header and implied
   (e.g. by some "wild card" notation) in the configuration tables, then
   the agent MUST examine all group control messages (6.2) in order to
   ensure that relaying of those messages proceeds normally.

        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.  A similar possibility for reading agents to filter
        distributions is also suggested in [USEAGE]) for the same
        reason.

   In order to avoid unnecessary relaying, an article SHOULD NOT be
   relayed if the <path-identity> of the receiving agent (or some known
   alias thereof) appears in its Path header.

   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 header's content. If it matches it MUST then prepend its own
      <path-identity> and a '/' <path-delimiter> to that 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 that 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-delimiter>s.


[All subject to unresolved issues concerning the Path header.]

        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 (F-3.1.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 SHOULD reject any article that does not include all the
      mandatory headers (section F-3.1).

   4. It MAY reject any article whose headers do not have legal
      contents.

   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).

        NOTE: Even though commonly derived from the domain name of the
        originating site (and domain names are case-insensitive), a
        message identifier MUST NOT be altered in any way during
        transport, or when copied (as into a References header), and
        thus a simple (case-sensitive) comparison of octets will always
        suffice to recognize that same message identifier wherever it
        subsequently reappears.

        NOTE: These requirements are to be contrasted with those of the
        un-normalized msg-ids defined by [RFC 2822], which may perfectly
        legitimately become normalized (or vice versa) during transport
        or copying in email systems.

        NOTE: Some old software may treat message identifiers that
        differ only in case within their <id-right> part as equivalent,
        and implementors of agents that generate message identifiers
        should be aware of this.

   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 except for headers designated as variant (2.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.

--- ../usefor-usepro-02/Duties_of_a_Relaying_Agent.out          December 2004
+++ ../usefor-usepro-03/Duties_of_a_Relaying_Agent.out          February 2005
@@ -5,16 +5,18 @@
    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,
+   of the <newsgroup-name>s in its Newsgroups header and at least one of
+   the <dist-name>s 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".
+   <dist-name> "world", and NO relaying agent should supply or accept
+   the <dist-name> "local".
 
    However, if the particular implementation does not relay non-existent
-   newsgroups, even when included in the Newsgroups-header and implied
+   newsgroups, even when included in the Newsgroups header and implied
    (e.g. by some "wild card" notation) in the configuration tables, then
    the agent MUST examine all group control messages (6.2) in order to
    ensure that relaying of those messages proceeds normally.
@@ -38,42 +40,46 @@
         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.
+        notice.  A similar possibility for reading agents to filter
+        distributions is also suggested in [USEAGE]) for the same
+        reason.
 
    In order to avoid unnecessary relaying, an article SHOULD NOT be
-   relayed if the path-identity of the receiving agent (or some known
-   alias thereof) appears in its Path-header.
+   relayed if the <path-identity> of the receiving agent (or some known
+   alias thereof) appears in its Path header.
 
    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.
+      article and compare it with the leftmost <path-identity> of the
+      Path header's content. If it matches it MUST then prepend its own
+      <path-identity> and a '/' <path-delimiter> to that 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 that 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-delimiter>s.
+
+
+[All subject to unresolved issues concerning the Path header.]
 
         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
+   2. It MUST examine the Injection-Date header (or, if that is absent,
+      the Date header) and reject the article as stale (F-3.1.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 SHOULD reject any article that does not include all the
-      mandatory headers (section a-5).
+      mandatory headers (section F-3.1).
 
    4. It MAY reject any article whose headers do not have legal
       contents.
@@ -85,7 +91,7 @@
         NOTE: Even though commonly derived from the domain name of the
         originating site (and domain names are case-insensitive), a
         message identifier MUST NOT be altered in any way during
-        transport, or when copied (as into a References-header), and
+        transport, or when copied (as into a References header), and
         thus a simple (case-sensitive) comparison of octets will always
         suffice to recognize that same message identifier wherever it
         subsequently reappears.
@@ -95,16 +101,21 @@
         legitimately become normalized (or vice versa) during transport
         or copying in email systems.
 
+        NOTE: Some old software may treat message identifiers that
+        differ only in case within their <id-right> part as equivalent,
+        and implementors of agents that generate message identifiers
+        should be aware of this.
+
    6. It SHOULD reject any article that matches an already received
-      cancel message (or an equivalent Supersedes-header) issued by its
+      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
+   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.
+   8. It MAY delete any Xref header that is present.
 
    9. Finally, it passes the articles on to neighbouring relaying and
       serving agents.
@@ -118,17 +129,17 @@
    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 (2.3.2).  In
+   article except for headers designated as variant (2.3).  In
    particular
 
-     o they MUST NOT create or augment a User-Agent-header in order to
+     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
+     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-
+       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 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]);