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.

It does.  I couldn't have done that anyway.  The kludge lines are
not mine to decide "these ones don't count".  The kludge lines are
designed for control information, that is specified by FTS-1, I
can't say "hang on, these are user-text".  Regardless, I don't
consider it to be an issue.  You can't send binary information
via FTS packets, you have to use uuencode.  There is no reason to
be desperate to be sending x'01' in your messages.  There IS a
reason to be desperate to send "---" in your messages, and there
is reason to want to send Origin as well.  

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.

It wasn't.

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 ?

RS> You quite sure you have been taking your medication ?

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

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.

Tobruk didn't even see the MSGID.  It doesn't look for it.  It's not
smart enough to reject the message because of that.  Neither is GMD.
GMD really only looks at echomail kludges unfortunately.

PE> Tobruk has every right to reject the
PE> 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
RS> for kludge lines between the SOT/EOT pair.

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

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

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

Read what I said, Rod.  ADDRESS IN THE FIXED HEADER PORTION.  It
wasn't looking at the MSGID at all.  It doesn't use it for anything.

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 fart
RS> and used the address from that embedded MSGID between an SOT/EOT pair.
RS> THATS where the problem lies. Makes no sense to do that.

It didn't!  It used the address from the fixed header!!!!  Like I
said!!!!  A bug in PQWK 2.50 makes it put the incorrect address in
the fixed header!  BFN.  Paul.
@EOT:

---