Re: #1416: USEPRO 3.9: Reinjection and Injection-Date (was: Re: ISSUE: Reinjection and Injection-Date)

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <87sle760yi.fsf@xxxxxxxxxxxxxxxxxxxxx> Russ Allbery <rra@xxxxxxxxxxxx> writes:

>Charles Lindsey <chl@xxxxxxxxxxxxxxxx> writes:

>> There are essentially two options:

>> Option 1: Injection-Dates are ALWAYS rewritten by (re-)injecting agents.

>> Option 2: Injection-Date headers, once written, are NEVER altered.

>Just to try to be painfully clear here, Injection-Date using the method
>laid out in the current USEPRO draft is *not* rewritten by injecting
>agents.  The whole point of that option is that only the gateways who are
>doing the reinjection make this transformation.

Indeed, whether it is the injecting agent that rewrites the header, or
whether it simply creates a new header because the
poster/gayewayer/reinjector had removed the old one, makes little
difference, since the observed effect is the same.


>> Option 1: Injection-Dates are ALWAYS rewritten by (re-)injecting agents.

>> We are concerned with an article that is being reinjected. ...

>Lack of safety can only occur if the networks are not disjoint *and* there
>is a delay in gatewaying longer than the history retention of whatever
>path causes the networks to not be disjoint (whether a relaying agent or
>another gateway) but shorter than the staleness check in the reinjecting
>gateway (*and* no staleness checks are applied to the Date header field,
>but we can all agree on that as a long-term goal).

Agreed, which is why you need something rather odd, like the Anytown
Squash Club, that creates a longish delay for things to go wrong. And to
cause an actual loop you need two separate longish delays somewhere
(though that is not impossible, just requires something odder than that
Squash Club).


>> But the real problems arise when FIRST is injected in a small private
>> network (even a private news server maintained by an individual poster).
>> .... Such small private neworks
>> are notorious for "leaking" (and it is not necessarily the "owner" of
>> the network who will be the REINJECTOR that perpetrates the leak).

>Note that *relaying* leaks from such private networks are quite rare
>(although not non-existent).  Leaks are almost always via reinjection
>(suck/rpost feeds).

And usually caused by someone far removed from the first injector, so the
two of them are unknown to each other, and neither of them believes he is
doing anything out of the ordinary. The problem, in essence, is that I do
not believe in this concept of "disjoint networks", since it is almost
impossible to prove that two networks are truly disjoint.

>> Option 2: Injection-Date headers, once written, are NEVER altered.

>> This clearly removes the risks inherent in Option 1. It is inherently
>> much safer, and it is 'fail-safe' in the sense that the only thing that
>> can go wrong is that an article whose propagation was genuinely delayed
>> at some point might fail to propagate beyond a relaying agent with a
>> short history file expiry. But better to lose a few articles than run
>> the risk of loops.

>As you note, this approach makes it impossible for a gateway that is down
>for longer than the retention period of its most immediate upstream
>relaying agent to ever go back and gate the articles that it missed during
>its period of downtime.

Right. And that is the problem we need to fix. It is only really fixable
if the gateway that is down can be Absolutely Sure that he is leak-proof
(e.g. he is a stand-alone server). In that case, it is perfectly
reasonable for him to rewrite the Injection-Date when he come back online,
or to remove it and let the injecting agent create a new one. The only
question is whether and how to write that into the draft as a "truly
exceptional" situation.

>This is exactly the sort of problem that caused us to add Injection-Date
>in the first place.

Yes, it is the man who carries his prepared article, or even a complete
private server, around on his laptop. But I still want the Date header to
reflect the time of composition, since that is what is clearly stated by
RFC 2822, which we are following in this regard (that was also part of the
reason to add Injection-Date).

> If this is acceptable, I move that we drop
>Injection-Date entirely and go back to the well-understood and
>already-implemented staleness checking on Date and make people who hold
>posts for a while work around this in their posting agent.  It would save
>a ton of complexity.

No, because whatever scenario we come up with that causes problems with
Injection-Date, you can write a similar scenarion that breaks with Date.

>> But since B wants the articles for its own use (not for relaying back
>> into Usenet), it is presumably a serving agent, in which case its expiry
>> time is likely to be more than a week, in which case the staleness check
>> is unlikely to be triggered. But even if that is not so, this is a case
>> where all B's admin needs to do is to temporarily increase the expiry
>> time of his history file. This is always safe; even if some site on his
>> local network tries to relay an article back into Usenet, it is still
>> protected by its _original_ Injection-Date.

>No, this is *unsafe* if that host is part of a Netnews network because it
>means that articles that the relaying agent had already accepted it may
>accept again because it now thinks that its staleness cutoff is longer
>than it really was and will therefore think that articles that it had
>expired out of its history would be present in history had it already seen
>it.

Not so. This is not a relaying agent we are talking about (if a relaying
agent goes down for some length of time, then articles will still flood
around it, albeit perhaps more slowly).

We are talking about a serving agent that has been down for some period,
and has therefore received no articles during that time. Therefore, the
only articles that will get accepted twice are those that were in transit
at or around the time of the breakdown, such that there is some
uncertainty about exactly which articles were missed, and for safety it
might have asked for a few more than it actually needed (e.g. by a
slightly pessimistic date-time in a NEWNEWS).

And it is only his direct clients who will see those few messages again.
If, having accepted articles that he has already seen before, he then
tries to relay them out to the rest of Usenet, they will still be
protected by their original Injection-Date. So any damage/inconvenience
will be restricted to himself and his immediate clients. That seems a
reasonable price to pay after such a major disruption.


>Please remember that one of the very common cases of suck/rpost feeds is
>*from* a standalone server *to* Usenet, so assuming that the destination
>of such reinjected articles is always a private stand-alone server is
>clearly incorrect.

Eh? The cases I am concerned about are when the destination of some
articles is the wider Usenet (and possibly via several routes, and
possibly unintentionally so). So I am not at all assuming or concerned
with articles sent to a stand-alone server. So could you please explain
your point there more clearly?

-- 
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