Answering msg from Paul Edwards to Rod Speed,
on Sunday January 22 1995 at 13:34

 RS>> The principle is fine, the problem is introducing that now when most
 RS>> messages dont use them.

 PE> It is not a great problem, because what it does allow is for the
 PE> traditional method to work better.  Traditionally you have to
 PE> search from the end backwards, skipping SEENBY, then Origin line,
 PE> and then you will probably find a tearline.  Now, if a tearline
 PE> is missing, you will instead find an EOT, whereby you are meant
 PE> to stop looking.  Traditionally, you would have continued looking
 PE> for a "-+-" in the user text, or at least if you had just run over
 PE> a blank line you would have.  It is really a pigs swill as to
 PE> what exactly you are meant to do here.  SOT/EOT serves a lot of
 PE> its purpose just by being there.  E.g. if SOT/EOT is used, then
 PE> you will never find "AREA" as the first line in a netmail message.
 PE> Anyone who doesn't use SOT/EOT has to rely on the user being a
 PE> really nice person and not sticking "AREA" as the first line of
 PE> their netmail messages.  That is satisfactory IMO.

Paul,

    Why would you _want_ to search backwards past the SEEN-BY lines anyway?
Anything before that is pretty much guaranteed to be user text, or an
origin
line, or tearline, which is part of the message body anyway. Just look for
the first CR before the SEEN-BYs.

    The way I do it is to use a "circular buffer" and just read
in chunks of PKT, and write out chunks of messagebase. If it hits a line
with "SEEN-BY" on it, then it removes that line. It continues
until it finds a terminating null. It does not have to seek through the
message twice (once to find null & SEEN-BYs, once to write the actual
body), and this speeds up things considerably.

    Of course this means that _any_ occurrence of "SEEN-BY" in
the message will be stripped, regardless of whether it's control info or
text. This is an import only tosser, BTW.

 RS>> Nope, its much easier to have something which is guaranteed to be
 RS>> the end of the user text. Anything else is farting around detecting
 RS>> when the user text stops and when trailing header detail starts.
 RS>> Particularly for stuff like forwarded messages which may well
 RS>> have stuff like real origin lines in the user text.

 PE> Yeah, this is the big problem.  Mail readers should be stripping
 PE> the Origin and tear lines completely, the same way they strip
 PE> the INTL line.  Failure to do so means that people keep shipping
 PE> these control lines around with their messages.

    Can you suggest how I will find the return address of an echomail message
without an origin line? It's not possible.

    Don't say ^aMSGID.

 RS>> And the reason its not very useful for that is because you have what
 RS>> is clearly not normal user text above it. Thats the way the system has
 RS>> grown over time and there is absolutely nothing you can do about that
 RS>> now.

 PE> It can change Rod.  The INTL was added on as an afterthought,
 PE> and not compulsory, as an example.  I would expect SOT/EOT to
 PE> remain the same - optional, easy to generate, and can be used
 PE> as a small part of the logic used to find origin lines and
 PE> tear lines etc.

    Personally I think they look silly, considering they put a lovely blue
bar right across the screen in GoldED. But it's my fault for viewing
kludges, eh? (-:

Best wishes, Ro.

---