• General
  • [Solved] Incoming Email Attachment File Size

adjusted nginx param client_max_body_size=130m;
increased send/recv timeout params too
attached 90.5MB file to email, I'm having error message below upon clicking 'Send'

add: I tried to attached 57Mb file I am having a different error - message rejection this time

But when my attachment file is less than 50Mb it is delivered without issues, can somebody help to make sense of this?

Did you check the settings in the postfix main.cf?
In Grommunio by default the parameter "message_size_limit" is set to 0.
(message_size_limit=0)
I don't know if "0" turns off the message_size_limit or sets it to standard of 10240000 (app. 10 MB)
You can try to increase the value to your requirements and see if it helps.

By the way: I personally would not exceed a message size of maximum 25 MB. To transfer bigger files there are other suitable options available. Additionally most recipients will not accept attachments of that size you like to send.

Check also the send and receive quota limits in the user settings in the grommunio admin-ui. The settings for send and receive are only for the size of the mailbox and not for single messages! I also fell into the trap at the beginning, because I thought that this affects the size of individual messages.

It is common practice that attachments are generally base64-encoded, so 50 becomes 66 MB during transfer.

These are periodic report exchanges that the users chose to use email.
by default, the Grommunio limit is 30MB

then I increased-
nginx:
client_max_body_size=130m;
client_body_timeout=3600;

PHP FPMs:
upload_max_filesize = 130M
post_max_size = 130M

and left postfix message_size_limit=0 (unlimited)
but why 2 different error messages?

    sigman The Attachment error message comes from grommunio nginx and php - the php upload limit, the other message (MAILER-DAEMON) comes from postfix - the smtp size limit. I assume the MAILER-DAEMON message is from destination mail server - message size to big for this server.

    Latest Test Results
    File attachment 57MB:
    grommunio-email -> external-email OK
    external-email -> grommunio-email NotOK
    grommunio-email -> grommunio-email NotOK

    gromox-delivery-queue side is now the suspect, anyone?
    I can not find a parameter limiting to 67108864 (64MB) with reference to "gromox"

    sigman changed the title to Incoming Email Attachment File Size .

    Run journalctl -f and try to receive a big mail. Do you see any errors or warnings regarding mail size in log?

      WalterH
      got this log on error:
      2022/10/28 21:10:28 [error] 22095#22095: *71 FastCGI sent in stderr: "PHP message: Unable to submit message for tester@testbox.com, MAPI error: MAPI_E_NETWORK_ERROR. SMTP server may be down or it refused the message or the message is too large to submit or user does not have the permission" while reading response header from upstream, client: 10.11.12.13, server: _, request: "POST /web/grommunio.php?subsystem=webapp_1666703207685 HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/grommunio-web:", host: "mail.testbox.com"

      As I have posted the results of the above tests, the culprit is obviously the MDA (Mail Delivery Agent)
      side 'gromox' as it can deliver external mail without a problem.

      The log shows: FastCGI sent in stderr: "PHP message: Unable to submit message for tester@testbox.com, MAPI error:.
      Please explain how you received the big mail?

        WalterH
        as simple as composing and sending through Webmail, and test results say
        File attachment 57MB:
        intenal-grommunio-email -> external-email OK
        external-email -> internal-grommunio-email NotOK
        internal-grommunio-email -> internal-grommunio-email NotOK

        When you hit the Send button in g-web (or Outlook Online Mode), the outgoing SMTP is contacted synchronously, and if the SMTP rejects it, the error is returned back to the caller as the result of the Submit operation. Other mail systems may process submissions asynchronously, such as when sendmail -t is used by local Unix MUAs. Async submission has the drawbacks that it needs somewhat more code, you don't see SMTP errors immediately, and the return path back to the mailbox needs to be valid already.

        8 days later
        sigman changed the title to [Solved] Incoming Email Attachment File Size .

        /etc/gromox/smtp.cfg) add parameter:
        mail_max_length=(parameter-here example: 100M)

        and adjust nginx settings too

        © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice