MML 'encoding' tag value ignored...

MML 'encoding' tag value ignored...

[Daniel Pittman]

In trying to work out why a PDF file was being corrupted when sent from
Gnus to several Win32 mailers, I found two things.

Firstly, Gnus was selecting quoted-printable encoding for the PDF file.
This was then incorrectly decoded by both Outlook and Eudora on the
Win32 machine, resulting in a corrupt PDF file.

Specifically, LF => CRLF conversion was happening on the Win32 machine.
Now, I don't know the QP spec well, so I can't tell if this is correct
behaviour for the Win32 machines.

If it is, though, I think that 'application/.*' MIME entities should be
encoded with base64 exclusively, to avoid this sort of problem.


The second, and more serious (IMO) issue is that MML encoding ignores
the 'encoding' tag when encoding the buffer and relies exclusively on
detecting the encoding type.

This is wrong, as far as I can tell, when it comes to the arguments
passed to `mm-encode-buffer' from `mml-generate-mime-1'. The `encoding'
tag is not passed to `mm-encode-buffer' from the part definition.

This means that even if I specified base64 encoding in the MML tag
(as: <#part ... encoding=base64>), quoted-printable was chosen.

        Daniel

-- 
Sadness is but a wall between two gardens.
        -- Kahlil Gibran

Re: MML 'encoding' tag value ignored...

[Toby Speight]

0> In article <87d7c3o54j.fsf@inanna.rimspace.net>,
0> Daniel Pittman <URL:mailto:daniel@rimspace.net> ("Daniel") wrote:

Daniel> In trying to work out why a PDF file was being corrupted when
Daniel> sent from Gnus to several Win32 mailers, I found two things.
Daniel>
Daniel> Firstly, Gnus was selecting quoted-printable encoding for the
Daniel> PDF file.  This was then incorrectly decoded by both Outlook
Daniel> and Eudora on the Win32 machine, resulting in a corrupt PDF
Daniel> file.
Daniel>
Daniel> Specifically, LF => CRLF conversion was happening on the Win32
Daniel> machine.  Now, I don't know the QP spec well, so I can't tell
Daniel> if this is correct behaviour for the Win32 machines.

I think the fix for this is to quote LF and CR in non-text parts:

<LF>     ->  =0A=<CR><LF>
<CR>     ->  =0D=<CR><LF>
<CR><LF> ->  =0D=0A=<CR><LF>


Daniel> If it is, though, I think that 'application/.*' MIME entities
Daniel> should be encoded with base64 exclusively, to avoid this sort
Daniel> of problem.

I thought you could Configure that somehow?

[/me RTFMs]

`mm-content-transfer-encoding-defaults' is what you're looking for,
though it's not defcustom in 5.8.3.

Re: MML 'encoding' tag value ignored...

[Daniel Pittman]

On 28 Feb 2001, Toby Speight wrote:
> 0> In article <87d7c3o54j.fsf@inanna.rimspace.net>,
> 0> Daniel Pittman <URL:mailto:daniel@rimspace.net> ("Daniel") wrote:
> 
> Daniel> In trying to work out why a PDF file was being corrupted when
> Daniel> sent from Gnus to several Win32 mailers, I found two things.
> Daniel>
> Daniel> Firstly, Gnus was selecting quoted-printable encoding for the
> Daniel> PDF file.  This was then incorrectly decoded by both Outlook
> Daniel> and Eudora on the Win32 machine, resulting in a corrupt PDF
> Daniel> file.
> Daniel>
> Daniel> Specifically, LF => CRLF conversion was happening on the Win32
> Daniel> machine.  Now, I don't know the QP spec well, so I can't tell
> Daniel> if this is correct behaviour for the Win32 machines.
> 
> I think the fix for this is to quote LF and CR in non-text parts:
> 
> <LF>     ->  =0A=<CR><LF>
> <CR>     ->  =0D=<CR><LF>
> <CR><LF> ->  =0D=0A=<CR><LF>

Well, if it were possible to ship PDF files as QP without Win32
exploding, that would be great...

> Daniel> If it is, though, I think that 'application/.*' MIME entities
> Daniel> should be encoded with base64 exclusively, to avoid this sort
> Daniel> of problem.
> 
> I thought you could Configure that somehow?
> 
> [/me RTFMs]
> 
> `mm-content-transfer-encoding-defaults' is what you're looking for,
> though it's not defcustom in 5.8.3.

Well, no. `mm-content-transfer-encoding-defaults' now features
`("application/.*" base64)' for me, but that's not the point.

The point is that the MML tag specified an encoding. Explicitly. Because
I put it there.

This, according to the documentation, should override whatever is in
`mm-content-transfer-encoding-defaults' because I, as the user, wanted
something different in this case.

Heck, the code in the MIME composing is even written in an attempt to
make this possible, I think.[1] It's just not _used_ in the code.


Seriously, though, what would you expect this MML tag to encode the
content as?

<#part type="some/type" encoding="base64">

I know that /I/ expected base64, regardless of what the *default*
encoding of MIME objects of "some/type" was. Because I told Gnus what I
wanted.

        Daniel


Footnotes: 
[1]  I didn't quite follow through what was implemented but there is
     *definitely* support in `mm-encode-buffer' for specifying an
     explicit encoding.

-- 
Estne Tibi Forte Magna Feles Fulva Et Planissima?

Re: MML 'encoding' tag value ignored...

[Toby Speight]

0> In article <87n1b6a06p.fsf@inanna.rimspace.net>,
0> Daniel Pittman <URL:mailto:daniel@rimspace.net> ("Daniel") wrote:

Daniel> Well, no. `mm-content-transfer-encoding-defaults' now features
Daniel> `("application/.*" base64)' for me, but that's not the point.
Daniel>
Daniel> The point is that the MML tag specified an encoding.

I didn't intend to address that point - because it's outside of my
expertise.  Can somebody else follow this up, please?