Re: #1416

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <Pine.LNX.4.64.0808081218001.6847@xxxxxxxxxxxxxx> stanley@xxxxxxxx writes:

>Russ Allbery <rra@xxxxxxxxxxxx>:

>> Briefly: the Message-ID plus the Date is the unique identifier for the
>> message.

>I'm with Frank in being confused by this statement. According to USEFOR:

>    A "message identifier" (Section 3.1.3) is a unique identifier...

>This clearly states that two articles with the same message id, even with 
>different dates, are the same article. "Every article ... ever". If you 
>say that "message id plus date" is the unique identifier, then you are 
>saying that two messages with different dates but identical message ids 
>are two different messages -- a violation of the definition of message id.

Sure, but in practice if you want to check whether a message is the same
as some other ancient message, it is much simpler to have a "date" as well,
so you can just say "this is so stale that I shall assume it is a
duplicate and ignore it anyway".

>> It requires, if I remember correctly, badly-timed multiple
>> injection of the message such that it expires on the basis of its original
>> Date and is then reaccepted on the basis of the modified Injection-Date.

>If a message is expired based on the Date header, why would the server 
>then accept the same article with the same Date header later? If it does,
>it's just going to expire it again. This just doesn't make sense. It 
>sounds too much like a bug and not a feature.

If you now have both Date and Injection-Date headers, then which is the
true "date" for the purposes of the test above? "OLD" (i.e. unupgraded
software) with use Date, and "NEW" (upgraded sotware) will use
Injection-Date.

So if two copies of an article are circulating, one with just Date and the
other with both Date and Injection-Date (say 24 hours later), and the
first arrives at some NEW server, is stored and eventually expires (say
afyer 10 days) and then 23 hours later the second turns up, it will be
accepted as if it were new.

So how can this happen? it requires the following scenario:

1. The article was generated by an OLD User Agent, and multiply injected
   to *two* Injection Agents (one OLD and one NEW).
2. The two injections were 24 hours apart.
3. The 2nd copy got delayed by ~10 days somewhere, and then somehow got
   routed to that FINAL agent which had just expired the 1st copy.
4. That 2nd copy just "happened" to arrive at the FINAL agent within the
   critical 24 hours after the expiry.
5. The flooding algorithm had somewhere failed to prevent the propagation
   of the of the delayed copy (i.e. the FINAL agent must have been in
   some rather poorly connected part of the network).

So that is five conditions to be satisied, all somewhat improbable. And,
at the end of the day, all that happens is that the client users of that
FINAL agent get to see the article twice, which is no Big Deal IMHO.

>For that reason, I think I have to object to the exclusion statement and 
>require injecting agents to put in an Injection-Date header unless that 
>header is already there, without regard to existing message id or date 
>headers.

Exactly!

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