搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Mail size increasing with attched file

  • 8 个回答
  • 1 人有此问题
  • 5 次查看
  • 最后回复者为 Onno Ekker

more options

Hello,

I have a issue with Thunderbird 52.2.1. When I add an attachment to the e-mail I`m creating (It does not metter whether it is a *.pdf file, *.zip file, *.rar file etc.) the size of the email is much bigger. For example: when I add 16,6MB *.pdf file, after sending an email, Thunderbird shows me that mail size is 23,2 MB (40% bigger).

In another thread I read that "sending a binary file as a attachment increases its size by a third due to base64 encoding sending two 8-bit characters as three 7-bit ASCII characters."

Is there a chance to correct this?

Hello, I have a issue with Thunderbird 52.2.1. When I add an attachment to the e-mail I`m creating (It does not metter whether it is a *.pdf file, *.zip file, *.rar file etc.) the size of the email is much bigger. For example: when I add 16,6MB *.pdf file, after sending an email, Thunderbird shows me that mail size is 23,2 MB (40% bigger). In another thread I read that "sending a binary file as a attachment increases its size by a third due to base64 encoding sending two 8-bit characters as three 7-bit ASCII characters." Is there a chance to correct this?

所有回复 (8)

more options

I think this is the case with all email programs: encoding overhead adds 33% to the message size. If you're reaching the maximum message size allowed by your mail service, or wish to utilize resources more efficiently, e.g. sending a large file at different times, it's better to upload the file to a file hosting site and send the download link by email.

The extension of yEnc to email would decrease the overhead to 1-2%.

more options

While it is possible to send attachments using 8-bit characters (by using the yEnc add-on), it is not recommended, because not all servers support this. As you never know which route a sent message takes from the sender to the recipient, you also cannot guarantee that the message doesn't pass such a mail server on the way, so the attachment might turn up unreadable at the other end.

more options

This topic is very interesting because recently I did a test with Microsoft Outlook 2010 and in the case of this program, problem does not exist. While Outlook uses rounds to display the size of the attachment, the entire email is not incremented. I do not know what the situation is for other programs - I am switching between Thunderbird and Outlook 2010.

So, either I do a bad test, or so it was designed. :)

more options

Try this test: send yourself a message, with attachments, from Outlook and TB, and receive the message with TB. Compare the size of the two messages by displaying the Size column. Any difference? I would be surprised if there were.

more options

I did a test and two different sizes came out. Test procedure:

  1. Sending an e-mail with attachment from Outlook to the account it's attached to, and a copy to the second account in TB. The attachment is 2.34 MB. Outlook reports 2 MB and TB is 3.3 MB.
  2. Sending an e-mail with attachment from TB to the account it's attached to, and a copy to the second account in Outlook. Same attachment as above. TB reports 4,2 MB, a Outlook 3 MB.

The most interesting thing is that the difference is basically the same in both cases but to the disadvantage of TB.

more options

re :Sending an e-mail with attachment from Outlook...The attachment is 2.34 MB. Outlook reports 2 MB.

Are you saying that Outlook is saying the email plus attachment is smaller than the attachment itself?

more options

It seems to me that Outlook uses rounding to the whole (2,34 MB after rounding it will give us 2 MB) and hence a "weird" difference. At least i think so.

more options

Looks to me like Outlook is displaying the size of the decoded attachment (the space it would occupy on your hard disk) and Thunderbird displays the size of the encode attachment (how much space it actually uses in your mail folder). There's nothing wrong with that, so it doesn't need to be corrected, but you might file a bug to request for an enhancement to also see the decoded attachment size.