On Wed, 28 May 1997 18:08:31 +0300 (EET DST), era eriksson
On Wed, 28 May 1997 10:46:11 -0400,
Roderick Schertler <roderick(_at_)argon(_dot_)org> wrote:
For a recent project I needed to decode whatever standard MIME
encoding the body was in, including this file does that.
The potential problem is that it won't take care of multipart messages,
What do you mean? Multipart messages cannot have an encoding (other
than 7bit, 8bit or binary) (ref section 6.4 of RFC 2045), so they're
handled just fine.
If you mean that this script won't decode the encoded parts of a multipart
message, of course not! That's not what it was designed to do. It was
designed to undo a decoding applied to the entire body. You might as well
point out that a dish washing machine doesn't wash clothes well.
This is fine for a simple decoder and a demonstration of how to do
nifty things in Procmail, but you should probably revert to a full
MIME decoder app if you want robustness.
Robustness is probably my most important design goal, so if I've fallen
short I'd appreciate it being pointed out.
My program checks the Content-Type, if it's not an allowed type the
message is bounced to a human (who will castigate the person who wrote
the program which sent it, this is part of an automatic data processing
setup so the remote end has to follow the spec).
mime_decode_encoding = `formail -zx Content-Transfer-Encoding`
This could probably be pared down to
* ^Content-transfer-encoding:[ ]*\/.*
mime_decode_encoding = $MATCH
There are two problems with yours: It doesn't allow spaces before the
colon (easily fixed), and it includes trailing space in $MATCH (which is
why I used formail, I can't spot a way to strip the trailing space but
otherwise capture the entire value without using an external process).