usefor-usepro-02 December 2004

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

   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.  The possibility for reading agents to filter
        distributions has been provided (7.7) 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-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 SHOULD reject any article that does not include all the
      mandatory headers (section a-5).

   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.

   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 (2.3.2).  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-01/Duties_of_a_Relaying_Agent.out          September 2004
+++ ../usefor-usepro-02/Duties_of_a_Relaying_Agent.out          December 2004
@@ -12,7 +12,12 @@
    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?]
+
+   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
@@ -36,12 +41,9 @@
         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.]
+   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:
 
@@ -70,25 +72,33 @@
       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.
+   3. It SHOULD reject any article that does not include all the
+      mandatory headers (section a-5).
 
-   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.]
+   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.
+
    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
@@ -108,7 +118,7 @@
    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
+   article expect for headers designated as variant (2.3.2).  In
    particular
 
      o they MUST NOT create or augment a User-Agent-header in order to