Subject: Niggles in usepro-draft-11

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Aug 2008 17:05:58 GMT

I have now had a chance to read through the whole document, and was
pleased to see that it is now in a pretty tidy state.

The following niggles are mostly of a grammatical nature, or are textual
clarifications intended to ensure that our intentions are correctly
understood. I think there is only one item that might conceivably turn
into an Issue, although there are also a couple of cases where there is a
problem but I am not sure how to fix it, hence further discussion is
required.

3.2.1.  Constructing the Path Header Field

   ........  Note that the Path header
   field content is constructed from right to left by prepending
   elements.

   1.  ........

   2.  ........

   3.  A relaying or serving agent SHOULD prepend a <path-diagnostic> to
       the Path header field content, where the <path-diagnostic> is
       chosen as follows:

       *  If the expected <path-identity> of the source of the article
          matches the leftmost <path-identity> of the Path header
          field's content, use "!" (<diag-match>), resulting in two
          consecutive "!"s.

       *  If the expected <path-identity> of the source of the article
          does not match, use "!.MISMATCH." followed by the expected
          <path-identity> of the source or its IP address.

       *  If the relaying or serving agent is not willing or able to
          check the <path-identity>, use "!.SEEN." followed by the FQDN,
          IP address, or expected <path-identity> of the source.

The term "expected <path-identity>" has been used three times there. but
has not been properly explained. I would suggest adding, at the end of
these steps:

   In the above, the "expected" <path-identity> refers to that
   appropriate to the apparent source of the article (e.g. as determined
   by the channel whence it arrived, its IP address, or some
   authentication provided during connection setup).

3.2.2.  Path Header Field Example

   Here is an example of a Path header field created following the rules
   for injecting and relaying agents.

          Path: foo.isp.example!.SEEN.isp.example!!foo-news
            !.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example
            !!old.site.example!barbaz!!baz.isp.example
            !.POSTED.dialup123.baz.isp.example!not-for-mail

   This article was injected by baz.isp.example as indicated ....

   The article was relayed to the relaying agent known, at least to
   old.site.example, as "barbaz".

   barbaz relayed it to old.site.example, which does not support <diag-
   keyword> and therefore used the old "!" delimiter.  This indicates
   that the identity of "barbaz" was not verified and may have been
   forged.

But then there is no explanation of why barbaz used that "!!" delimiter
(all the other funnies in the example _do_ get accounted for in further
on in the text). So I would suggest:

   barbaz, being satisfied that it had indeed been recceived from
   baz.isp.example, inserted a "!!" <path-delimiter>. It then relayed it
   to old.site.example .........

3.3.  Article History and Duplicate Suppression

   o  ............  If this
      interval is shorter than the time it takes for an article to
      propagate through the network, the agent might reject an article
      it had not yet seen, so it ought not be aggressively short. .....
                                          ^
                                          to

   These are just two implementation strategies for article history,
   albeit the most common ones.  Relaying and serving agents are not
   required to use these strategies, only to meet the requirement of not
   accepting an article more than once.  However, these strategies are
   safe and widely deployed and implementors are encouraged to use one
   of them, especially if they do not have extensive experience with
   Netnews and the subtle effects of its flood-fill algorithm.
               ^^^
           with the more

3.4.  Duties of a Posting Agent

   If the proto-article already contains both Message-ID and Date header
   fields, posting agents MAY add an Injection-Date header field to that
   proto-article immediately before passing that proto-article to an
   injection agent.  They SHOULD do so if the Date header field
   (representing the composition time of the proto-article) is more than
   a day in the past at the time of injection.  They MUST do so if the
   proto-article is being submitted to more than one injecting agent;
   see Section 3.4.2.

We are now allowing (sometimes even requiring) posting agents to insert
an Injection Date.  Whereas clueful multiple injectors will probably do
this correctly, I am worried that incompetent MUA implementors (or which
there are many :-( ) will do it wrongly.

On the other hand, now it seems to have been decided only to allow
injection agents to insert it in limited situations, it is desirable
that posting agents should be encouraged (somewhere between MAY and
SHOULD) to do it routinely (otherwise this new header will never catch
on). So I suggest:
   
   When the proto-article already contains both Message-ID and Date
   header fields, posting agents MAY, as part of the injection process
   (i.e. immediately before passing it to an injection agent), add an
   Injection-Date header field to that proto-article (a useful practice,
   since it provides diagnostic information and can imrove propagation).
   Moreover, they SHOULD do so if the Date header field (representing
   the composition time of the proto-article) is more than a day in the
   past at the time of injection. and they MUST do so if the
   proto-article is being submitted to more than one injecting agent;
   see Section 3.4.2.

3.4.1.  Proto-articles

   A proto-article has the same format as a normal article except that
   the Injection-Info and Xref header fields MUST NOT be present; the
   Path header field MUST NOT contain a "POSTED" <diag-keyword>; and any
   of the following mandatory header fields MAY be omitted: Message-ID,
   Date, and Path.  In all other respects, a proto-article MUST be a
   valid Netnews article.  In particular, the header fields which may be
   omitted MUST NOT be present with invalid content.

I am worried about that 'MUST NOT contain a "POSTED" <diag-keyword>'. It
would cause no interoperability problems and cause no significant harm,
and hence a "MUST" cannot be justified under RFC 2119. Nothing breaks if
two "POSTEDs appear in one Path. Indeed, it could arise legitimately in
multiple injection "after the fact", and in other exotic gatewaying
situations.

Yes, some s[pc]ammers will preload the Path so as to disguise the true
origin of an article (which is indeed why POSTED was invented), but that
is a matter to be taken up by the netkops rather than the protocols. And
I would prefer to preserve all evidence left over from previous Paths in
order to facilitate bebugging of broken gateways, etc.

So, at the most, it ought to be a SHOULD, and I would be happy to omit
it altogether. Note that whatever change is made here, corresponding
changes would be needed in 3.4.2 and 3.5.2 Step 2.

3.4.2.  Multiple Injection of Articles

   Under some circumstances (posting to multiple disjoint networks,
                                                ^
                                             supposedly
   injecting agents with spotty connectivity, or for redundancy, for
   example), ........

   Whenever possible, multiple injection SHOULD be done by offering the
   same proto-article to multiple injecting agents.  The posting agent
   MUST supply the Message-ID, Date, and Injection-Date header fields,
   and the proto-article as offered to each injecting agent MUST be
           ^^^^^^^^^^^^^
           proto-articles
   identical.

   In some cases, offering the same proto-article to all injecting
   agents may not be possible (such as when gatewaying, after the fact,
   articles found on one Netnews network to another, supposedly
   unconnected one).  In this case, the posting agent MUST convert the
   article back into a proto-article before passing it to another
   injecting agent, but it MUST retain unmodified the Message-ID, Date,
   and Injection-Date header fields.  It MUST NOT add an Injection-Date
   header field if it is missing from the existing article.  It MUST
   remove any Xref header field and either rename or remove any
   Injection-Info header field and other trace fields.

I don't like the term "after the fact" (it has no intuitive meaning),
and I don't think "converting back to a proto-article" is the best way
to describe what needs to be done (since it can still contain various
headers not present in the first-time-around proto-article). Here is an
alternative wording:

   In some cases, multiple injection arises (perhaps inadvertently) when
   gatewaying articles found on one Netnews network to another,
   supposedly unconnected one.  In this case, the (re-)posting agent
   MUST remove any Xref header field and either rename or remove any
   Injection-Info header field and other trace fields (thus converting
   the article back into a proto-article) before passing it to another
   injecting agent, but it MUST retain unmodified the Message-ID, Date,
   and Injection-Date header fields.  It MUST NOT add an Injection-Date
   header field if it is missing from the existing article.

Note that wording might need further revision, depending on what we
decide regarding allowing "POSTED" to appear twice in a Path. And the
words "after the fact" would need rewriting in the following NOTE.

      NOTE: Multiple injection inherently risks duplicating articles.
      Multiple injection after the fact, by converting an article back
      to a proto-article and injecting it again, additionally risks
      loops, loss of trace information, unintended repeat injection into
      the same network, and other problems.  It should be done with care
      and only when there is no alternative.  The requirement to retain
      Message-ID, Date, and Injection-Date header fields minimizes the
      possibility of a loop and ensures that the newly injected article
      is not treated as a new, separate article.

   Multiple injection of an article listing one or more moderated
   newsgroups in its Newsgroups header field SHOULD only be done by a
                                                    ^^^^
						    ONLY
   moderator and MUST only be done after the proto-article has been
                      ^^^^
		      ONLY
   approved for all moderated groups to which it is to be posted and has
   an Approved header field (see Section 3.9).  .....

I think that is well within the spirit of RFC 2119, and will be much
clearer.

3.4.4.  Construction of the References Header Field

   The content of the new article's References header field MUST be
   formed from the content of the parent's References header field if
   present and the content of the Message-ID header field of the parent.
           ^^^
        followed by
   If the parent had a References header, FWS as defined in [USEFOR]
   MUST be added between its content and the Message-ID header field
   content.

If we don't make that change, then it does not actually make it clear
whether the new reference is to be placed to the left, or to the right,
of the existing ones.

3.5.  Duties of an Injecting Agent

   11.  If the proto-article already had an Injection-Date header field,
        it MUST NOT be modified or replaced.  If the proto-article had
        both a Message-ID header field and a Date header field, an
        Injection-Date header field MUST NOT be added, since the proto-
        article may have been multiply injected by a posting agent that
        predates this standard.  Otherwise, the injecting agent MUST add
        an Injection-Date header field containing the current date and
        time.

Well, you know that I don't like the second sentence in that. Taking the
preferences into account, we were split exactly 50:50 on the issue
(which is a perfect un-consensus :-) ). But I accept that it is better
for the Chair to make an arbitrary choice in this situation (absent
some unforeseen new consenus, of course).

3.6.  Duties of a Relaying Agent

   5.  It SHOULD reject any article that matches an already-received
       cancel control message or the contents of the Supersedes header
       field of an accepted article, provided that the relaying agent
       chose (on the basis of local site policy) to honor that cancel
       ^^^^^
       has chosen
       control message or Supersedes header field.

5.1.  Authentication and Authorization

   Control messages specify actions above and beyond the normal
   processing of an article and are therefore potential vectors of abuse
   and unauthorized action.  There is, at present, no standardized means
   of authenticating the sender of a control message or verifying that
   the contents of a control message were sent by the claimed sender.
   There are, however, some unstandardized authentication mechanisms in
   common use.

   Agents acting on control messages SHOULD take steps to authenticate
   control messages before acting on them, as determined by local
   authorization policy.  Whether this is done via the use of an
   unstandardized authentication protocol, by comparison with
   information obtained through another protocol, by human review, or by
   some other means is left unspecified by this document.  Further
   extensions or revisions of this protocol are expected to standardize
   a digital signature mechanism.

   Agents are expected to have their own local authorization policies
   for which control messages will be honored.  No Netnews agent is ever
   required to act on any control message.  The following descriptions
   specify the actions that a control message requests, but an agent MAY
   always decline to act on any given control message.

5.2.3.  The checkgroups Control Message

   The body of the message is an entity of type application/
                             ^
       (or contains, as part of a multipart/mixed)
   news-checkgroups.  It SHOULD be declared as such with appropriate
   MIME headers, but news servers SHOULD interpret checkgroups messages
   that lack the appropriate MIME headers as if the body were of type
   application/news-checkgroups for backward compatibility.

Cf. wording in 5.2.1.

5.3.  The cancel Control Message

   The cancel control message requests that a target article be
   withdrawn from circulation and access.  The syntax of its Control
   header field is:

         control-command     =/ Cancel-command
         Cancel-command      = "cancel" Cancel-arguments
         Cancel-arguments    = 1*WSP msg-id

   The argument identifies the article to be cancelled by its message
   identifier.  The body of the control message MAY contain anything,
   usually an explanatory text.

   A serving agent that elects to honor a cancel message SHOULD make the
   article unavailable to reading agents (perhaps by deleting it
   completely).  If the cancel control message arrives before the
   article it targets, news servers choosing to honor it SHOULD remember
   the message identifier that was cancelled and reject the cancelled
   article when it arrives.

   To best ensure that it will be relayed to the same news servers as
   the original message, a cancel control message SHOULD have the same
   Newsgroups header field as the message it is cancelling.

   Cancel control messages listing moderated newsgroups in their
   Newsgroups header field MUST contain an Approved header field like
   any other article in a moderated newsgroup.  This means that cancels
   posted to a moderated newsgroup will normally be sent to the
   moderator first for approval.  Outside of moderated newsgroups,
   cancel messages are not required to contain an Approved header field.

   Contrary to [RFC1036], cancel control messages are not required to
   contain From and Sender header fields matching the target message.
   This requirement only encouraged cancel issuers to conceal their
   identity and provided no security.

5.4.  The Supersedes Header Field

   The presence of a Supersedes header field in an article requests that
   the message identifier given in that header field be withdrawn in
   exactly the same manner as if it were the target of a cancel control
   message.  Accordingly, news servers SHOULD use the same
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   authentication and authorization checks for deciding whether to honor
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   a Supersedes header field as they use for cancel control messages.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   If the Supersedes header field is honored, the news server SHOULD
   take the same actions as it would take when honoring a cancel control
   message for the given target article.

The bit I have marked with ^^^^^^^^ is all fine and dandy, except that
the preceding section 5.3 on Cancel Messages make no mention of
"authentication and authorization". I think the Cancel Message _should_
say something on the subject, but the question is What? (given that we
have nothing specific to offer). The old draft-06 contained the
following:

        NOTE: It is expected that the security extension envisaged in
        section 5.1 will make more detailed provisions for establishing
        whether honouring a particular "cancel" message is in order. In
        particular, it is likely that there will be provision for the
        digital signature of 3rd party cancels (i.e. those issued other
        than by the sender, the moderator, or the injector).

However, what is currently said in our section 5.1 is fine (so far as it
goes) for Group Control Messages, but has nothing to say of relevance to
Cancels and Supersedes. Moreover, we are hardly in a position now to
promise that a "Security Extension for Netnews" is in the offing,
desirable as such might be.

So what ought we to be saying as regards both Cancels and Supersedes? I
have quoted all the relevant texts above so that people can discuss
the possibilities.

And also, as regards Supersedes headers, we do not actually say that, in
addition to acting as a Cancel, they are also propagated and displayed
like an ordinary article. I therefore suggest the following additional
paragraph:

   The article containing the Supersedes header field is itself still
   intended to be made available to reading agents in the usual manner.

6.  Security Considerations

6.1.  Compromise of System Integrity

   Control messages pose a particular security concern since acting on
   unauthorized control messages may cause newsgroups to be removed,
   articles to be deleted, and unwanted newsgroups to be created.
   Administrators of news servers SHOULD therefore take steps to verify
   the authenticity of control messages as discussed in Section 5.1.
   Articles containing Supersedes header fields are effectively cancel
   control messages and SHOULD be subject to the same checks as
   discussed in Section 5.4.  Currently, many sites are ignoring all
   cancel control messages and Supersedes header fields due to the
   difficulty of authenticating them and their widespread abuse.

Agreed as far as Cancels, but does there in fact exist such "widespread
abuse" of Supersedes?

6.2.  Denial of Service

   Such articles intended to deny service, or other articles of an
   inflammatory nature, may also have their From or Reply-To addresses
   set to valid but incorrect email addresses, thus causing large
   volumes of email to descend on the true owners of those addresses.
                   ^
              ("mailbombs")
   Users and agents should always be aware that identifying information
   in articles may be forged.

Please add:

   The inclusion of a Disposition-Notification-To header field could
   also give rise to such mailbombs (hence its deprecation for Netnews
   in [RFC3798]).

Appendix A.  Changes to the Existing Protocols

   This document prescribes many changes, clarifications, and new
   features since the protocol described in [RFC1036].  Most notably:

   o  Addition of the new Injection-Date header field is required for
      injecting agents (Section 3.5) and MUST be used by news servers
      for date checks (Section 3.6).  Injecting agents are strongly
      encouraged to put all local trace information in the new
      Injection-Info header field.

Unless a sudden "unforeseen new consensus" happens, that first sentence
will need to be changed.

{Ah! I just spotted that Russ has fixed it in draft-12}

Authors' Addresses

   Charles H. Lindsey
   University of Manchester
   5 Clerewood Avenue
   Heald Green
   Cheadle
   Cheshire  SK8 3JU
   United Kingdom

I would suggest removing that "University of Manchester" line. I am long
retired from the University, and I would not like to people to think
that the address of the University was "5 Clerewood Avenue, Heald Green"
:-) .

-- 
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: [email-masked]      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