PE>> Tell you what Rod.  Manually create a packet, and include in it two
PE>> messages with the from, to, subject, timestamp the same, and also
PE>> put in two different MSGIDs.  I bet you $10,000 it doesn't get past
PE>> my Squish 1.10 system.

RS> Utterly irrelevant. The point is how often thats going to happen.
RS> And thats a stupid way to dupe check anyway. Even if it is its most
RS> unlikely to bite you.

PE> The problem happens once a month with Bob with no seconds fixup.

Yep, no argument that the seconds fixup is essential. The argument was
tho about whether there is any practical difference between a 1 sec and
a 2 sec increment. There isnt. And whether a real MSGID should be there
TOO, it should.

PE> Whether it is a stupid way to dupe check or not is irrelevant.

Nope, its just a bug in 1.10 which gives a bizarre result. No significance
in what should be done in outgoing messages coz you have to use the seconds
fixup for systems which dont use MSGID at all, whether thats by design or
because a particular system has been setup to dupe check without using
MSGID on a version of Squish or anything else which doesnt have that bug.
THATs the point.

PE> The fact is my system, and many others, are using that algorithm.

Yes, so you need BOTH the seconds fixup AND a real MSGID TOO.

PE> Like I say, put your money where your mouth is.

Utterly pointless, I KNOW about that Squish 1.10 bug have done for quite
some time. No news to me.

PE> What are we arguing about if it isn't the above?

I am saying that we need BOTH the seconds fixup AND a MSGID in the
outgoing messages. And that there is no practical difference between a 1
second increment in the seconds fixup and a 2 second one. The chance of
getting bitten by the 2 second fixup is utterly remote, and the 1 second
fixup has precisely the SAME problem, a very obscure.

PE> I'm saying your messages won't get through unless you make an effort
PE> to get the timestamp unique.

Yes, I have said all along that a seconds fixup is needed. Its not as
bad as you say it there tho, even without the seconds fixup you STILL
have to edit TWO messages in the SAME minute with common To: From:
Subject and Date fields. That really is quite uncommon tho it certainly
does happen.

PE> Your current PQWK makes a reasonable effort to do that, but will be
PE> defeated by more than 30 messages (then it's back to luck).

Nope, you STILL miss the point here. Its not ANY pkt which has more than
30 messages which is the problem, the problem is that in that case you
have to have TWO messages with common To From Subject Date and Time
identical, AND be precisely 30 messages apart in the REP. Thats extremely
bloody unlikely. And even if you use a 1 second increment instead, the
SAME potential is still there except that the two messages have to be
PRECISELY 60 messages apart instead.

PE> The new PQWK does that and more.

Nope, it makes SFA difference to the risk.

PE> And since my dupe check count is set to 1, I won't be able to detect
PE> it myself, so your message will probably stop at Dave Hatch's system.

Nope, you have STILL missed the point. The risk is absolutely microscopic.
And MSGID should be added TOO, to give even better protection on system
which dupe check on MSGID alone.

--- PQWK202