RS> I still cant see how it can do that when it was INSIDE the
RS> SOT/EOT which was SPECIFICALLY intended to allow for that
RS> problem of stuff that would normally be part of the mail non
RS> text body appearing in what is meant to be the body of the text.

PE> It specifically disallows intra-text kludge
PE> lines, except those meant to mark-up text.

RS> Yes, and thats fucked by design, makes no sense whatever.

PE> It does.

Nope, it makes no sense whatever for Tobruk to be
scanning for stuff like a MSGID between an SOT/EOT pair.

PE> I couldn't have done that anyway.  The kludge lines are
PE> not mine to decide "these ones don't count".  The kludge
PE> lines are designed for control information, that is specified
PE> by FTS-1, I can't say "hang on, these are user-text".

You are having another massive brain fart. It makes no sense whatever
for Tobruk to be scanning for stuff like MSGIDs between an SOT/EOT pair.

PE> Regardless, I don't consider it to be an issue. You can't send
PE> binary information via FTS packets, you have to use uuencode.

Soorree, the whole POINT of the SOT/EOT pair was to delimit the
body of the message so that if some stuff which appeared to be
control stuff would be IGNORED. That was THE WHOLE POINT OF IT.

PE> There is no reason to be desperate to be sending x'01' in your
PE> messages. There IS a reason to be desperate to send "---" in your
PE> messages, and there is reason to want to send Origin as well.

Unfucking believable. Now try explaining why it makes the SLIGHTEST
sense for Tobruk to be scanning for MSGIDs inside an SOT/EOT pair.

PE> All echomail, that I send to Dave Hatch, has MSGs in the PKT
PE> with a from address of 3:711/934, a destination of 3:711/809.
PE> If I were to send an echomail message with an address of
PE> 3:640/305, a destination of 3:711/809, then as far as 3:711/809
PE> is concerned, he just received a routed echomail message.

RS> Still says nothing useful whatever about why Tobruk is mindlessly
RS> scanning for MSGIDs in the body of a message, BETWEEN the SOT/EOT pair.

PE> It wasn't.

THE ONLY PROBLEM WITH THAT MESSAGE WAS THAT IT HAD A MSGID BETWEEN
AN SOT/EOT PAIR. THAT WAS THE ONLY OUT OF SPEC THING ABOUT THAT
MESSAGE. THERE NEVER WAS ANY MESSAGE WITH AN EMBEDDED ORIGIN LINE.

RS> Arent you still having a brain fart about embedded
RS> origin lines which werent even IN that message, and
RS> which are ALLOWED between an SOT/EOT pair anyway ?

PE> Imbedded origin lines are allowed, incorrect
PE> addresses in the headers are not allowed.

I CAN NOT POSSIBLY HAVE PRODUCED AN INCORRECT ADDRESS IN THE
HEADER. SINCE THE ONLY MESSAGE WHICH WAS OUT OF SPEC HAD A MSGID
BETWEEN AN SOT/EOT PAIR, TOBRUK MUST HAVE HAD A BRAIN FART.

PE> Both problems were fixed in 2.60.

RS> Dunno, I still dont see that thats the correct place to fix it.
RS> Surely since it was within the SOT/EOT, the problem is in Tobruk
RS> which didnt ignore the superfluous MSGID in the message body.

PE> Tobruk didn't even see the MSGID.  It doesn't look for it.

Welp that was the ONLY blemish in that out of spec message.

PE> It's not smart enough to reject the message because of that.

Welp, there must be some fuckup there somewhere
because that was the ONLY DEFECT IN THAT MESSAGE.

PE> Tobruk has every right to reject the out-of-spec MSGID, in the wrong place.

RS> Nope, makes no sense to do that, in fact it makes much more sense
RS> to ALLOW those between the SOT/EOT pair, just like other stuff.

PE> However, it's not smart enough to do that.

RS> It should be smart enough to not check for
RS> kludge lines between the SOT/EOT pair.

PE> It is allowed to, but in this case, it didn't.

And it makes no sense whatever for it to do so.

PE> GMD might be. In this case, it was rejected not because
PE> of the intra-text MSGID, but because of the incorrect address
PE> in the fixed header portion of the message in the PKT.

RS> I still cant see why Tobruk is using an address
RS> from that embedded MSGID at all, thats fucked.

PE> Read what I said, Rod.

Try expressing yourself clearly Paul.

PE> ADDRESS IN THE FIXED HEADER PORTION.  It wasn't looking
PE> at the MSGID at all.  It doesn't use it for anything.

Welp, its a nice theory, now try explaining how a message
WHICH ONLY HAS AN MSGID BETWEEN THE SOT AND EOT CAN HAVE
DONE THAT. IT HAD NO EMBEDDED ORIGIN LINE AT ALL, WHAT SO EVER.

RS> Either you are having a brain fart or I am.

PE> You are.  I can send you the PKT if you want to see it.
PE> You can use inspecta to see the address in the header portion.

RS> Says nothing useful whatever about why Tobruk had a massive brain
RS> fart and used the address from that embedded MSGID between an SOT/EOT
RS> pair. THATS where the problem lies. Makes no sense to do that.

PE> It didn't!  It used the address from the fixed header!!!!

WHICH FUCKING PKT ?  You are so fucking cryptic that you dont
even say if you mean the PKT *I* uploaded or the PKT THAT TOBRUK
PRODUCED FROM THAT. Since you made the comment about sending it
to me, I assumed that you meant after it had been thru Tobruk.

PE> Like I said!!!!  A bug in PQWK 2.50 makes it
PE> put the incorrect address in the fixed header!

Well, you originally claimed that a message of mine had an embedded
origin line. You eventually realised you had fucked that up and it did
not. NOW you may be saying that PQWK 2.5 produces a PKT which has a
message which has the incorrect address in the a header. Presumably you
mean in the header of that particular message that is dud, in that PKT.

I really havent got a fucking clue what you are trying
to say since what you do say is so damned cryptic.

AND I CERTAINLY HAVE HAVE NEVER DELIBERATELY SEND YOUR SYSTEM A
MESSAGE THAT I KNOW IS OUT OF SPEC. SO YOU CAN TAKE YOUR STATEMENT
ABOUT ME HAVING DONE THAT MALICIOUSLY AND SHOVE IT UP YOUR ARSE.
@EOT:

---