I am using an Email Handler for inbound emails and we are wanting to do some tracking on the size of incoming emails. We will eventually be putting some limits on max attachment sizes that we want to accept, but are looking for a way to baseline the current trends.

Looking at this article, it states:

Note: The maximum size of the inbound email must not exceed 35MB which includes the Email Body, Headers, and Attachments together, otherwise the email will not be processed.

With the understanding that only emails less than 35MB will even reach the handler without being stopped at the Salesforce MTA, I am looking for a way to come up with a rough calculation of the attachments + headers + content in terms of byte size to determine the average we are seeing today.

My goal is to be able to get two numbers from this. The average size of an incoming email in its entirety, and the average size of just the attachments.

Looking at the class that the handler is extending, I don't see any methods that already provide such calculation, so I'm looking for a way to accomplish that.

Any suggestions on getting such a calculation using APEX?


For the attachments, this seems to provide a very close number with the additional increase that comes from the encoding of the attachments:

Input (files attached to email): test.html = 582 B, test.csv = 190 kb

Output (calculated total of attachments): 195614 / 1000 = 195.61 kb

// Binary attachments
if (email.binaryAttachments != null && email.binaryAttachments.size() > 0) {
        for (Messaging.Inboundemail.BinaryAttachment bAttachment : email.binaryAttachments) {
            attachmentSize += bAttachment.body.size();
// Text attachments
if (email.textAttachments != null && email.textAttachments.size() > 0) {
        for (Messaging.Inboundemail.TextAttachment tAttachment : email.textAttachments) {
            attachmentSize += tAttachment.body.length();

For the total, I believe would need to calculate the size of the body + headers and add it to this number. Anything else I need to consider?

1 Answer 1


SMTP is a protocol, and as such, it uses particular encodings to represent certain types of data. The main body is usually "quoted-printable" 7-bit encoding, where some bytes that would break the protocol are encoded as =XX, where XX is a hexadecimal number encoding.

UTF-8 characters outside of 0-127, as well as certain control characters, like Carriage Return and New Line, are encoded to prevent the protocol from breaking. Emails that aren't in English or Spanish (and other "Latin" languages), for example, are likely to be far bigger than those that can fit in the ASCII table.

Further, attachments may be in Base64 format, again to avoid breaking the protocol, and might actually therefore be 33% larger (4:3 input:output bytes), so you may find that you can't really accept emails larger than perhaps 26MB or so.

As an additional complication, I see your calculation suggests that you have 195KB from an original 190KB file. This is likely a confusion between KB and KiB. In computing, we have decimal- and binary-based number formats. Historically, KB, MB, etc were binary-based, but after ISO 80000, KB, MB, etc became decimal-based, and KiB, MiB, etc were the new binary-based numbers.

Microsoft Windows shows KB, as it always has, but these are really KiB per the standards. The difference is that a KB is 103 bytes, but a KiB is 210 bytes. This means that a "190KB" file in Windows is at least 190 times 1,024 bytes in size (199,680 > file size >= 198,656 bytes); your input of 195,614 bytes suggests Windows should actually report this file as 191KB (specifically, it calculates out to 191.02929KiB).

Note that Salesforce documentation appears to always use ISO 80000 standards, meaning that when it says 35 MB, it means 35 times 106 bytes, and not 35 times 220 bytes. If you're comparing a file in Windows to what Salesforce will see, be aware that you're comparing KB to KiB, or "apples to oranges."

Also, as far as I'm aware, Salesforce counts the bytes in the header against the 35 MB limit as well. This means you'll need to also need to calculate the headers as well. Even then, there are some "hidden" bytes, so you won't be able to get a completely accurate count of the bytes.

All that said, this should be a "close enough" estimate of the sizes involved. Just remember that the files on your OS will appear to be "smaller" than they will appear to be in Salesforce, unless you account for the KB/KiB difference.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .