BL> SOT is useful in Netmail that is neither: international; from a
 BL> point, nor to a point (no #1 kludge lines) where someone has
 BL> written "AREA: " at the beginning of their message. I don't
 BL> know what the odds against this are.

 FM> Doesn't matter what the odds are, it *is* possible and is IMHO
 FM> sufficient justification for ^aSOT (at least to be inserted
 FM> when required). Paul has quoted a message from someone who
 FM> wrote some automatic reply software and, unthinkingly, put
 FM> exactly that at the beginning of the message!

  Not exactly. Paul did not explain that the mailer which accepted
this "Area: something else" line as valid was outside spec. The valid
identifier is "#0AREA:NO_SPACE#13" all capitalised with no spaces as
defined in the FTS-4 he keeps telling us to read.

 FM> You certainly could do it accidentally, as the guy did above or
 FM> by typing it.

  He didn't, actually, but there are lots of faulty mailers out there
that would stuff Paul's SOT just as successfully.

  But in any case I have no objection to SOT - can't hurt, may help,
and 5 bytes plus a #13 is not too much to pay. Of course, a singe #1
would do just as well, or even a blank #13.

 FM> You said there were 2 reasons, what was the other?

  The other one was for EOT.

  If we have reader that does not add a Tearline *or* an Origin line
in e-mail, and *also* ends the text without a CR, the first SEEN-BY
line will be added to the text and lost. EOT would prevent that.

  The problem is that one has to propose a faulty Origin line but a
good EOT in the *same* reader. To me this is mad. This is where
Paul's logic? falls apart. He proposes a reader that adds EOT exactly
to spec but stuffs up the Origin and Tearline... in the *same* reader
he says is the only place to add EOT.

 FM> I think the argument against ^aEOT: is that only a message
 FM> originator can put it in reliably. A subsequent processor can't
 FM> for the sorts of reasons you mention. And if the originator can
 FM> put it in, he can also put in the tear and origin lines,
 FM> serving the same purpose (even if there are others in the "user
 FM> text" earlier on).

  I agree.

 FM> I think the rationale is sound, based on the "don't let the
 FM> transport layer fuck with the content" argument.

  It's a good ideal that falls apart in the execution. Paul has
devised something that would work in perfect conditions without
looking at how to stuff it up. It's easy to stuff up... just don't add
EOT and put a false one after SOT. That way, every message is blank
for anyone using a SOT/EOT-aware reader.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---