Re: 8bit transport (8BITMIME) and MIME

["David Herron" <david@xxxxxxx>]

>> What I'm wondering is how all this relates to the Content-Length: header
>> that shows up in System V release 4 in order to permit binary-transparent
>> mail [...]
>> without having to stick > in front of lines beginning with From.

Eh?  Mark, how does sticking `>' in front of `From<space>' lines help with
transporting binary files?  The historical (hysterical?) reason was that
silliness with the `From<space>' line added by /bin/mail(?) being used as a
mailbox separator.  It had nothing to do with transparency and is certainly
nontransparent by itself!

>> The SVID requires this field, and all SVR4 implementations (including
Solaris)
>> implement it.
>
>Sigh.  This is in direct conflict with the decision of the 822 extensions
>working group, which determined that neither line counts nor character
>counts were a satisfactory means of delimiting body parts.

Double Sigh.  Unfortunately that Content-Length stuff predates the 822
extensions working group by a few years.  I remember seeing it on the ATT
7300 I owned many years ago!

>The SVID needs to be revised to get rid of Content-Length in favor
>of a local mailbox format that keeps the message-length *outside*
>of the mail message itself.

Apparently it's not just SVID that's broken in this way.  Apparently `elm' (
and thus pine?) does the same silliness.

I personally prefer mh's approach to the local mailbox format (one directory
per mail-folder, one file per message) which is why PathWay Messenger uses
that mailbox format.  This even works alright on PC's and MacIntosh's,
systems where people seem to worry about the absolute number of files on the
system implying that the system imposes some small limit on that.

REMINDER!!!!!  Mailbox format issues are outside the scope of the working group!


	David