BL> IF the *original* creator adds SOT/EOT, then
BL> why not add a Tearline and Origin line instead?

Yes, you dont need the EOT if the original spec for the message had
mandated a rigidly specified trearline/originline pair for all messages.

We are talking about whats useful WHEN it didnt happen like
that tho. Particularly when the FTS chooses no to just mandate
that more rigid specification of the tearline/originline now.

BL> Paul's logic is flawed. In fact, Paul's logic isn't.

You havent actually got a clue what standards are about yourself,
particularly when they grow radically over time to end a a hell
of a long way from where they started and you choose not to just
mandate a swag of stuff that was once optional.

BL> Have you actually written your reader yet? How do you do it?
BL> You just put EOT ahead of the Tearline... right? So what's
BL> EOT doing? If you *always* put an Origin line on the end
BL> of your message (like you do with EOT), then the LAST origin
BL> line in the PKT message is *always* the correct one.

Pity that only covers the case where you have complete control
over the full detail of use of the EOT, the tearline, and the origin
line, yourself. Quite a bit of mail processing software does not.

One obvious example is an offline mail door which tosses whatever the
user uploads into the message base. It may well have no control over
the tearline and originline detail at all. If it chooses to bracket
the user text with SOT/EOT, its then added a considerable level of
insurance against fuckups that other software can do to the message.

Not only fuckup in the design sense, but also fuckups in the config
sense as well. *IT* knows what is user text, if it always brackets
that with SOT/EOT that provides an extra level of insurance.

Robust software is all about being bullet proof, not mindlessly
assuming that everything else will be perfect or perfectly configged.
@EOT:

---