[lots of interesting stuff about MIME's place in Squeak]
I'm trying to merge everything that's been said that clicks for me, how
does this sound to you all -
A class called MIMEContent represents MIME formatted data (thus - it
holds arbitrary header fields). To support MIME-nested content, it is a
Composite. To support content-type sensitive behavior (one or more
conversions to representative morphs, an action menu...) it will
delegate to an appropriate Strategy object. Because parsing isn't free
(for possibly large, complex instances), all analysis will be done
lazily (as now).

What other net protocols use the MIME format? I'm woefully ignorant in
this...
Anyway, MailMessage, NewsMessage, ProtocolXTransmission and friends
might have different roles and functionality depending on their
application. So we might profit from concentrating the MIME
functionality in neutral territory, despite mail being the senior user
;-)

About conversion - no conversion is effortless, and almost none are
really reversible. Again I'm in favor of laziness - the string is a
comfortable representation for MIMEContent until a client requests
something else, and then we can convert...

About the missing -- (separator suffix) bug -
I'm slightly shamed to say that was pure sloppiness - I knew that detail
but assumed MIME parser couldn't seriously care past the last part (ours
doesn't... <g>). Well, seeing as I got caught, I'll have to correct
that.