One must wonder: if you WANT these messages, and the absence of a
plaintext
part is a problem, why not upgrade to an MUA that can handle it -- OR, if
your MUA can't, why is just rewriting it to plaintext a problem?
If a user can't get around receiving and reading HTML, there is one
potential
advantage to creating a multipart alternative with the first part as text:
it makes it easier to run naiive spam filters (via grep, procmail rules,
etc),
because they can key off the text in text part of the MIME-encoded
attachment.
Along those lines, it would be helpful mimedecode text and html parts that
are either that are Content-Type: text/* and were base64 encoded in order
to obfuscate the text. I was wondering in fact, if the recipe at,
http://www.xent.com/pipermail/fork/2002-June/012749.html
[Excerpt follows]
# Message is text/html with no multipart mixed, related, or
# alternative. Process body with lynx -dump.
:0wb
* ^Content-Type: text/html.*
| lynx -dump -force_html -stdin | \
mutt $MAILLIST -s "${SUBJ_}"
would in fact handle Content-Transfer-Encoding: base64? I think not.
There needs to be another step there, possibly invoking
munpack, and then picking up the extracted html part and feeding
that into lynx. However, if the structure of the MIME encoded attachment
is complicated (say, multipart with an html part, and couple image
parts), it seems like this all gets to be rather tricky.
Of course, once the mail has been munged in this way, some of the
markers that a spam filter program like Spamassassin use to detect
spam have been removed. The good news (if it can be considered to
be good) is that the body (or the MIME text part) of the message
can be read as plain text.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail