BL> The *last* origin line is the real one.

RS> STILL missing the point utterly. The SOT EOT is MUCH easier to use
RS> as the borders of the user text that that sort of farting around.
RS> BUT there is a problem when hardly anyone uses SOT EOT. SO you have
RS> to write the code without relying on them UNTIL they are widely used.

BL> I'll say it one more time...

Wont help, if you havent grasped the point of SOT and EOT by now,
repeating your assertion about it wont change a damned thing.

BL> because I've actually done it in code both ways.

Utterly irrelevant and STILL missing the point severely. No one has
EVER said that adding SOT and EOT *NOW* is the salvation of mankind
for processing mail NOW. It does however provide a useful ADDITIONAL
capability in messages which use it, totally unambiguously delimiting
the user text. Thats a quite separate question to what you have to do
in code NOW while hardly anyone uses it.

What follows is your repetition of a completely DIFFERENT point,
what you undoubtedly have to do in code while ever most messages dont
have SOT and EOT. Its utterly irrelevant to the value of SOT and EOT.

BL> If you use Paul's EOT, you have to look for that in particular -
BL> first - to mark the end of the text. Then you have to look for
BL> the tear line and origin line because both have to be added back
BL> into the message shown on the screen. You have to read both of
BL> them and add them to the message - again! Then you have to look
BL> for the "SEENBY" line to make sure it's there, following the
BL> Origin line. If not - you look for another Origin line and so
BL> on until you find the last one with a "SEENBY" following.

Nope, thats wrong too. Even when there are messages which may or
may not have EOT, there is no reason why you cant scan back from
the candidate end of message, once finding EOT decide that you
really have reached the start of user text. No need to consider
text before that.

OR you can drive it off the SOT seen earlier, if it has been seen,
ONLY use the EOT to marker the end of user text, completely ignore
any possibility of pseudo trailing header stuff embedded in user text.

BL> Without Paul's EOT, you look for the Origin, and then read "SEENBY".
BL> Then you try again - staying inside the null terminator - until you
BL> find the last pair.

BL> The point I keep repeating ad nauseam, is that once you do this,
BL> what the fuck do you need EOT for? It's an extra!

Nope, even thats not right either. It still provides a totally
unambiguous place where you can decide to stop looking when you
find it. Whatever is above that in user text is utterly irrelevant
to you. It absolutely certainly must be user text. Without EOT you
dont have that certainty. You dont have an absolute 'time to stop
backward scanning' market.

BL> Even if it existed in *every* message (which it doesn't
BL> and never will), you still have to look for the tear line

Yes, even with SOT and EOT universally used you do have to process
the trailing header details. BUT the point you totally fail to grasp
is that you know with absolute certainty that whatever precedes the
EOT cant possibly be trailing header text, even if it matches totally
with the specs for trailing header text by the first few bytes on the
line stuff, it has to pseudo trailing header text as a result of the
user quoting another message. And so it utterly irrelevant when
extracting TRUE trailing header text.

BL> (you don't need to do this without EOT because it will always
BL> be *inside* the origin line), then the origin line, and then
BL> read "SEENBY" as a fallback. This identifies the correct
"SEENBY"
BL> unambiguously... the one following the *last* Origin line.

All utterly irrelevant. The EOT flags totally unambiguously the
boundary between user text and trailing header text. You may well
want to extract more info from the trailing header text than just
the origin line, or even the PATH or SEENBY data. You might want
to snoop on product brag text for example.

BL> I began by writing the code to do all this, and I understood
BL> as clearly as St Paul saw Jesus on the Road to Damascus that
BL> EOT was surplus!

Nope, you had a brain fart. You got it wrong. You still get it
wrong. Except for the consideration that while ever SOT and EOT
arent used much in messages, it may well be worthwhile to just
ignore them in code for now. Even then, you can argue that you
should really use them now since they do atleast protect messages
which have quoted trailing header text embedded in user text.

BL> I was using the same code, twice!

Even thats not right, depends on the detail of how you code the
message processor. If for example the occurrence of an SOT triggers
the use of a different trailing header text spitter outer, a particular
message doesnt actually use the same code twice at all, it just totally
unambiguously locks the place at which you can decide you have scanned
back far enough up into user text.

BL> The esisting system can be totally foolproof at the end of
BL> the message.

Nope, not when you consider the false trailing user text in user
text which can get their by quoting messages or stuff like code
which can have early bytes on the line which happen to be the
same as one of the trailing header text flag bytes. The EOT totally
unambiguously settles that question for the messages that use it.

BL> Whether mailers do it properly or not is another story
BL> that applies equally as well to how they treat SOT/EOT.

Yes, the same considerations apply to them, the EOT really does
add a level of protection against some known defects in messages,
false trailing header text in what is actually user text.

BL> Paul's poisition is that the Origin line is not always included,
BL> even though this breaks FTS1. So... we find the seenby and use
BL> that to mark the end of the message. It's still foolproof.

Nope, doesnt protect against false ones in user text. I'm not even
convinced that SEENBYs are compulsory in all circumstances anyway.

BL> I say that if a braindead mailer leaves out an Origin line
BL> that everyone needs to be able to reply to the message,

They dont, the absolute vast bulk of people just reply to the
From: field and dont give a stuff about the Origin line. And the
Origin line is often useless anyway, particularly with gated echoes.

BL> then why would this same braindead mailer add EOF that no one
BL> but Paul gives a stuff about?

Thats missing the point utterly. The SOT EOT is about whats optional
and handy, not about whats compulsory, a different matter entirely.

BL> Paul says it is easy to do. I agree with him. I did it. No worries.
BL> I also added a tear line and an origin line, and it uses exactly the
BL> same code with different characters. Instead of writing "^aEOT:" I
BL> put " * Origin". What's the difference? The only
difference is that "
BL> * Origin" goes in the right place - at the end.

Doesnt help a bit with the question of whether SOT and EOT give some
extra protection for messages which use them. It does, its useful.

(Continued to next message)

--- PQWK202