Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-4772

CiviMailProcessor silently fails when there are too many messages in an IMAP inbox


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.2.7
    • Fix Version/s: 4.3.0
    • Component/s: CiviMail
    • Labels:


      When the CiviMailProcessor is run on an IMAP inbox with too many messages, it silently fails. I'm not sure where the cutoff is, but in my testing 16,567 was too many and 12,585 was OK. So it might be 16,384 only because that's the power of 2 in between those numbers. When it's too full, you get this error message back from the IMAP server (in the case of dovecot on RHEL 5.3, at least): A0007 BAD Error in IMAP command FETCH: Too long argument.

      So there are a couple of issues to address here:

      1. It shouldn't silently fail. The only reason I was able to grab that error message at all is because I spent hours tracing the breakdown and finally narrowed it down enough to insert a print statement into packages/ezc/Mail/src/transports/imap/imap_transport.php on line 980. The library is throwing an ezcMailTransportException when this occurs and putting that error message into the exception object. So ideally all that would propagate up to the stdout of the calling script so the caller sees it (and cron e-mails the error to the admin, etc.). But currently it doesn't, the CiviMailProcessor.php script just stops and no error is seen.

      2. It shouldn't fail at all. It seems like maybe this is a bug in the upstream ezc IMAP library we're using. So maybe a newer version of that would fix it? Or maybe we need to patch it for now and then submit that patch upstream? Seems like there should be a way to limit whatever argument it's sending so the size doesn't get so big the server rejects it. I don't know if dovecot is uniquely picky in that regard, but it's a pretty common IMAP server so probably it's best just to accommodate it either way.




            • Assignee:
              lobo Donald A. Lobo
              cap10morgan Wes Morgan
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: