From: J. B. Moreno (planb@newsreaders.com)
Date: Fri Feb 06 2004 - 22:17:37 CST
Charles Lindsey at <chl@clerew.man.ac.uk> wrote:
> In <BC473F44.C717%planb@newsreaders.com> "J.B.Moreno" <planb@newsreaders.com>
> writes:
>
>> On 2/4/04 8:43 AM, Charles Lindsey at <chl@clerew.man.ac.uk> wrote:
>
>>> No, I don't think it is as simple as that. We need to analyze the reasons
>>> why double injection occurs.[...]
>
>> [...] fundamentally [the reason is] irrelevant -- the problem is accepting
>> stale messages. The only way to see how fresh an article is is to have a
>> header that contains a timestamp, replacing that timestamp with a newer one,
>> for whatever reason, can result in double injection.
>
>
> Hmmmmm! Maybe. That is certainly the safest option, insofar as it will
> never go _wrong_. But that does not ensure that it always goes _right_.
> Some otherwise safe articles are going to get lost / dropped / rejected /
> poorly propagated.
There's no way to do both.
> My concern was the man with the broken posting agent which inserted an
> Injection-Date-header when it shouldn't.
The *only* benefit from introducing a new header IMO is that it will be
server generated ONLY -- if you get rid of that then we should definitely
stick with Date. Posting agents MUST not be adding this header.
> Or maybe his machine really was the injector and he normally had it connected
> permanently to the internet and used IHAVE to his upstream. But now he is away
> from home. The article is on his laptop and he carries it around for a couple
> of days until he finds somewhere to plug it in (and that 'somewhere' does not
> accept his IHAVE and regards itself as the true injecting agent). Or maybe he
> is still at home, but his telephone line has been down for a couple of days.
>
> So it seems that we just have to say to him "Tough! Usenet is like that".
Yes. He could shop around for another server that had a longer/larger
history, but if the timestamp is present (and once there it should never be
moved or changed) and it predates the history of the accepting server, that
server should reject the article.