🚀 go-pugleaf

The problem with the AT&T/SUN half-assed Content-Length: mbox format
is that it is half-assed.  The *only* advantages of mbox format are:
 1) being able to edit the mailbox with an external text editor
 2) being able to port the mailbox to a system with a different file
    representation (e.g. record-based files, or different newline
    conventions) difficulty.
AT&T/SUN mbox format has destroyed these advantages for very little
gain.

AT&T/SUN format requires a combinination of two delimiter searches and
a count parse/skip.  Because it is done in the originating UA, a
plethora of failure modes are introduced.  Their scheme can't work
unless absolutely every agent in the path is a Unix machine running
their software.

Even more damning, there are other existing and well-understood
formats which offer greater gain at no additional cost.  One is left
with the feeling that AT&T/SUN hired a bunch of kids out of high
school who lacked any real understanding of the issues.

The MIME archives are filled with discussions on how binary data is
represented in mail.  It seems that AT&T/SUN have paid no attention to
this at all.

Perhaps there is a good reason why they ignored cross-platform
interoperability.  If their e-mail infrastructure won't work in a
multi-vendor environment, then you have no choice but to buy all your
equipment from them.

If you are going to go to a count-based format, you might as well use
tenex (mail.txt) format which does it right.  The tenex format has a
number of other advantages over mbox format, including the ability to
use random access I/O to update status (it reserves space for status
flags).

Personally, I've come to believe that a directory-folder (with each
message occupying a single file) format such as mh is probably the
overall best compromise.