BL> My point here, was that an unidentifiable message is safer than
BL> an identifiable one. There is no need to identify SOT, just so
BL> long as *somehting* is there. In that case, it is better not to
BL> identify it. The absolute minimum is a blank line, next best is
BL> a line with just #1 in it. The four bytes "SOT:" have no
BL> function.

PE> You can't have a blank line, as that would not be a control
PE> line.

BL>   That's my whole point. You don't need a control line, just a blank.
BL> It *isn't* a control line, even if it has #1 as its only character.

I've explained this enough times already, from now on you get a
"Poor old Bob".

PE> The minimum you could have is ^aS: You need a ":" and a
PE> keyword, you can't just have a ^a by itself. Ref FTS-1.

BL>   Who said it was a control line? It does not meet the control line
BL> specification of #1 followed by unique keyword so it isn't a control
BL> line. Don't you know how to read a specification? Where does it say
BL> anything about a colon? 

Read FTS-1 for yourself dorko.

BL> FMPT does not have a colon.

FMPT is an exception to the rule.

BL> The basic address is in the message header, and the sysop will
BL> know his own points, so you dont *really* need the Origin.

PE> Poor old Bob. Doesn't even know what the fixed header address
PE> has in it.

BL>   I was talking about the message header, dicko. That's why I used the
BL> words: "message header".

Yes, and you don't understand that.

PE> Hint, it's not 711/934 when the echomail message *you* wrote in
PE> this echo is going from Bill Grimsley to David Drummond. Both
PE> origin and destination are 640/305.

BL>   Hint: Are you sure you know how it works? The message header is the
BL> 14-bytes at the top of each message (with no room for point number).
BL> When I reply, it goes all the way back the way it came, using the
BL> address in the message header, 

Nope, the address changes from system to system, as it sends your
message between 3:400/400 and 3:500/500 etc etc.  The original
711/934 disappears for good.

BL> and when it gets to the other end it
BL> has the correct address (except for the point number). As I said, the
BL> home system will knows its own points, so you don't *really* need the
BL> Origin line.

Yes you do, the 711/934 disappears forever otherwise.

BL>   The only time you need to read the Origin line is if you want to
BL> reply directly to a point's email. Otherwise, you reply to his home
BL> system and rely on that to pass it on. You don't *really* need the
BL> Origin line.

Nope, you don't have the home system 711/934, it disappears forever.
Poor old Bob.  Pontificating from ignorance again.

PE> No need for that. You can do it in an upwardly-compatible
PE> manner. Tell me how the SOT/EOT spec is flawed so that can't
PE> use it to find start and end of user-text. Good luck. BFN.
PE> Paul.

BL>   It isn't there in 99.99% of messages. Now try and use it.

On those messages, you have to use the "hope and pray" method.
So?

BL>   But that's not the worst part. You didn't realise that in a mixed
BL> system of eot-aware readers and no-eot-readers, the eot-aware readers
BL> can damage compliant messages with a false eot in them.

No they can't, there's no such thing as a "false eot".  Failure
to comply with specs is simply failure to comply with specs.
No-one's fault but your own.  I've answered this enough times
already.  You'll get "Poor old Bob" from now on.  You really are
quite thick.  BFN.  Paul.
@EOT:

---