Answers.Body: <p>Most likely this is the first message in your CiviMail IMAP folder. The error message that we print out is what is returned from the ezMail package</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T06:29:33.783Z
Answers.Text: Is there a log that tracks which message is getting hung up?
Answers.UserDisplayName: BruceW
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T06:48:15.163Z
Answers.Text: (Damn, StackExchange and its autocratic rules, not letting me edit a comment after 5 minutes of creation.) All the bounced messages have the same format. Can't figure why it is getting hung up. Here is an example: "Subject: Delivery Status Notification (Failure)"  Body: The following message to <email@domain.com> was undeliverable.
  The reason for the problem:
  5.4.7 - Delivery expired (message too old) 'timeout'
Answers.UserDisplayName: BruceW
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-21T07:22:01.890Z
Answers.Text: Not the first message or the 50th or 150th. I've increased the message size variable in postfix to 10MB to no avail. The largest bounced message is 250KB. Bump.
Answers.UserDisplayName: BruceW
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-11T04:49:00.360Z
Answers.LastActivityDate: 2015-04-11T04:49:00.360Z
Answers.UserDisplayName: Donald Lobo
Answers.Body: <p>This issue has been fixed by Zimbra, the email application we use. Can CiviCRM be adjusted to deal with this issue or is it purely on the IMAP server side? Would using POP3 have a different effect?</p>
  
  <p>Their solution is with a caveat that has a <em>drastic</em> effect at the enterprise level:</p>
  
  <blockquote>
    <p>The issue stems from the bug reported at -
    <a href="https://bugzilla.zimbra.com/show_bug.cgi?id=73266" rel="nofollow">https://bugzilla.zimbra.com/show_bug.cgi?id=73266</a></p>
    
    <p>Pasting an internal comment from the bug, which help explains the
    issue  --- This goes back to the fix for bug 63644. There are two
    limits at play zimbraImapMaxRequestSize and zimbraMtaMaxMessageSize.
    The latter is used for all literals, regardless of command. Due to the
    way literals are processed there isn't a really clean way to use
    zimbraImapMaxRequestSize for some literals and allow larger literals
    commands such as APPEND where we really want to allow huge literals;
    at least without a big rewrite that is too much for 8.0 at this stage.</p>
    
    <p>Staff, for the purposes of the test can you also set
    zimbraMtaMaxMessageSize to a really small value (say 5). I think the
    main purpose of those two limits is to protect against buffer
    overflow; so as long as we have some limitations for all commands that
    should be safe enough for now.</p>
    
    <p>The downside of disabling NIO is that you loose out on the performance
    improvement that NIO offer - <a href="http://wiki.zimbra.com/wiki/IMAP_NIO" rel="nofollow">http://wiki.zimbra.com/wiki/IMAP_NIO</a> :<br>
    <em>> NIO implementation helps reduce the mailboxd memory footprint with a
    small CPU overhead. NIO eliminates the need of 1 (IMAP
    connection)-to-1 (server thread) mapping and helps reduce the memory
    footprint of the ZCS server. It is useful when there are many
    concurrent IMAP users. The exact benefit depends on the number of IMAP
    users/server and number of live connections/users.</em></p>
    
    <p><em>> The saving is linear to the number of active IMAP connections that are
    in a single mailbox server.</em></p>
    
    <p><em>> Example for 10,000 concurrent IMAP accounts:</em></p>
    
    <p><em>> With NIO: If there are 10,000 IMAP accounts, each of the IMAP accounts
    has an IMAP client which maintains 3 to 4 connections. There are at
    most 100 to 200 Java threads required in the mailboxd process to
    handle requests from those clients. If one thread uses 256k memory, it
    uses 25 to 50MB Java memory.</em></p>
    
    <p><em>> Regarding the CPU and depending on the load, the overhead usage can
    range from 0 to 20%. Since ZCS is not CPU bounded, the CPU increase
    should not be a significant factor to impact the client side response
    time.</em>
    *> 
    Without NIO: If there are 10,000 IMAP accounts, each of the IMAP
    accounts has an IMAP client which maintains 3 to 4 connections. There
    are 10,000*3 or 10,000*4 Java threads required in the mailboxd process
    to handle requests from those clients. If one thread uses 256k memory,
    it uses 7,500MB to 10,000MB of Java memory.*</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-30T18:00:08.150Z
Answers.LastActivityDate: 2015-04-30T18:08:31.473Z
Answers.LastEditDate: 2015-04-30T18:08:31.473Z
Answers.UserDisplayName: BruceW
Body: <p>I have recently been getting this error message from the bounce fetcher but the error message is not notating which message is the culprit:</p>
  
  <blockquote>
    <p>Parameters parsed (and passed to API method): 
    a:1:{s:7:"version";i:3;}</p>
    
    <p>Full message: 
    Finished execution of Bounces fetcher with result: Failure, Error message: An error occured while sending or receiving mail. The IMAP server could not list messages: * BAD maximum line length exceeded.</p>
  </blockquote>
  
  <p>Please advise.</p>
  
Tags: <civimail><joomla><4.5>
Title: CiviCRM 4.5.8 - Bounce Fetcher - Max Line Length Exceeded
ThreadText: # CiviCRM 4.5.8 - Bounce Fetcher - Max Line Length Exceeded
  
  (Asked by: username_0 on 2015-04-11)
  
  I have recently been getting this error message from the bounce fetcher but the error message is not notating which message is the culprit:
  
  > Parameters parsed (and passed to API method):
  > a:1:{s:7:"version";i:3;}
  >
  > Full message:
  > Finished execution of Bounces fetcher with result: Failure, Error message: An error occured while sending or receiving mail. The IMAP server could not list messages: \* BAD maximum line length exceeded.
  
  Please advise.
  
  **Tags:** civimail, joomla, 4.5
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2015-04-30. Score: 3 | Accepted answer
  
  This issue has been fixed by Zimbra, the email application we use. Can CiviCRM be adjusted to deal with this issue or is it purely on the IMAP server side? Would using POP3 have a different effect?
  
  Their solution is with a caveat that has a *drastic* effect at the enterprise level:
  
  > The issue stems from the bug reported at -
  > <https://bugzilla.zimbra.com/show_bug.cgi?id=73266>
  >
  > Pasting an internal comment from the bug, which help explains the
  > issue --- This goes back to the fix for bug 63644. There are two
  > limits at play zimbraImapMaxRequestSize and zimbraMtaMaxMessageSize.
  > The latter is used for all literals, regardless of command. Due to the
  > way literals are processed there isn't a really clean way to use
  > zimbraImapMaxRequestSize for some literals and allow larger literals
  > commands such as APPEND where we really want to allow huge literals;
  > at least without a big rewrite that is too much for 8.0 at this stage.
  >
  > Staff, for the purposes of the test can you also set
  > zimbraMtaMaxMessageSize to a really small value (say 5). I think the
  > main purpose of those two limits is to protect against buffer
  > overflow; so as long as we have some limitations for all commands that
  > should be safe enough for now.
  >
  > The downside of disabling NIO is that you loose out on the performance
  > improvement that NIO offer - <http://wiki.zimbra.com/wiki/IMAP_NIO> :  
  > *> NIO implementation helps reduce the mailboxd memory footprint with a
  > small CPU overhead. NIO eliminates the need of 1 (IMAP
  > connection)-to-1 (server thread) mapping and helps reduce the memory
  > footprint of the ZCS server. It is useful when there are many
  > concurrent IMAP users. The exact benefit depends on the number of IMAP
  > users/server and number of live connections/users.*
  >
  > *> The saving is linear to the number of active IMAP connections that are
  > in a single mailbox server.*
  >
  > *> Example for 10,000 concurrent IMAP accounts:*
  >
  > *> With NIO: If there are 10,000 IMAP accounts, each of the IMAP accounts
  > has an IMAP client which maintains 3 to 4 connections. There are at
  > most 100 to 200 Java threads required in the mailboxd process to
  > handle requests from those clients. If one thread uses 256k memory, it
  > uses 25 to 50MB Java memory.*
  >
  > *> Regarding the CPU and depending on the load, the overhead usage can
  > range from 0 to 20%. Since ZCS is not CPU bounded, the CPU increase
  > should not be a significant factor to impact the client side response
  > time.*
  > \*>
  > Without NIO: If there are 10,000 IMAP accounts, each of the IMAP
  > accounts has an IMAP client which maintains 3 to 4 connections. There
  > are 10,000\*3 or 10,000\*4 Java threads required in the mailboxd process
  > to handle requests from those clients. If one thread uses 256k memory,
  > it uses 7,500MB to 10,000MB of Java memory.\*
  
  
  ---
  
  ### Answer by username_1 on 2015-04-11. Score: 1
  
  Most likely this is the first message in your CiviMail IMAP folder. The error message that we print out is what is returned from the ezMail package
  
  > **Comments:**
  > **username_0**: Is there a log that tracks which message is getting hung up?  
  > **username_0**: (Damn, StackExchange and its autocratic rules, not letting me edit a comment after 5 minutes of creation.) All the bounced messages have the same format. Can't figure why it is getting hung up. Here is an example: "Subject: Delivery Status Notification (Failure)"  Body: The following message to <email@domain.com> was undeliverable. The reason for the problem: 5.4.7 - Delivery expired (message too old) 'timeout'  
  > **username_0**: Not the first message or the 50th or 150th. I've increased the message size variable in postfix to 10MB to no avail. The largest bounced message is 250KB. Bump.  
  
  ---
  
  