[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Niggles in usepro-draft-11
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: chl@xxxxxxxxxxxxxxxx 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