🚀 go-pugleaf

(*sigh*) How soon they forget ...

> Some mail arrived here recently with a line:
>
> Encoding: 219 Text, 814 HEX
>
> in the headers, no other "MIME" type line was present. Z-Mail interpreted this
> as a multi body part message when it was nothing of the sort. Both pine, mh
6.8
> and elm 2.4.21 read the headers correctly and ignored the "Encoding" line.

The `Encoding:' line does indeed indicate a multi bodypart message.  It does
not do so using MIME mechanisms, however.  Prior to a year ago if you wanted
to do multi body part messaging and were looking through the list of RFC's
the most recent one to reach your eye was:

1154  Robinson, D.; Ullmann, R.  Encoding header field for internet messages.
      1990 April; 7 p. (Format: TXT=12214 bytes)

Well..  It doesn't say `multi-bodypart' but when you read the RFC that's
what it talks about.

The mechanism is *exactly* as appears above.  There's a single header line
named `Encoding:'.  The contents of the line is a comma separated list
of:

	<line count> <content type description>

The <content type description> is a very short list of names listed in
the RFC, TEXT and HEX being two of them.  (HEX is a very wasteful encoding).

There are many problems with the approach.  But some of us have put it
into products since we were looking for `multi-body-part' before the MIME
working group was ever convened.  For awhile it was one of the few games
in town.  Fortunately MIME came along and has given us a much richer
message structure to play with!

<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- 
<- Where su-b-tlety is taken to an art!