#1416 Reinjection - an attempted summary, and a suggested resolution

[Harald Alvestrand <harald@xxxxxxxxxxxxx>]

So far, my buffer shows:

42 postings on the "#1416" thread, Jan 19 to Feb 7, including Charles' 
initial issue mail
Active participants:
- Charles Lindsey
- Russ Allbery
- Forrest J. Cavalier
- Frank Ellermann
- Harald Tveit Alvestrand
- Richard Clayton

Relevant technical information from the thread:

- Injecting a message (with an unique Message-ID:) several times into a 
single Usenet network is supported, and it's important that it remains 
supported ("multipoint injection").
- Current USENET servers (when acting as relaying agents) check Date: 
for staleness (rejecting articles that have a Date: that is so old that 
their history files won't cover the message-ID).
- Injection of articles into USENET where the client posting agent sends 
to someone acting as an injecting agent, and the article then ending up 
with someone acting as a posting agent towards another injecting agent 
("reinjection from an isolated network"), is quite common.
- No technical means exists today for verifyng whether a network is 
truly isolated.
- No existing mail-to-news gateways modify Date:

There was some report of an experiment on propagation with different 
Date: headers, but I've not been able to find that in my archive. Bad 
choice of keywords to search for, I assume.

Suggested hacks include:
- Changing Date: at injection to be within a short distance from the 
current time
- Allowing posting agent to set Injection-Date:, to ensure it's 
consistent between injected copies
- Drop Injection-Date: from the spec

I've probably dropped some important pieces of information, but I've 
seen the above.

--------------------------------------------------------------------------------------------------------------------------
PROPOSED RESOLUTION:

This is very much on the "Keep It Simple" approach to protocol design.

- Date: identifies the date of composition. Don't change it, ever.
- Injection-Date: identifies the date of injection, by the last agent 
that identifies itself as an injecting agent. Proto-articles don't have 
it. Relaying and serving agents never, ever change it.
- "Reinjection" doesn't exist. There is only multipoint injection. The 
means by which a proto-article (including message-ID, but NOT including 
Injection-Date:) gets from wherever it started out to the posting agent 
is not defined by the protocol; if the protocol happens to be NNTP, 
that's not an issue for this specification. (we can add warnings...)
- When doing multipoint injection, Message-ID: MUST be consistent in all 
copies. Date: SHOULD be consistent, if it's not, Bad Things Can Happen.

On the stale article problem:

- We state that existing implementations use Date: to check for 
staleness, and that will cause discarding of articles that are too old. 
Period, end of story, accepted.
- We recommend (require?) that injecting agents refuse posting of "too 
old" articles by Date: - the exact acceptable Date: range should be a 
local decision.
- We recommend that the staleness check use Injection-Date: if present, 
otherwise Date:
- We state that if stale article rejection is an issue for people, they 
should:
 - Ensure that their injecting agent adds Injection-Date:
 - Put pressure on the discarding agent to check Injection-Date: if present

Case analysis:
If a message has Date: on day 0, and is injected on day 7, into a 
network where anything older than 3 days is considered stale, but the 
injecting agents accept 14-day-old proto-articles, this will happen:

- Servers that check Injection-Date: will relay the message. More 
propagation than today.
- Servers that check Date: will reject the message. Unchanged from today.
- Servers that feed from a server that checks Date: will not get the 
message in the normal feed; they may get it offered from feeds that go 
via Injection-Date: checking servers.

If a message has Date: on day 0, gets injected on day 1 into the 
network, and gets injected again on day 7 into the same network, the 
following will happen:

- Servers that check Date: will see the first copy.
- Servers that check Injection-Date: will relay the message twice, 
possibly causing users to see it twice.

The last looks like a loop, but can be solved by sysadmins beating up on 
the injecting agent to enforce stricter policing of posting of old articles.
Is the latter a Big Deal?

                           Harald