Emails are made up of a header and body, the body may be HTML or plain text, and any attachments are encoded within the body of the email for it to be sent. We have applied limits to our email infrastructure to reduce load, bandwidth, and disk space but also to protect recipients of our emails from very large emails (with attachments) that we might send and standardise what we (i.e. users) are able to send and recieve across all the email components, i.e. the Mailbox Servers, Mail Relay Servers and Mail Hygiene solution.
Microsoft provides a good summary of the effects of encoding on email size in this article Message size limits in Exchange Server, however other mail relay software will do similar things and the size changes due to encoding can be different across many platforms, so you need to be aware that although you might have created an email with a seeming below limit attachment(s), during the various encodings that occur during transmission (or unzipping in the case of mail anti-virus/malware filtering by the mail hygiene solution) it may exceed a total email size limit at any of these steps causing rejection of the message. So for example a limit of 60MB may mean that an email message of 20MB could be rejected if the message contains an attachment that is zipped and is over 60MB when expanded (by the mail hygiene solution), also an email message of 45MB which is subject to a size increase due to the encoding changes during delivery could exceed 60MB even though it is seemingly below the limit, the actual effect on size differs from mail to mail and system to system. Also be aware that on Microsoft Exchange an individual’s mailbox could have limits on sending and receiving of messages explicitly set, see Recipients → Mailboxes → Username → Mailbox Features → Message Size Restrictions, this is normally not set so each mailbox inherits the maximum sizes from the Exchange organisation instead.
Example Problematic Email
The below email headers show an example email that has not been able to be delivered, as you can see the message has been bounced back, reading into the text you can see the various parts that indicate why this has occurred.
If you review the email headers, there are these key bits of information:
Final-Recipient: rfc822;bob@domain.com
Action: failed
Status: 5.2.0
Diagnostic-Code: smtp;554 5.2.0 STOREDRV.Deliver.Exception:MessageSubmissionExceededException.MapiExceptionMaxSubmissionExceeded; Failed to process message due to a permanent exception with message Cannot complete delivery-time processing.and additionally this:
X-MS-Exchange-Organization-OriginalSize: 45843038In this example email the (original) size is: 45843038 bytes (45.84 megabytes), so at first glance this should be able to be received by the Exchange email infrastructure (for example) if the Receive Connector limit was 60MB. The exact implication of this X-MS-Exchange-Organization-OriginalSize value is described in Message size limits in Exchange Server which says:
hole message size limits: Specifies the maximum size of a message, which includes the message header, the message body, and any attachments. Exchange uses the custom X-MS-Exchange-Organization-OriginalSize: message header to record the original size of the message as it enters the Exchange organization. Whenever the message size is checked, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and transport agent processing.
For any message size limit, you need to set a value that's larger than the actual size you want enforced. This accounts for the Base64 encoding of attachments and other binary data. Base64 encoding increases the size of the message by approximately 33%, so the value you specify should be approximately 33% larger than the actual message size you want enforced. For example, if you specify a maximum message size value of 64 MB, you can expect a realistic maximum message size of approximately 48 MB.As a quick aside let’s Base64 encode this text: “The quick brown fox jumped over the lazy dog.”, in Base64 its: VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu. So going from 45 characters to 109, so you can see the affect.
Explanation
The explanation can go into nauseating detail about how different types of data is encoded and transferred, but the explanation below intends to shorten this as much as possible.
The MIME encoding can take place on any email, but if the email contains only text, the increase is very small (if anything), where only non-standard characters may require encoding to take place, either way the impact to overall size is tiny, but if there is a large binary attachment, the impact can be significant.
So let’s say we have a plain text email message with a 45.84MB attachment (such as the example above), which we are sending out to a recipient on the Internet. Now Microsoft Exchange supports the SMTP 8BITMIME SMTP Extension RFC 6152 so it can use 8-bit encoding for the transmission of data, so essentially there is no conversion needed, for an Exchange server to send to another Exchange server. However when sending outside of the Microsoft Exchange organisation typically only 7-bit encoding is available, hence the use of MIME to allow binary to be converted to a text string (email can only contain text) that can be safely transmitted via email servers.
What this means is the actual length of MIME-compliant Base64 encoded binary data is about 137% of the original length, very roughly encoded binary data is equal to 1.37 times the original data size + 814 bytes (for the headers) so we get equation as below. The first shows the size in bytes of our example email after being converted from 8-bit encoding into base64 MIME encoding for transmissions to a recipient on the Internet.
Original Message Size: 45843038 bytes (45.84MB)
(original size in bytes + 814) * 1.37 = MIME base64 encoded size in bytes
(45843038 + 814) * 1.37 = 62806077 bytes
Encoded Message Size: 62806077 bytes (62.8MB)So as we can see it is over the 60MB limit, hence it was rejected.
So what about a message that is being received by the Microsoft Exchange organisation (infrastructure), well it appears that if the above example was reversed, the message is received by the Microsoft Exchange receive connector, even though the original message size is less than 60MB (45.84MB in this case), at the point of receiving it is over 60MB so is rejected, i.e. its not received, accepted, converted to see if it’s okay and then delivered to the Microsoft Exchange organisation, it’s just rejected as being over the limit, essentially this means that even if the message limit is 60MB it is in fact less than this for MIME encoded messages.
Conclusion
So the takeaway is that the configured 60MB is not the actual limit, in reality is less than this (after encoding overheads), so about 44MB or thereabouts, if we wanted a “real” limit of 60MB emails, we’d need to set the configured email limits to around: 82.2MB to cope with the encoding overheads (citation).
Additional Information
- https://social.technet.microsoft.com/Forums/lync/en-US/ba5d45f0-b34e-44d1-a34f-9d49389bbd58/actual-delivered-message-size-varies-between-two-different-exchange-forests?forum=exchangesvrsecuremessaging
- https://docs.microsoft.com/en-us/exchange/content-conversion-tracing-exchange-2013-help?redirectedfrom=MSDN
- https://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding
