410758 - [RFE] Support more efficient encodings for attachments

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, enhancement)

Description

[Carlo Alberto Ferraris]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 

Adding support for other encoding methods (7bit, 8bit, binary) for specifiable domains would save me a lot of time when sending large attachments (not talking about sending time, rather about composing time, i.e. the time needed to compose many different messages with the various chunks of the attachment).

Reproducible: Always

Comment 1

[Magnus Melin [:mkmelin]]

mail.file_attach_binary forces base64 (if that helps you)

Comment 2

[Carlo Alberto Ferraris]

The above pref was false (default). Changing it to true does not resolve. Attacchments for binary files (I just tryed with a pdf and a random binary file that tb didn't recognize -> octet-stream) are still sent base64-encoded.

Comment 3

[Vincent (caméléon)]

Carlo, 
Sorry,I'm not sure to understand you. Are you complaining about the fact that with the actual encoding, the size of a binary file is increased by about a third when you send it as an attachment (due to the base64 encoding)?

Source: http://kb.mozillazine.org/Can_not_send_large_attachments

If yes, I will vote for this bug.

Comment 4

[Carlo Alberto Ferraris]

Yes, that's the point.

Comment 5

[jouan.y]

Hello,

I agree with you, caméléon.

Regards

Comment 6

[rsx11m]

(In reply to comment #2)
> Attacchments for binary files (I just tryed with a pdf and a random binary file
> that tb didn't recognize -> octet-stream) are still sent base64-encoded.

Unless RFC 2045 has been obsoleted by an update (couldn't find one), this is the correct behavior for binary data:

Quoting from http://tools.ietf.org/html/rfc2045#section-6.2 ...
>    There is a tradeoff between the desire for a compact and
>    efficient encoding of largely- binary data and the desire for a
>    somewhat readable encoding of data that is mostly, but not entirely,
>    7bit.  For this reason, at least two encoding mechanisms are
>    necessary: a more or less readable encoding (quoted-printable) and a
>    "dense" or "uniform" encoding (base64). [...] Thus there are no
>    circumstances in which the "binary" Content-Transfer-Encoding is
>    actually valid in Internet mail.

This concludes with a statement that "binary" may be possible in the future.

Thus, which other more efficient encodings are you suggesting? For other than 7-bit or 8-bit (optionally quoted-printable encoded) textual data, base64 is the only other content-transfer-encoding which can be used in accordance with the standard (uuencode has been depreciated even though supported by Tb on the receiving/decoding end).

Comment 7

[rsx11m]

So, what's the point of this bug? From my point of view this is invalid, given that Thunderbird is behaving in accordance with the standard. Could one of the proponents be a bit more specific what this is aiming for, and how this would be in compliance with any applicable RFCs?

Comment 8

[rsx11m]

Unless further information and references to standards are provided here I'd suggest to close this as either invalid or incomplete.

Comment 9

[[:Aureliano Buendía]]

Closing Incomplete for lack of answers at 2009-07-09. 

Feel free to reopen if you can provide more information.