🚀 go-pugleaf

Unfortunately, requiring more dashes just makes the problem
harder and introduces additional ambiguity.  Let me explain.
A primary motivation for writing that RFC was that I was
getting tired of constantly modifying the bursting agent in MH.

First, I tried looking for 5 dashes at the beginning of a line.
Sure enough, some digests let that through.  Then I upped it to 30.
Sure enough, some digests let that through.  Then I got clever and
introduced special heuristics based on the number of blank lines
both preceeding and following the line that started with the dashes.
Still not good enough.  I then decided to look at least TWO LINES ahead
and see if I could find what looked like a header.  Still no good,
one day someone just happened to have a couple of blank lines, a line
of dashes, a couple of blank lines, all followed by a line that looked like
a header.  Brute force and extremely clever coding just can't compete.

So, I decided that we need to bit (well, byte) stuff.  This is the ONLY
way to unambiguously separate messages in a digest (or a forwarding of
messages, in general).  So, if you're going to change all that software in
net to be considerate and generate digests etc., that other software can
burst, then you might as well make the change as simple as possible.
Hence, the choice of a single dash for the EB.
The RFC contains very simple algorithms to byte-stuff on encapsulation
and to burst on decapsulation.  The latter algorithm, in fact, needs
only one character look-ahead.

The point of all this is that I want to get painless bursting with the
absolute LEAST amount of effort on the part of the mail hackers in the
net.  I really don't think it's too difficult to look at the beginning of
each line and output a "- " if it starts with a "-".

/mtr