Re: [1586] Multiple POSTED in Path: header

"Charles Lindsey" <[email protected]> writes:

> 3.4.1 of the present draft contains:
>
> 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 SHOULD 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.
>
> That "SHOULD NOT" was formerly "MUST NOT", so it is an improvement.
>
> But I propose changing it to:
>
> .. the Path header field MAY contain a "POSTED" <diag-keyword>; ...

Since that is equivalent to saying nothing about the POSTED
<diag-keyword>, were we to decide on this change, I think I would omit the
sentence entirely and just add the note (with corresponding minor wording
changes).  Or even better, move the NOTE to a subsection of 3.2 that
explains the meaning of a POSTED keyword and the circumstances under which
a Path header could be constructed containing several of them.

> and adding a NOTE such as the following:
>
>    NOTE: Whereas the presence of two "POSTED" <diag-keyword>s will often
>    indicate a malicious attempt to disguise the true origin of an article,
>    it could also arise following some ususual gatewaying or injecting
>    scenario (taking advantage of the "MAY contain" above), in which case
>    it could be useful for detecting unintended loops or mismanaged
>    gateways. The whole intent of these <path-diagnostic)s is to assist
>    humans in assessing unusual situations, and it would be unwise for
>    subsequent agents automatically to assume one possibility or the other.
>
> Essentially, I am arguing for not throwing away any information which might
> be of subsequent diagnostic use, possibly at the expense of making people
> think a bit before accusing posters of trollery. It is up to the "netkops"
> to deal with these issues, and our draft should not try to prejudge their
> efforts.

The corresponding text in 3.4.2 is:

   In some cases, offering the same proto-article to all injecting
   agents may not be possible (such as when gatewaying, after injection,
   articles found on one Netnews network to another supposedly-
   unconnected one).  In this case, the posting agent MUST remove any
   Xref header field and rename or remove any Injection-Info, Path, and
   other trace header field before passing it to another injecting
   agent.  (This converts the article back into a proto-article.)

Since multiple injection is the only means by which multiple POSTED
<diag-keywords> can arise with their intended meaning and purpose, it
seems pointless to relax the requirement too far in one area and not in
the other.

I think our options here are:

1. Treat the Path header as special and permit (or even encourage)
   retaining it while not permitting retention of the other trace headers,
   on the grounds that it has an intrinsic ordering and therefore isn't as
   prone to confusion as having multiple trace headers that aren't
   ordered.

2. Leave the existing wording, which requires multiple injection to remove
   or rename the Path header but allows readers to add spurious POSTED
   <diag-keyword>s by violating a SHOULD.  I'm not entirely comfortable
   with it, but I can't think of any specific protocol harm it could
   cause.

3. Restore the MUST in the proto-article section to match the MUST in
   3.4.2 and make the document consistent but possibly too strict.

4. Relax the MUST generally in 3.4.2, but then we will run into issues
   with Injection-Info, which the posting agent is not permitted to supply
   and which doesn't have an intrinsic ordering the way that the Path
   header does.

The more I think about it, the more option 1 seems like a workable idea,
but I think that's reversing some decisions that we made some time back.
That makes me nervous at this stage of the process.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>