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.
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:
To make the generic error message better:
Bug 19210 - Incorrect error message while sending message of size exceeding than set in MTA
Bug 16128 - Attachment upload limit has to be displayed
- 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 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
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
Last edited by mmorse; 12-10-2007 at 07:25 AM.
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.
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!
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:Sound agreeable to all here?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.
The different values for each app discussion that I often see & other's reading this may go 'why not separate values for each app?'
- 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.
- 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.
- 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.
- 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?
- 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.
- And most importantly the idea is to keep-it-simple
Last edited by mmorse; 11-05-2007 at 01:10 PM.
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 know it's verbose, but it would at least be comprehensible to those who bother to read it. . .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.
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.
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!
Last edited by mmorse; 11-05-2007 at 01:16 PM. Reason: meant 'greater' not 'less' if I word it that way
Thanks, Mike, for the bug filing. Ken, glad you're back in business. Marking thread solved. . .
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)
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?
There are currently 1 users browsing this thread. (0 members and 1 guests)