Re: questions on QP, non-text attachments and munpack

[[e-mail]]

< From: [e-mail] (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
			  [e-mail], [e-mail]
		    http://ourworld.compuserve.com/homepages/Tony_Hansen