Udi Mottelo wrote:
On Tue, 13 Aug 2002, Bart Schaefer wrote:
On Tue, 13 Aug 2002, Udi Mottelo wrote:
Unfortunately metamail doesn't know the Content type
"multipart/alternative" you can miss some files.
Metamail knows multipart/alternative -- but it interprets it according to
the MIME spec, which says that when given alternatives you select exactly
one of them (the "best" one based on the test criteria in mailcap).
Unfortunately I don't recall the RFCs saying anything about mailcap; maybe
you could cite a reference? What they do infer is that the "most preferred"
format is the last one presented in the body. Yes, what I am saying is that
according to my interpretation, if a text/html part precedes a text/plain
part, then the text/plain part is "preferred"! Not that mail clients
necessarily agree with me in practice.
The RFCs seldom make or intend things to be more complicated than they need
to be; always apply Occam's Razor.
So metamail will never process more than one of the parts in a m/a. If
you want to forcibly examine the rest of the parts, you need a different
tool, or a hack like rewriting the content-type to m/mixed.
Thanks Bert, when David Tamkin tald me about I deleted the m/a
lines as first-aid than I thought it is too brutal and I change
it to mixed. From your explain I understand that delete was ok.
If you delete the Content-Type: multipart/.* header then what should happen
in the absence of other header defects (and in all cases where 2 == 2, for
most values of 2) is that the body is treated as a "standard" 822/823 body.
Some mail clients are "smarter" than that however and just have to try to
be helpful; there are mails which are crafted to exploit that. This may
also explain the single-part multi-part messages; or, those could be an
attempt to circumvent certain filters which don't look at certain MIME
parts, only at integral message bodies... or maybe which crash... if there
are any of those still around. (I think that every one of those I get turns
out to be spam, except for the ones which end up that way after PerlJacket
strips a part.)
I vote for rewriting both multipart/alternative *and* multipart/parallel
(don't forget that one!) as multipart/mixed... that is if we're all talking
about the same thing.
procmail mailing list