PE> Where's the 80 bytes, Bob? What do we do if it goes like this:

PE> tearline
PE> fred nerk was here 
PE> Origin

BL>   At last... something to answer.

BL>   Reading backwards from Origin, the CR's (or CRLFs) are not
BL> contiguous. If you find "CR--- " you know you have a false one. The

Pardon?

BL> same would apply if the reader did not add an EOT and someone added
BL> one near the top of the message. Your reader would then delete most of
BL> the message...

So?

PE> And I explained step-by-step why you are a dork.

BL>   Yes... you insulted me rather well but you didn't refute what I
BL> said. 

I did.

BL>   If we assume that an Origin line exists...

You aren't even allowed to assume that.

BL>   If we assume that both a Tearline and EOT may or may not exist:

That is true.

BL>   It is always possible to identify the true Tearline, by counting

No it isn't.

BL> back from the Origin (or SEEN-BY if Origin is faulty) a short line (80
BL> bytes) as specified in FTS-4. 

Nowhere does it say that "short" means less than 80, but even if it
DID...

BL> Blank lines are ignored. 

You pulled that one out of your arse TOO.

BL> The "CR--- "
BL> found is then a true Tearline. 

You don't KNOW that.  That could have been the last line in the
message, on a system which does not generate tearlines.

BL> If other lines than blank lines are
BL> found between, the Tearline is false.

Says who?  Where does it say that there are no other control lines
allowed to go between tearline and origin?  Ever heard of "# Origin"?
Where does it even say that the tearline comes before the origin
line?

When you receive a message without SOT/EOT, you just have to take
one big guess.  When you receive a message with SOT/EOT, you know
that it follows a set of rules to enable to you find the user-entered
text.

BL>   The problem with EOT is that if it is missing (the usual case) then
BL> the scan  backwards takes the full length of every message. It is not

What scan backwards?  Scan backwards to do what?

BL> possible to scan forward and combine it with the search for the null.

It isn't?

BL> The undefined text could contain a EOT line. One has to scan forward
BL> to find the null, and then backward to find the missing EOT. In the
BL> case of no EOT (the usual case), a false one near the head of the
BL> message will truncate the message, even conting backwards.

Bob, I have written a mailprocessor, I've maintained a PKT to QWK
converter, I have enhanced a message reader.  The mailprocessor 
didn't need any logic for SOT/EOT, although having them in the
message prevents problems, the PKT to QWK converter required no
extra logic, the message reader works fine with the extra logic.
This "terrible scanning backwards" is a feature of your own mangled
"mind" trying to come up with an algorithm.

BL>   If you don't answer this I assume it is because you have no answer.
BL> Please do not write insults. I'm better at it than you but it becomes
BL> wearing after a while.

Nice faking, Bob.  I answered every technical point you ever put
forward, although it became wearing after a while, so I just use
"Poor old Bob" on repeats.  BFN.  Paul.
@EOT:

---