Hi @████████ - it looks like although the 'Total Email Size' can be up to 40MB, the actual total Attachment size can only be 25 MB (combined total of all attachments). Is this correct?

If this is the case - then why is there that limitation on attachments? Why can't the 'Total Email Size' include attachments (allowing say, 2 x 19MB attachments)?

We have a use case where Civil Engineers are uploading PDFs/JPGs (site plan drawings etc) that are regularly very large - and we want to use workflow to send the files to external parties.

Since Direct Share is still not available to Workflow - then their only option is Email Attachments... or having to send them manually if they have over 25 MB combined attachment total.

More control here would be ideal if possible. Even if it required more cost they would likely pay! (as long as it was reasonable).

Hi Duncan,

That's correct and documented in the Process Automation Service Limits.

Email attachments must be MIME-encoded to convert the binary file to a Base64 text representation, a process which makes the encoded file take up around 137% the space of the original. Think "fitting a soccer ball in a square box".

See:

• Amazon SES Sending Limits - Maximum message size (MB) (Laserfiche Cloud uses SES)
• https://www.reddit.com/r/Office365/comments/vm99eh/message_size_set_at_25mb_but_rejects_19mb_from/

Email was originally intended solely for handling text-based messages. MIME encoding makes it possible to send binary files (non-ASCII text files) such as multimedia files, compressed archives, etc. over the Internet.

Almost all modern email clients support the MIME encoding and decoding process. The MIME process takes binary files and converts or encodes them to a plain text format for the trip across the Internet. The MIME process then decodes or reconverts the plain text back into the original binary format once the email reaches its destination.

The result of this process is overhead in terms of file sizes. In general, MIME encoded binary attachments are approximately 137% of the size of the original, pre-encoded file. For example, if you attach a 3MB .zip file to an email, the file will exceeds 4.1MB when it is in transit between servers.

A 25 MB attachment thus uses 34.25 MB of the available 40 MB maximum message size Amazon SES allows (which is hard limit that cannot be raised on request, etc.). After SES raised their max message size limit to 40 MB, we raised ours to (roughly) match.

25 MB is also a common receive-side attachment size limit. The highest we could have possibly made the attachment size limit is about 29 MB, which after encoding would leave a few KB for any text/HTML/CSS/images/etc., Allowing that extra 4 MB in attachments would almost certainly result in an increase in send-side failures due to max message size constraints as well as an increase in receive-side failures from being over the common 25 MB default.

Two 19 MB attachments would be 52 MB after encoding.

Even if we could give you account-level control over the attachment size max (which we can't at the moment), I'm guessing bumping it up another 3-4 MB to the hard technical limit wouldn't meaningfully make a difference for your use case.

As you noted, a Direct Share activity for Cloud Workflow is likely the "right" solution for it. I don't know the current status of or plans for that though.

Since Direct Share is still not available to Workflow - then their only option is Email Attachments... or having to send them manually if they have over 25 MB combined attachment total.

Wish I had an immediate solution for you here, but hopefully this response at least helps you understand the technical aspects of the email limits we're working with.