[SOLVED] Maximum message size

[czaveri]

You may not be dealing with a bug at all, Ken. Remember that when a binary attachment is sent by email it is first encoded into ASCII using either MIME or UUENCODE. Either results in fairly substantial inflation in message size, as explained in this article.

Let's look at your specific example. You have a file that you tell us is 8,987 KB. Multiply that by 1,024 bytes per KB and you have 9,202,688 bytes. Now give that a 30% encoding overhead (the article I referenced says 30-40%) and you're up to 11,963,494 bytes. Sticking with kilobytes, though, since that's how the Zimbra system takes its settings, 8,987 kb times 30% inflation would be 11,683 KB, again over your stated limits.

Let's do a real-world test. I have a message in my inbox that is reported by Zimbra as 10,544 KB. It's got only two lines of text, and a PDF attachment. When I save that attachment to my desktop and check its size with Windows, the resultant file is only 7.47 MB (7,835,426 bytes).

Bottom line--file size and message size should not be confused. If you really want to limit your users to 10MB attachments, you probably need to limit the message size to more like 13 or 14 MB to allow that file size to come through. This is not a bug, it's how encoding of binary attachments works.

What you say makes sense. The user reporting this issue hasn't replied so will repro this, this Monday, and check the behavior.

Thanks for pointing to the article.

[phoenix]

We know that this is the behaviour (don't we?) and the upload size depends on how the file is encoded, it's been covered a few times in the forums.

[mmorse]

I'll make notes to have the duplicates (bullets) closed (or someone can just do it) but for those who want to know what the differences are:

Web-Client:
To make the generic error message better:
Bug 19210 - Incorrect error message while sending message of size exceeding than set in MTA

• Bug 13566 - Sending attachment of size greater than that defined in MTA gives "mail.SEND_FAILURE" error
• Bug 16225 - Discrepancy between zimbraFileUploadMaxSize and the actual upload size

Bug 16128 - Attachment upload limit has to be displayed

ZCO:
Bug 16974 - Error message too vague when exceeding message size
Bug 16630 - Enforce maxUploadSize and maxMessageSize locally


This might need to stand alone:
Bug 6758 - When sending a message that exceeds the max message size, include the 'allowable size limit' in the error message

Server-
Bug 16621 - controlling message size and file upload per user or a group of users
Bug 20615 - zimbraFileUploadMaxSize and zimbraMtaMaxMessageSize should be COS settings
Bug 6635 - per user/COS message size limit

[czaveri]

We know that this is the behaviour (don't we?) and the upload size depends on how the file is encoded, it's been covered a few times in the forums.

Yes, we do.

The issue with the user who reported this earlier was that with 20 MB of zimbraFileUploadMaxSize and zimbraMtaMaxMessageSize, he could upload only about 10 MB. This is a huge difference (much >30-40%) and I was wondering if there is something else, other than how the file is encoded, that's doing this.

I tried to get in touch with him to find out more about how his system was configured but did not get a response.

I also tried reproducing this in the past but did not succeed and noticed a standard deviation of around 25-40% with the compressed archives; not more.

[mmorse]

So technically, after all my digging above, the best way to cut down on future threads, bugs, & support tickets is to file another RFE
lol-to that one dan!

Something like-
Title: Warning in admin console when zimbraFileUploadMaxSize greater than zimbraMtaMaxMessageSize
Body: This should NOT prevent setting any value greater than the other. There's still attachments in other locations to consider; and someone may not care how big files from local to server are, but will care about size when sending to other email servers. The warning should be like:

For sending emails attachments FileUploadMax should generally be less than MtaMax. We also recommend that you set FileUploadMax at least 10% larger than expected due to format conversion of emails. You will need to set MtaMax larger of course to allow emails with multiple large attachments of size 'FileUpoad'. Though you can choose to ignore this warning if you wish; as FileUploadMax value is also used in other attachment locations like cals, docs, tasks, briefcase, etc.

Sound agreeable to all here?

---

The different values for each app discussion that I often see & other's reading this may go 'why not separate values for each app?'

1. Take for example Bug 19515 - Separate Max File Size for Briefcase (which soxfan and I really intended to be used with Bug 19516 - Ability to segregate Briefcase storage from regular mail storage) but the MtaMaxMessageSize really takes care of the concerns in that separate max briefcase file size RFE.
2. Instead, it would be better if when you were about to send that briefcase file it in an email it would notifiy you that it excedes the MtaMax.
3. If we're going to have a lot of 'save to/from briefcase features' and there was separate values for each app, you'll just end up in a situation where there's an attachment in a briefcase that you want to move to a task (or vice versa) and can't. Unless a lot of warnings and checks are built in.
4. Unless they're size limits shown in the web-client, which isn't done right now for anything really, who wants to give their user's a list of file sizes you can upload/move to each section?
5. Have you & users remember that there's more than 2 (or 3) limits when going about their normal usage of the web-client isn't ideal.
6. And most importantly the idea is to keep-it-simple

[dwmtractor]

All good suggestions, guys, though Mike's minimum of 10% greater message size than file size will, in my experience, rarely if ever be enough. I'd go 30% and still expect barriers.

Perhaps a really clear error message (probably as a bounced email with the original message attached?) would clarify the issue. Something like:

I'm sorry, but your message exceeds the maximum message size of XX MB. Although your attached file(s) were only a total of YY MB in size, email technology frequently results in expansion of the file size. Please downsize your attachment or split your files across multiple messages to send. If you need further assistance please contact your administrator.

I know it's verbose, but it would at least be comprehensible to those who bother to read it. . .

Might even want to have a blurb on this in the documentation for the MTA administration section of the manual?? While you guys all know this, I find it not uncommon for administrators to forget it. . .Mike's suggested warning is a good start on this too.

Dan

[KenVM]

Thanks dwmtractor, looks like that was the issue.

I hadn't considered file encoding consuming message size. I just assumed that the original file size would be considered and thats it.

I think just having a little snippet on the MTA tab would help alleviate a lot of the problems on this one. A small note reminding admins to consider file encoding and a link to a more detailed explanation.

Thanks for your help!

-Ken

[mmorse]

Bug 21584 - Warning in admin console when zimbraFileUploadMaxSize greater than zimbraMtaMaxMessageSize

[dwmtractor]

Thanks, Mike, for the bug filing. Ken, glad you're back in business. Marking thread solved. . .

Cheers,

Dan

[sidestar]

Hi,

I have ZCS 5.0.1 on a Debian4 box. Increasing the message size still gives large attachment error and the operation fails.
Attachment size: 24845376 (uue size is: 34584282)
zimbraMtaMaxMessageSize: 61440000

I saw previous postings, but the version under test is the latest and I assume the problem resurfaced.

Anyone else has similar problems with this kind of setup?