Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-241

fail gracefully upon large messages/attachments

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.1.3
    • 3.0-M2
    • POP3Server
    • None
    • redhat 9

    Description

      I am aware of the <maxmessagesize> to prevent too large messages getting into james and the corresponding fast-fail discussions (http://marc.theaimsgroup.com/?l=james-user&m=108040337403426&w=2, http://nagoya.apache.org/jira/browse/JAMES-134).
      When uploading via a web-mail interface into my MySQL mailstore, I got messages up to 14MB through the system.

      However, I would like to know what is the maximum I can safely handle.
      I didn't find anything documented.
      I did increase the heap for my JVM in phoenix.sh with PHOENIX_OPTS=-Xmx512m, but on a 45MB attachments, it fails with little useful error output:
      <<[root@myhost logs]# less connections-2004-04-01-09-24.log
      01/04/04 09:24:35 ERROR connections: Error handling connection
      java.lang.OutOfMemoryError>>

      Especially, since my adaptation of the MySQL mailstore also explicitly stores attachment sizes, I could stop that message from being pushed through the pop3 server before it is in memory and causes problems and then could issue error message saying (e.g. "message ABC too large - please retrieve via webMail interface" instead of the current <<
      Task 'sPop test account - Receiving' reported error (0x800CCC0F) : 'The connection to the server was interrupted. If this problem continues, contact your server administrator or Internet service provider (ISP).'>> I see in my MUA)

      Attachments

        Issue Links

          Activity

            People

              norman Norman Maurer
              ralfhauser Ralf Hauser
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: