FM> I think the argument against ^aEOT: is that only
FM> a message originator can put it in reliably.

Yes, and thats the reason why its very desirable for it to do so, coz it can.

FM> A subsequent processor can't for the sorts of reasons you mention.

Yes, no one has ever disputed this.

FM> And if the originator can put it in, he
FM> can also put in the tear and origin lines,

Nope, because the message originator which CAN reliably bracket the user
text with SOT/EOT ISNT NECESSARILY THE SYSTEM WHICH ADDS THE TEARLINE AND
ORIGIN LINE and this is where you are having your massive brain fart. The
message originator CANT rely on the tearline/origin line being done right.

FM> I think the rationale is sound, based on the "don't let the
FM> transport layer fuck with the content" argument. But given
FM> that we *have* FIDO, we *have* a whole heap of existing software
FM> out there which *does* do that, there's not much point.

Corse there is. Once the SOT/EOT is in use, its feasible to use it to
quickly and reliably determine what is the user text, and FALLBACK to
the more long winded bullshit exercise involved in working out what is
user text IF THEY ARENT PRESENT. Something that say chooses to add that
tearline/origin line stuff later can say toss messages a lot faster when
they are SOT/EOT messages. If say some dork of a user chooses to configure
the message originator so it doesnt use those, he gets to wear the
significantly degraded performance as it farts around doing it the other way.

FM> Specifically, there's no point with ^aEOT:

Fraid so.

FM> but ^SOT: should be used at least when it's needed.

Or bracket the user text with SOT/EOT and hope that eventually
more and more message processing software does it that way.
@EOT:

---