[RFE] Support more efficient encodings for attachments



11 years ago
10 years ago


(Reporter: bugzilla, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: closeme 2009-07-09)



11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv: Gecko/20071127 Firefox/
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
mail.file_attach_binary forces base64 (if that helps you)

Comment 2

11 years ago
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.
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

11 years ago
Yes, that's the point.

Comment 5

11 years ago

I agree with you, caméléon.


Comment 6

10 years ago
(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

10 years ago
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

10 years ago
Unless further information and references to standards are provided here I'd suggest to close this as either invalid or incomplete.
Whiteboard: closeme 2009-07-09
Closing Incomplete for lack of answers at 2009-07-09. 

Feel free to reopen if you can provide more information.
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.