On Fri, 28 Feb 2003 01:13:41 EST, John Lyon <[log in to unmask]>  said:

> Good ol' MS :-)  Any message with an attachment should be:
> Content-type: Multipart/Mixed  Then other types and subtypes
> are nested below that. Including the attachment itself and
> mutipart/alternatives, if the message body wasn't plain text :-)

Not strictly true.  multipart/mixed is the "default" if you need to drop
back because your MUA doesn't support a particular multipart/*, but it's
quite plausible for a message to be a multipart/(not-mixed) and still
have an attachment.  Consider this message - it's multipart/signed and has
an attachment (the PGP signature..).  The other multipart/* forms specify
additional semantics relating the bodyparts, which can be used by an MUA
which understands the semantics (and subtype), but if your MUA doesn't
handle the subtype, it uses the multipart/mixed semantics.

A *partial* list of multiparts:  mixed, alternative, digest, parallel, signed,
encrypted, related, report, form-data.

Also note that RFC2046, section 5.1.1 makes mention of using multipart/*
with a *single* bodypart - this is legal and sometimes even a good idea
(for instance, by passing all the Content-type and Content-Transfer-Encoding
and similar headers in the message body, it makes it possible to get a
non-binary file through Listserv even if 'shorthdr' is in effect).

>> A related question:  Does Listserv recognize the * in
>> application/*msword as a wildcard?  If not, what is the purpose of the
>> asterisk?

> Yes, but I don't know why one is used/needed.

Quite often, support for a new format will start off using the x- convention,
and then drop it once an RFC comes out specifying it.  The * is so that
(for instance) application/*foobar will catch both newer application/foobar
and older clients still generating application/x-foobar.

--
                                Valdis Kletnieks
                                Computer Systems Senior Engineer
                                Virginia Tech