Re: Is QP bad for binary files?

[Daniel Pittman <daniel@rimspace.net>]

On Thu, 12 Jul 2001, Kai Großjohann wrote:
> Suppose I send a binary file as an attachment, and it is encoded in
> quoted-printable rather than base64.  I'm thinking maybe strange
> things might happen to line endings in that file.  For if I send it
> from a Unix system to a Windows system, \n can become \r\n on the way.
> 
> Does this really happen?  Can it really happen?

Yes, it really happens. No, it shouldn't happen.

The problem is that the authors of every major Win32 mail client *know*
that Quoted-Printable is *always* text, never anything else.

They know this so well, in fact, that they ignore the `application/'
part of the MIME type[1] as well as the fact that Gnus has encoded it
such that the line endings are encoded in QP and the raw line endings
are elided[2].

They then convert it to the local line ending type, in a variety of
stupid ways[3], with no notice to the user.

Then, finally, they pass the broken result off to the application to
display which, unsurprising as this may be, complains that it's binary
data[4] has been corrupted and fails.

Unless, of course, it's Abode Acrobat, which simply displays an empty
page because we all know that error messages scare the user -- and it's
better to silently fail than scare the user.[5]

> If this really happens, then I think this would be a good reason to
> refrain from using QP for binary files.  Gnus fairly often uses QP for
> PDF files.

This breaks the legs of that particular problem for me -- I have not
seen an issue with it since:

,----[ .gnus.el excerpt ]
| ;; Force application/* to be sent base64; QP vs Win32 breaks things
| (require 'mm-encode)
| (setq mm-content-transfer-encoding-defaults
|       (append (remassoc "application/.*"
| 			(remassoc ".*" mm-content-transfer-encoding-defaults))
| 	      '(("application/.*" base64)
| 		(".*" qp-or-base64))))
`----

        Daniel

Footnotes: 
[1]  Which specifies that this is binary data, not text, and that you
     better not modify it or you will suffer (and break it) according to
     the MIME RFC set.

[2]  This is not only legal but the *required* behavior according to the
     QP specification, in it's RFC, which explicitly states that this is
     the way to transport line endings without mangling.

[3]  Including adding a <CR> to every <LF> even if there was already one
     there in at least one case.

[4]  No matter how much it really was text, because we all know PDF
     isn't PostScript, honest.[5]

[5]  Yes, I am bitter. Why do you ask?

-- 
You want to be famous and rich and happy, but you're terrified you have
nothing to offer this world. Nothing to say and no way to say it, but you can
say it in three languages.
        -- KMFDF, _Dogma_