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

[Russ Allbery <rra@xxxxxxxxxxxx>]

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.

The current draft doesn't define a "reinjecting agent" exactly, but such
an agent would be a gateway and posting agent, *not* any sort of injecting
agent.

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

> We are concerned with an article that is being reinjected. Let us refer
> to its two incarnartions as FIRST and SECOND and the person/entity doing
> the reinjection as the REINJECTOR. For this option to be safe, it is
> ESSENTIAL that FIRST and SECOND were injected into totally disjoint
> networks, with absolutely no possibility of leaks between them, and it
> is the absolute responsibility of the REINJECTOR to ensure that this
> condition is met.

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

Observe that even in this situation, the problem can only happen once per
article.  In other words, the worse case scenario is for a host to see the
same article twice and twice only.  At that point, the requirements of a
gateway cut off further reinjection of the same article.

> But the real problems arise when FIRST is injected in a small private
> network (even a private news server maintained by an individual poster).
> Although it is argued that such a network should be regarded as
> gatewaying into the network where SECOND is to be propagated, it is far
> from certain that the owner of such a network or such an individual
> poster will regard himself as a "gatewayer", or that he will believe
> that section 3.9 applies in any way to him. 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).

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

This is exactly the sort of problem that caused us to add Injection-Date
in the first place.  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.

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

Extending the staleness cutoff is *not* safe unless it's done at least
that length of time after increasing the expiration time on the history
file so that the history file really does contain that many days of
history.

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.  Please also remember that you cannot assume that the
person running the gateway and the person running its first upstream
relaying agent are the same person or that the latter cares about the
concerns of the former.

-- 
Russ Allbery (rra@xxxxxxxxxxxx)             <http://www.eyrie.org/~eagle/>