You don't have to know the transfer encoding when parsing the header.
According to 822,

	Each header field can be viewed as a single, logical  line  of
	ASCII  characters,  comprising  a field-name and a field-body.

Of course 821 states

	The maximum total length of a text line including the
	<CRLF> is 1000 characters (but not counting the leading
	dot duplicated for transparency).

To stay consistent with these, headers need to be in the
7bit domain.  However, rfc2047 provides the amazing
=?b?gobbledeygook?= syntax to allow non ascii tokens in the
header.

Therefore, the 'Content-Transfer-Encoding: {78}bit' header field
isn't telling you anything per se about the header since the
headers are predefined to be US-ASCII with the =???=
encoding providing an escape in case you want what's there
to be convertible to non-ASCII.

When upas/marshal says that a message (or message portion)
is either 7 or 8 bit, it's just stating a fact.  However, if
smtp sees an 8bit message and doesn't get an esmtp connection
to the remote host, it should encode the message (or message
part) in base64 (or quoted printable).

We either have to bite the bullet and encode all 8-bit data
presented to marshal OR change smtp to do the recoding OR
both.  However, if we're also willing to relay messages (which
I do) than the marshal change is insufficient since mail may
pass through us from an 8bit to a 7bit channel without passing
marshal.

Therefore, I'm going to make smtp (or a front end to it)
convert and you can all stop your whining.

However, I'm still perplexed as to what to put in the header
of a multipart message.  Does the transfer encoding specified
there pertain to the whole message or just to the

	nyah nyah, if you only had a MIME mailer you wouldn't see this

message that starts every multipart message?