Re: Circumventions
A.R. & F.L. Scott-Thoennes (sthoenna@peak.org)
Thu, 28 Nov 1996 23:13:57 -0800
In article <jfIny4uYONMT089yn@stack.nl>,
galactus@stack.nl (Arnoud "Galactus" Engelfriet) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In article <199611270454.XAA03946@muselab-gw.runet.edu>,
>Dennis McClain-Furmanski <dmcclain@runet.edu> wrote:
>>I moderate a group, and I'd like to be able to see all the messages,
>>especially those with diddled headers. Is there any way to prevent YARN
>>from discarding messages with missing/bad message ID?
>
>News articles *MUST* have a message ID. You simply cannot get
>an article from a news server which doesn't have a message ID on it.[0]
>
>The problem occurs when you get an article with VERY long lines,
>so long that they are truncated or overflow some buffer, so Yarn
>or uqwk thinks the headers end somewhere where they actually didn't.
>The message-ID header then isn't seen, because Yarn thinks it is
>just some text from the body. Another reason is when you filter
>mail messages (which are not required to have a message-ID[1], and
>not always do) to a newsgroup.
>
>I'm not sure what the problem is, though. A moderated newsgroup requires
>that people send you mail to get their articles posted. Then you
>should have read all articles in your mailbox already?
>
>> Similarly, I've
>>noticed that some replies get rejected at upload due to "references too
>>long". If I knew that at the time, I could have trimmed them. Is there a
>>way to make YARN notify you when the references are reaching a particular
>>limit, and maybe clip them off except for the last few? I don;t imagine
>>they need more than a few to keep them threaded.
>
>The last part of section 2.2.5 of RFC 1036 states that
>
> It is permissible to not include the entire previous "References"
> line if it is too long. An attempt should be made to include a
> reasonable number of backwards references.
>
>but it doesn't define 'reasonable' or 'too long'. I think all news
>servers can handle 10 referenced message-IDs, so this would be
>a good (and simple) thing to implement.
>
>Galactus
>[0] RFC 1036, section 2.1 "Required fields" lists Message-ID in
>section 2.1.5.
>[1] RFC 822, section 4.1 lists Message-ID in the "optional-field"
>category.
FWIW, Son-of-1036 (the primitive draft of a proposed successor to RFC 1036)
suggests the following rules for deleting message-IDs:
<begin quote>
Followup agents SHOULD not shorten References headers. If
it is absolutely necessary to shorten the header, as a des-
perate last resort, a followup agent MAY do this by deleting
some of the message IDs. However, it MUST not delete the
first message ID, the last three message IDs (including that
of the immediate precursor), or any message ID mentioned in
the body of the followup. If it is possible for the fol-
lowup agent to determine the Subject content of the articles
identified in the References header, it MUST not delete the
message ID of any article where the Subject content changed
(other than by prepending of a back reference).
<snip>
NOTE: The first message ID is very important as
the starting point of the "thread" of discussion,
and absolutely should not be deleted. Keeping the
last three message IDs gives thread-following
software a fighting chance to reconstruct a full
thread even if an article or two is missing.
Keeping message IDs mentioned in the body is obvi-
ously desirable.
<end quote>
It also suggests that message IDs for a followup where the subject changes
have a local part that ends with _-_ (e.g. <jfIny4uYONMT089yn_-_@stack.nl>)
and that any message ID with this pattern also never be removed, but no
newsreaders (AFAIK anyway) do this.