PE> To "detect" it, I use Squish's "Duplicates"
keyword.  In any
PE> conference that I have defined that has a low number of messages
PE> (e.g. 1 per day), and I happen to be keeping 1000 duplicates per area
PE> (the Squish default), then I will indeed keep 3 years worth of this
PE> information, and if you attempt to send me a duplicate MSGID, your
PE> message will be lost without warning when it passes through this system.

RS> Yes, but as he says, the chance of that
RS> happening, someone keeping that period,

PE> It is very easy to keep 3 years worth of duplicates.

Yes, but the EASE hasnt got much to do with CHANCE. What matters
is how many actually DO, not how easy it is to do. And before it
becomes an actual problem, the ALSO have to do the other stuff too.

PE> A lot of people keep a fixed area size, e.g. 500 messages.
PE> They do that on Lotus, or Z3_NETDEV, not sure about BLAKES_7,
PE> then they will indeed get 3 years worth of duplicates.

*IF* they actually choose a number which results in a 3 year
accumulation. I have my doubts that all that many actually do,
even in those low volume echoes. *AND* its only a problem if
they ALSO do other stuff too.

RS> and you accidentally reusing the SAME MSGID in the SAME very low
RS> volume area, is indeed utterly microscopic. And if that risk does
RS> actually worry you, the answer is to improve the dupe delete mech
RS> so it only does an unconfirmed delete when the other fields match
RS> TOO, and say asks for confirmation if they dont also match. Far
RS> better than just ditching MSGID for such a microscopic risk.

PE> When you get:

PE> 1. Squish changed so that it does this
PE> 2. The *masses* of Squish to use the new version

PE> then let me know.

No thanks, I will let you know NOW that you are missing the point
utterly and throwing the baby out with the the bathwater in the
process. Like I say, the risk *NOW* is utterly microscopic. *AND*
readily fixable by YOU with some care in the MSGID process too if
you do want to be totally anal about that utterly microscopic risk.

PE> Certainly it's of absolutely no use for getting an address from.

RS> Thats wrong for starters, its more rigorously defined than the
RS> other source.

PE> WRONG!

RIGHT!

PE> The MSGID address is defined to be the
PE> address in the ORIGINATING NETWORK.

And THAT is more useful than the OTHER sources, like I said.

PE> Quite often, this is an internet address,

Nothing remotely like quite often. And the other sources
of the address suffer from the same problem too.

PE> but it could also be an Adultnet address, Zyxelnet
PE> address, or any other net, with numbers that are
PE> shared by another net, or maybe even a fakenet.

Yes, its possible, no its not that common. Yes the other sources
ALSO have that as possible *TOO*. Atleast with the MSGID its rather
easier to be sure what the address actually is, even if you do have
to allow for the possibility that its not the RIGHT address. *BUT*
thats JUST as much a problem with the OTHER candidate addresses TOO,
and they are harder to find *TOO*

PE> Since there is NO WAY of knowing what net it was
PE> that created the message, you HAVE to treat that
PE> as a character string that is not to be interpreted,

Bullshit. You can treat it as a readily findable
address, which has to be used with the SAME caution
as any other address, *BUT* its more easily findable.

PE> anything else is irresponsible.

Pathetically bogus form of argument, just stick the
word 'irresponsible' on it and hope that wins the day |-)

PE> On the other hand, the address in the origin line is defined in FTS-4,

And suffers from the SAME deficiencys, and is not as easy to find.

PE> and will be a fidonet address (or more to
PE> the point, an address in the CURRENT network).

Nope, you cant rely on that either. Whatever FTS-4 may say.

PE> The INTL line is similarly robust.

And is nothing remotely like universal.

PE> It's only use is for duplicate detection,

RS> Nope, there are a variety of other benefits, particularly
RS> when its turned into a valid REPLYID when replied to. You
RS> have a quite unambiguous specification of what its a reply
RS> to. And thats not just useful for threading either.

PE> Yeah, that's one small benefit, when
PE> someone goes and changes the subject line.

Which a surprising number do. I think thats fucked myself,
but they do anyway. Apparently mostly for those who browse
lists of messages for 'interesting' ones using the subject
line. Tho some just play smartarses with the subject line.

PE> and that's the problem I'm most worried about.

RS> For microscopic risk which can be readily
RS> fixed if if really does worry you.

PE> Nope,

Yep.

PE> can't be fixed

Sure can.

PE> unless you can change all the software in existence
PE> that dupe detects quite validly based on the FTS-9 spec.

Bullshit. Your other option is better MSGID management at your end.

PE> It is YOUR duty to make sure that no two messages you
PE> generate have duplicate MSGIDs, NOT the author of Squish.

Yes, and you can perform your duty if you are anal enough to bother.

PE> You can bay at the moon all you like, and run around in
PE> ever decreasing circles, but it doesn't change a damn thing -

Enjoying yourself are you ?

PE> it is YOUR responsibility,

(Continued to next message)

--- PQWK202