From: Russ Allbery (rra@stanford.edu)
Date: Fri Feb 13 2004 - 11:53:00 CST
Charles Lindsey <chl@clerew.man.ac.uk> writes:
> Russ Allbery <rra@stanford.edu> writes:
>> Preserving existing Injection-Date headers for regular posting is
>> highly unwise for all the reasons that we're talking about moving away
>> from using the Date header.
> Eh? We are going around in circles.
> 1. I initially proposed that the Injection-Date should normally be
> rewritten by the injector if there was one already present on arrival.
> 2. I was roundly told by yourself and John Moreno that this was wrong,
> would lead to loops, and it was essential to keep the old Injection-Date
> in all circumstances.
In all circumstances where the article is accepted. The best thing to do
when a posting agent includes an Injection-Date header is to simply reject
the message.
> 5. Now you are asking me to go back to position #1,
No.
> and injectors are somehow supposed to detect and deal with articles that
> come from "unusual gateways", or we are to rely on the "unusual
> gateways" to know what they are dpoing and to do it right, which seems
> risky to me.
Multiple injection is inherently risky and should be avoided wherever
possible. People doing it need to know what they're doing.
>> In off-line news reading situations where the person is running their
>> own local news server, the Injection-Date may be significantly stale.
>> Likewise for the workaround situations such as the one that John
>> Stanley described. In those situations, I think the onus is on the
>> agent doing unusual reinjection to strip the erroneous Injection-Date
>> before reinjecting the message (an operation that should require manual
>> configuration and therefore for someone to know what they're doing).
> I think it would be much safer to put the onus on the man with the news
> server on his laptop to remove the stale Injection-Date manually - since
> it is only his article that will suffer if he fails to do so.
That's exactly what I just said.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>