:0
* ^Content-Type: multipart/alternative
However, I believe that there is a problem with this pattern. You assume
that such messages only consist of the two alternative parts (plain text
and HTML). Some people send attachments as well as alternative parts! So
your pattern, which is implicitly constrained to the message header, would
skip those.
I think, note think, that the fix is to match the above within the body.
I actually was not looking (initially) to deal with anything other than people
who use AOL or MS Outlook (Express) who send HTML formatted email which should
have been plain text....
So I wasn't looking to deal with attachments.
(It is important to remember that in my narrow scope I am looking to forward _a
copy_ of the text of the message to a cell phone. An un-altered version of the
email goes to my INBOX.)
So my pattern matching looked for the header line and then (if found) looks for
either AOL or MS Outlook signals.
Now, it may be entirely possible to expand this to deal with attachments and
whatnot, but that wasn't the original intent, so our goals may not have been the
same.
I greped such a message, which I saved for tasting my own recipe, to show
the mix of Content-type lines that do occur. And as can be seen from the
last part it would be dangerous to excise a none iso-8859-1 part.
Yes I was matching Content-Transfer-Encoding where I probably should have been
matching 'Content-Type: text/plain' and then grep out the
'Content-Transfer-Encoding' part.
I'm also a little suspicious of your sed directives to remove MIME-encoded
characters. Would it not be better to fed the retained part through
mimencode so all those quoted characters are converted?
Probably... but I've only seen a few of them, and I was already calling 'sed' so
it was less of an impact to add another pattern there.
Your recipe was helpful in getting me started, especially as I'd not
considered that there might be a difference between AOL-generated mail and
Microsoft-generated mail. I certainly need to add more beef to my recipe.
Yeah the boundary was different. Heaven forbid that anything wrt MIME be too
standardized.
If I were in charge of it, it would have been done much differently to allow for
easier parsing. I think they allowed for too much flexibility in how things are
sent.
TjL
ps -- I'd like to see what you come up with, and will be happy to share my
revisions as well.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail