BL>   You're right. I used the 80-bytes to minimise the chance of finding
BL> another Tearline within a Tearline, but it would best be done reading
BL> CRs (and possible LFs) as part of the '---' identifier. My problem is
BL> that this does not change the logic. No matter how unlikely I make it,
BL> Paul will still say there is a chance... and at the same time ignores

Standards are meant to work so that if you follow the spec, it
actually works, not "mostly works".

BL>   The next stage is to examine the many ways of stuffing EOT, and
BL> compare the results to a stuffed Origin line and Tearline. You speak

Poor old Bob.  If you don't follow the spec, it doesn't actually
matter a toss what happens, that's a problem with buggy software.
Same as if the origin line is stuffed and the address is invalid.
It doesn't matter your end, it's the originator who needs to fix
his software, not you.  A grunged message is a grunged message.
BFN.  Paul.
@EOT:

---