< From: jgm+(_at_)CMU(_dot_)EDU (John Gardiner Myers),
< That is because the heuristic is to use the choice of quoted-printable vs.
< base64 to intuit whether or not the object is textual. Few textual
< non-text/* objects are encoded in base64. All text/* objects are by the
< spec textual.
Unfortunately, this gives the totally wrong answer for non-text/* objects
encoded in quoted-printable!
Yes, all text/* objects are by the spec textual. And non-text/* objects may
be either textual or non-textual. And both base64 and quoted-printable may
be used with both text/* objects and non-text/* objects. But the use of
base64 vs. quoted-printable in non-text/* objects does not imply whether the
underlying object is textual or not.
What started this thread was a complaint from a customer who was using
munpack to decode a message with a non-text/* body part which was mostly
ascii, but definitely not textual. Since quoted-printable made complete
sense for encoding that body part (5% increase in encoded size instead of
33% increase), the body part had been encoded using quoted-printable.
Unfortunately, munpack was stripping out the =0D-encoded CR's when the body
part was decoded; that is, the decoded body part was ruined.
I then asked this group who was right: munpack or the software which encoded
the body part with quoted-printable. The consensus is that the q-p software
is right and munpack is wrong.
We've had to advise the customer to stop using munpack because of this. (We
may even have to put out a general customer advisory on this issue.)
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
http://ourworld.compuserve.com/homepages/Tony_Hansen