From: Bruce Lilly (blilly@erols.com)
Date: Wed Apr 14 2004 - 20:25:41 CDT
Charles Lindsey wrote:
> In <406CC294.5090302@erols.com> Bruce Lilly <blilly@erols.com> writes:
>> Neither the term nor reasons
>>why the process might legitimately take place are defined.
>
>
> It is going to happen, whether it is legitimate or not.
If it is not legitimate, then we should state so clearly. If there are
known instances where it happens regardless, we should be especially
clear that those cases are forbidden.
>>If the article has been injected, it should be relayed, not "reinject"ed.
>>If the laptop has separate injecting and relaying agents, and the article
>>has already been injected, the relaying agent has it and is expected to
>>relay it (not inject or reinject it). If it has a combined injection/relaying
>>agent and that agent has accepted the article with all of the necessary
>>checks associated with injection, but finds that it cannot relay the article,
>>it might be reasonable for that agent to convert the article back into a
>>proto-article (removing Injection-Date, Injector-Info, etc.) and inject that.
>
>
> NO! Removing Injection-Date is verboten. This laptop has a complete news
> server on it (quite a common setup). It may normally relay to several
> sites. Maybe it has already relayed to one (with the original
> Injection-Date) before it tried this unusual injection attempt. Maybe it
> is going to relay it again when it gets home.
If the article in question has been successfully relayed, and is refused
relaying by other sites, the server has finished it's job -- there is no
cause for "re-injection". If the article has never been successfully
relayed, there is no harm in presenting it again as a proto-article
for injection -- the alternative is that the article simply does not
propagate beyond the server in question, in which case the user may notice
that lack of propagation and manually resubmit his article, which will
have the same effect.
>>> . a relaying agent receiving an attelpted relay from a source with
>>> which it did not have a peering agreement might choose to reinject it
>>> instead, in order to fulfil its obligation to the rest of the network
>>> (8.2) to be responsible ...
>
>
>>According to 8.2, an injection agent is responsible "for the behaviour
>>of its posters"; in the case you describe, either the relaying agent is
>>unable to fulfill that obligation or it has no reason to reject the
>>relayed article. Either way, [re]injection is not warranted.
>
>
> No, we are talking about the case when an agent B is unwilling to accept
> relaying from A, but it is willing to accept injection from A (because
> allowing someone to peer with you requires a greater degree of trust in
> that someone than does allowing him to inject). So A tries to relay to B
> (and perhaps he also relays to another peer C that DOES so allow). A uses the
[...]
That is utter nonsense; if the article (N.B. not proto-article) cannot
be relayed (why on Earth is A trying to relay to B, when it is an established
fact that B does not accept relayed articles from A?) then that is the end
of the transaction between A and B regarding that article. There is again
no justification for "re-injection".
>>> . there might be a genuine misunderstanding between two sites as to
>>> whether the relationship between them was as peers for relaying, or as
>>> client/server for injecting.
>
>
>>How can that happen given the requirement in 8.2 (as above)? An injection
>>agent must know its clients quite well.
>
>
> Would that were true!
8.2 requires it to be so, as noted above.
> Usenet is full of dodgy sites, and even more dodgy
> clients. It happens all the time, and yet we want Usenet to be robust
The solution to that is "if Injection-Date, then reject on attempted
[re-]injection".
> And again, that cannot be enforced. Private networks leak. Sysadmins have
> spent years trying to plug leaks, and it just does not work. It takes only
> one rogue node on a network to cause a leak. Then the article meanders
> back through Usenet to the place where it was first gatewayed out, is
> accepted there (because its rewritten Injection-Date looks nice and fresh
> and its original copy of the article has long expired), and off it goes
> round the loop again.
Same solution as above; presence of Injection-Date ("fresh" or otherwise)
prevents injection.
> I can imagine that a gateway whose admin really Really REALLY knew what he
> was about might reinject without the original Injection-Date into an
> injecting site whose sysadmin really Really REALLY understood why it was
> safe, but I would not like to write that into the draft (let them declare
> a cooperating subnet if they want to preserve a semblance of legality).
That amounts to the difference between MUST and SHOULD. If we say MUST,
then such sites can set up a gateway which coincidentally happens to
result in loss of Injection-Date header fields.
>>In all the cases described, an injection agent (or gateway assuming the
>>functionality of an injection agent) would need to have sufficient
>>information about the source of the article(s) to comply with the 8.2
>>obligations. In the specific case of gateways, the x-to-news gateway
>>will have to have sufficient information to be able to determine that
>>the network that the article will be injected into is in fact different
>>(i.e. disconnected from) any news network that the article may have
>>been posted to.
>
>
> Yes, and if they don't not have that information, then they have no
> business attempting to reinject. Safer in that case to reject outright any
> article with an Injection-Date already present.
Not sure what you mean by "don't not". Anyway, we're in agreement on your
second sentence.
>>>>>>What about NNTP-Posting-Date? If it is to be ignored, then there is no
>>>>>>need to say that it MUST be retained.
>>>
>>>
>>>>If it's not supposed to be generated, then why mandate preservation?
>>>>If it's not used for anything, then it is effectively ignored.
>>>
>>>
>>>Because it is generally a Bad Thing to remove any header without good
>>>cause. But you may well argue that MUST is a bit strong here. I have made
>>>a note to review this when I come to writing that bit of the text.
>
>
>>There are some (e.g. Xref) that shouldn't be there in the first place,
>>and which should always be removed when relaying, gatewaying, etc.
>
>
> Yes, that is why we invented the category of "variant headers".
>
>
>> One
>>issue with what you wrote is indeed that under the circumstances
>>(NNTP-Posting-Date is ignored) "MUST be retained" is to strong. However,
>>it is arguable that NNTP-Posting-Date should not be ignored if it is
>>present and Injection-Date is not, in which case "MUST be retained" is
>>reasonable. Specifically, the date-time taken to be the time of
>>injection should probably be:
>>1. that specified in Injection-Date, if present, else
>>2..that specified in NNTP-Posting-Date, if present, else
>>3. that specified in Date, as a last resort
>>I.e. NNTP-Posting-Date fills an interim role until Injection-Date becomes
>>widely supported.
>
>
> I don't think I want to write that into the draft (we should not be
> telling people to use a header that we are deprecating).
The reality is not that we're deprecating something previously defined,
rather we're defining an official header field (injection-Date) which
fills the role that the unofficial "NNTP-Posting-Date" provided.
> But I have no
> problem if some sites take that course as an interim measure.
Then the normative text needs to be clear that sites MAY do so. The text
proposed to date does not say that.