FM> But, OTOH (and this is my point), if you are the originator of
 FM> a message you can put that other stuff in, where it belongs,
 FM> all the time. So for a message originator there's no need for
 FM> EOT, and for a subsequent reader you can't reliably add it.
 FM> Mostly you will be able to *correctly* add it, in those cases
 FM> where you don't need to.

  He, he, he. This logic is inarguable. I'll be interested to see how
Paul argues it.

 FM> There needs to be an 0x01 line, specially added in a particular
 FM> circumstance. I think I'd rather add ^aSOT rather than
 FM> ^aILLOGICALTWIT, in that circumstance where it was needed. :-)

  My point here, was that an unidentifiable message is safer than an
identifiable one. There is no need to identify SOT, just so long as
*somehting* is there. In that case, it is better not to identify it.
The absolute minimum is a blank line, next best is a line with just #1
in it. The four bytes "SOT:" have no function.

 FM> As someone who's trying to learn and understand this stuff, I'd
 FM> like to see the reasoned comments on both sides.

  So would I. I keep thinking I'm talking to Rod Speed. This is my
resoning so far: 

  In Fido there are some things without which it will not work and
others that merely send faulty messages. At the foot of the message, a
null is required. Inside that, SEN-BY is required. Without these, you
won't get the mail. This is all we can count on, and on that basis,
the only "reliable" action would be to end the message at the first
SEEN-BY. This is what I do in fact. 

  Next, but not strictly essential, is the Origin line that gives
the return address (for points). The basic address is in the message
header, and the sysop will know his own points, so you dont *really*
need the Origin.

  The Tearline is useless. It is meant to define the end of text and
Paul duplicates this with his equally useless EOT, but all it really
does is make a nuisance of itself. EOT is even worse, being basically
dangerous if someone adds a false one earlier.

  At the top of the message, there is a need for something like SOT.

  The way I actually process mail is as follows:

1.  Read header
2.  Check for AREA: in first line... email or netmail.
3.  Read consecutive #1 control lines until something else intervenes.
    Define message START there.
4.  Look for end-null.
5.  Read backwards to "*". If not found show entire message to null.
Origin: ")
6.  Find end of Origin line and define message END there.

  I use the Origin rather than the first SEN-BY because there is no
foolproof way to find the first SEN-BY. If you scan from the top the
first one could be in the message text. If you scan backwards from the
end, there may be several SEN-BY lines. The only way is to find the
Origin line first, and if you have to do that, you may as well use
it.

  The only foolproof way is to remove all #1 control lines and show
what's left, incuding the SEN-BYs.

  My logic relies on an Origin line being present. I can't rely on EOT
being present. In fact, I have to write a special routine to remove
Paul's fucking EOT line.

  I understand Paul's reasoning, and there *is* a need for a way to
define the end of text in a message, but it's too late to add it now.
The only thing that would work is something that mail won't work
without... disallow multiple SEN-BY lines or add #1 to each SEN-BY. 
Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---