Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Mail size increasing with attched file

  • 8 பதிலளிப்புகள்
  • 1 இந்த பிரச்சனை உள்ளது
  • 13 views
  • Last reply by Onno Ekker

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?

All Replies (8)

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%.

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.

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. :)

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.

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.

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?

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.

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.